LIBRARY: Tutorials Reviews Interviews Editorials Features Business Authors RSS Feed

Checksums, Speed, and Acceptable Risk

COW Library : Art of the Edit : Kylee Peña : Checksums, Speed, and Acceptable Risk
CreativeCOW presents Checksums, Speed, and Acceptable Risk -- Art of the Edit Editorial All rights reserved.

Do you hang out under a tree during a lightning storm? Do you perform a checksum every time you copy important files from one place to another? If you don't have an equally strong opinion about both these questions, it's time to learn about checksums: how they work, how much you can trust them, and how this technical task can save a creative person from certain doom.

As a Workflow Supervisor for Bling Digital, I work with a team to provide post production services specializing in set-to-finishing data management and digital dailies for television and feature films. While we’re engineering workflows using the latest in camera and post technology for major studios worldwide, we’re also responsible for the integrity of camera masters — the “digital negative” — in the post pipeline.

What that means for me: lots and lots of files from all different kinds of cameras coming in the door every day for shows like Scorpion and Jane the Virgin, each needing to be processed for dailies and distributed appropriately through VFX, online and color very rapidly. Ensuring these shows and movies are delivered on time means that not one bit of these terabytes can be out of place, so learning about and advocating for verification processes like checksums is one of my most vital roles at Bling.

Simply put, a checksum is a method for detecting errors when copying a file from one place to another. When a file is being copied or moved between two different storage mediums, an error can occur that is undetectable from a quick glance but can cause big issues later on; like two bits being swapped inside the file that cause it to not play back anymore.

A checksum can be a difficult concept to understand both in function and importance, only in part because it's pretty boring on the surface. In my experience, many people in post production beyond on set media managers don't really know what a checksum is – and it's hard to blame them, because it's not simple to investigate in the context of video production. If a checksum is done at all, it's a button that spits out data that says "verified" or not, a not-that-interesting chore done in the process of getting media from one place to another in order to get to the good part. Who would ever want to know more?

But if your media is compromised, that's the end of the road. No assembling, no cutting, no finishing. That's a lot of trust to put in a boring button-press that may as well be run by magic for all of you now. What is actually happening in there? Does verified actually mean verified all the time?

In video post production, a checksum is used to prevent as many of these copy errors from slipping by as possible. There are different checksum types that accomplish this error detection in their own ways, and with varying degrees of accuracy depending on, well, variables.

From there, things quickly get much trickier.

The concept of a checksum is complicated by its origins in cryptography. Its technology is used to verify data authenticity ("has this been maliciously tampered with?") as well as data integrity ("did this copy to my hard drive as I expected?"). In post, we have other needs and methods for keeping media safe from potential harm, so complicated cryptography-related checksum algorithms offer us features we don't use. An MD5 checksum has become industry standard, and studios that require checksums with media offload on set typically require it.

And further research leads you down two rabbit holes: a whole lot of forum posts by internet mathematicians arguing about equations, or a brief summary which blindly accepts checksum methods as "totally safe" with no actual explanation of how or why it works.

Besides the industry standard MD5, there are many different kinds of checksums. A newer checksum called "xxHash" has been recently(ish) introduced as a faster alternative to MD5 that does not check data authenticity, and data wranglers are pushing for its adoption while studios push back. Is this disruption on the checksum scene worth looking at, or is it an attempt to cut corners on media management?

"Maintaining the integrity of media" being the most important job description that any of us have at Bling Digital, I wasn't happy with choosing between not-human-readable descriptions of algorithms by internet strangers and over-simplified blog posts that come down to "Hey, whatever, it works!" I want to know more about the processes that I'm trusting to check the bits I can't see because I am not a robot, unfortunately.

It is important to note that none of these checksums are perfect. Each checksum brings with it variables that determine both safety and speed. The reality of post production today is MORE media, LESS time. How likely is a lapse in data integrity, and how can you balance risk with time? What are the most important considerations for video professionals who manage data?


A checksum is a method for detecting errors in copying files from one place to another – from a camera card to a hard drive, or maybe from a portable drive to local shared storage. A checksum consists of a hash function, which "takes an item of a given type and generates an integer hash value within a given range."

Again, in English: the hash function looks at a video clip bit by bit, and from that it generates a string of random letters and numbers to represent that clip, kind of like a fingerprint for the file. When a checksum happens, it's comparing the string of letters and numbers – the hash value – for the clip on both the source and destination locations. Even one bit out of place will mean the hash value (or fingerprint) for the file will be completely different. If the hash values match, the checksum believes the data has been copied correctly.

A good hash function will generate unique hash values from different inputs. The way the algorithm is programmed to work, your computer hardware, and the length of the hash value (meaning the number of characters in the random string) will determine the speed of the checksum, as well as the likelihood of a "hash collision."


In every hash function we'll use, there is some possibility of unique inputs generating the same exact hash value. This is called a "collision." If a collision occurs, that means two or more of the clips you've verified with a checksum have the same hash value, so one of them has not actually been verified. This file could have been damaged in the copy process, but there's no way you'll know because your checksum saw that the hash values matched on both sides, so it believes everything is fine.

(Hashing algorithms are incredibly complex, and while I want to understand how they work so I can make informed decisions about how best to utilize them to protect media, I know there are limits to my expertise. I believe that it's enough for me to know they exist and that there are different algorithms that work different ways. In terms of collisions, I think it's more important to talk about hash length, especially given that the checksum options available in most media offloading software have comparably "safe" algorithms.)

You already know a hash value contains a string of random letters and numbers generated after the function looks at all the bits inside a video clip. What I didn't mention before is that these random strings are different lengths depending on the checksum you choose. This "bit length" of a hash value can vary wildly, from 32 bits to 256 bits, or more or less. They also vary by checksum – an MD5 checksum could be 32 bits, or 128 bits too.



What's the bit length of the MD5 checksum your media offloading software is using? Why does it matter? Setting aside the algorithm, there is a 1 in 1000 chance of a hash collision in a 160 bit hash if you have 5.41xD71022 clips. With a 32 bit hash, you reach that probability with just 2932 clips. For reference, you also have a 1 in 1000 chance of getting a four of a kind in a poker game. Even if you're the worst card player, you've played a hand at least once where someone won with a four of a kind. In the same way, you should remember that collisions aren't merely a possibility – they're inevitable.


It's important to consider a couple aspects of probability theory when it comes to thinking about hash collisions. This is going to feel a little high school math, but love yourself and stick with it this time.

You remember the probability of a random event, right? If you flip a coin 50 times and it comes up heads every time, what is the probability it will come up heads again? It's 50-50, and it always will be. In the same way, each hashing function is a completely independent event. It doesn't know what the value generated on the previous clip was, and doesn't care what the value of the next clip will be.

You may have forgotten about the "birthday paradox." This is the probability that in a set of randomly chosen people, some pair of them will have the same birthday. You might believe that this probability hits 100% when you have 367 people, given that there are 366 possible birthdays in a year, including February 29th. However, you actually hit 99% probability with just 57 people. This is an important way to illustrate how probability works in terms of hash collisions – the number of clips needed to generate a possible collision is much lower than you might anticipate at first glance because hash values aren't equally distributed, just as birthdays are not equally distributed across every single day.

Why did I share math lessons? Context. It's all numbers and math, and there's a reason why this works and doesn't work. If you have a firm grasp on the very basics of this process and the simple limitations of it, you are more informed and appropriately trusting of your checksum. We want to trust what computers tell us because they're sitting all around us all the time, buzzing us when we need to do a thing or sending a notification when we've forgotten to do another thing. We want to trust them, but they're all numbers and math. We have to decide how to interpret them based on the inputs we've provided.


Again, a shorter hash – 32 bits instead of 128 for example – will increase your chances of a collision significantly. So why not just run a 512 bit checksum on every clip? Well, it takes longer. Like, it can take a LOT longer, especially if you're using a complex checksum like MD5. More complexity means more data to crunch. So yes, you could run the biggest hash you've got. But in the world of on set media management or dailies, the clock is running constantly and it's not realistic to allow hours and hours for the verification of data when smaller hashes are probably capable of doing the job.

But it's important to understand the risk you're accepting. You have a 1 in 100 million chance of a collision basically right away when you use a 32 bit hash value. But with the 160 bit hash value, you need hundreds of thousands of clips before you reach those odds. (That's a simplified way to think about how collisions can come up, but keep in mind that it can happen on clip #1 or clip #95,909 since like a coin flip, collisions are independent events.)

You also have a 1 in 100 million chance of dying in a shark attack. Do you still swim in the ocean? Some people don't, but most of us probably do while we remain vigilant...just in case. Jaws was popular for a reason.


The speed at which checksums run is limited by the hardware you're using. Some people try to say that xxHash is considerably faster than MD5 in an attempt to sway people from one to the other, citing 5.4 GB/s compared to MD5's 0.28 GB/s. But these speeds are benchmarking tests, not real world uses. Among other things, your checksum process is limited by your CPU's computing power, your RAM, the speed of your hard drives, and the way you're connected to devices. That xxHash checksum is fast, but it's only faster than MD5 if the transfer speed of the source and destination is more than 350MB/s.  You can only accurately compare checksum speeds using the same hardware and software setup. And if you give a complex checksum process too much power, you won't leave enough for running other tasks on your system. Like everything else in video production, the details and peripherals matter greatly.

In Shotput Pro, three of the checksum types you can choose from are SHA-1 256, MD5-32, and xxHash-16. Given that these are all considered to have similarly safe algorithms and are commonly used checksums in video production, and given what we know about hash lengths, I decided to run a test to see how quickly media could be verified with each.

I used a late 2013 Mac Pro with a 2.7 GHz 12-Core Intel Xeon E5 and 64 GB 1866 MHz DDR3 ECC.

The source is a Lacie Rugged Drive connected via USB3 directly to the Mac Pro. The destination is the Mac's desktop. The read/write speed from this drive, testing with Blackmagic's speed test, is roughly 85 MB/s. These drives are very commonly used for media transfer and transport.

Using Shotput Pro 5.3.4, I verified a "small" 2.5 gig ProRes file and a "large" 10 gig ProRes file – both files generated by an ARRI Alexa XT.

Checksum: xxHash
Hash Length: 16 bit
Time Elapsed: 47.19 seconds

Checksum: MD5
Bit Length: 32 bit
Time Elapsed 85.77 seconds

Checksum: SHA-1
Bit Length: 256 bit
Time Elapsed: 112.92 seconds

On a common video production hardware setup, the MD5 checksum took twice as long as xxHash, and the SHA-1 checksum took 3 times as long.

A terabyte might take 2.5 hours to verify with SHA-1. With xxHash, it might take only an hour. MD5 falls somewhere in between, a little under two hours. I didn't do any testing to see how speeds compare between doing a terabyte all at once or several hundred gigabytes at a time, which is far more likely in an on-set media management situation. (But I don't have any reason to believe there are significant speed variances between big chunks and small chunks.)

The difference between an hour and 2.5 hours on set or in dailies turnarounds is significant. The difference in "safety" may or may not be as significant depending on your outlook. Setting aside the algorithm each checksum is using, you can see how they might be different.


I know the odds of being struck by lightning are fairly low, about 1 in 500,000-ish. But when I'm outside during a thunderstorm, I don't hang out under a tree. And I'm guessing you don't either. But I'm also guessing you don't sit inside your home, refusing to go outside for even a moment until the storm is long gone. Similarly, I think there's a middle ground to be found in checksums depending on the level of risk you're willing to accept.

In video production, we accept all kinds of risks on a day to day basis. We trust that every person in the chain is doing their job. We allow people to drive cars with hard drives inside. We assume the set isn't going to be struck by a meteor. Acceptable risk is a part of doing business. But we need to know exactly what kinds of things we're choosing to trust and how they work. As the industry continues to move in the direction of faster speeds, higher capacities, and increased footage, xxHash will likely be more widely adopted. What about after that? Shorter bit lengths? Less complex but less robust algorithms? Will our amount of acceptable risk shift as expectations shift?

We need to remain vigilant that our need for speed isn't tossing aside essential verification processes that can make or break the completion of a project. Particularly as an advocate for digital negative, the safety of bits is near and dear to me. What you do on your own productions depends on your own needs, but knowing what you're getting yourself into – bit for bit – puts you ahead of the curve. My own data verification choices will continue to evolve depending on the needs of clients and studios, combined with the fail-safes available to ensure the safe keeping of the digital negative.


Kylee Peña is currently based in the Los Angeles branch of Bling Digital. Originally from the Midwest, Kylee spent six years as an editor in Indianapolis and Atlanta, working on projects ranging from PBS shows to independent films.

Kylee started out with Bling in the Atlanta office before relocating to LA in 2015, applying her knowledge of a working editorial department to the technical and creative aspects of workflow design on shows like CBS's Scorpion and Jane the Virgin on The CW.

A Women in Film member, Kylee is also an advocate for gender equality in post production, having spoken on the topic on numerous podcasts, in classrooms, and at the National Association of Broadcasters conference in 2015.

Many thanks to Bling Digital, a division of SIM Digital, for allowing us to reprint this article from the Bling Digital Blog.


Re: Checksums, Speed, and Acceptable Risk
by Joe Bell
How do we feel about CRC which the Nexto DI devices use?
Re: Checksums, Speed, and Acceptable Risk
by David Pultz
Da Vinci Resolve 12 has Clone Tool, a build-in file copy function with checksum verification. There is a free version of Resolve for both Mac and PC, downloadable from Blackmagic Design.
Windows and the convenience of "checked" backups.
by Anthony Burokas
I agree that checksums are important but I think there's tiny bit of exaggeration in the article- that "two bits being swapped inside the file that cause it to not play back anymore." It depends on where that bit is. Is it part of the compressed video description where changing a bit changes the hue of an 8x8 MPEG block? or is it a bit in the header that describes what the file is? Those are very different situations.

To wit; we've been copying important spreadsheet data, banking information, e-mail, and more for decades and nobody bothered with checksums- and those files remained readable on far less reliable systems, like dialup internet.

As a freelancer, I'm often tasked to shoot and then dump my content onto a client's "pocket" drive before they leave, there's often NOT two backups. And while I may hold the content for a little bit, I can't sit on multiple shoots indefinitely "in case" the client later finds out a file copied bad. So I found a portable offloading solution I could keep in my camera bag.

There are a few different PC apps that offer verified offloading which should have been mentioned in the article.

In my search for something I could dedicate, I found a 32-bit OS capable backup app ( that runs on an inexpensive USB-3 equipped WinBook tablet. The app is touch-screen friendly and five taps dumps my SD cards at over 65 MBps. I added MacDrive so I can write to MacFormatted HDDs too.

Truth be told, if there is an error, the most we can do is cancel the copy and try again. Back when I wrangled RED with R3D, if I got a checksum error on a file, I'd play it on the destination and it never failed to play. So how critical checksums are is still up for debate to me.

Moreover, I've had more "bad clips" in camera than after camera when dumping to HDD. A checksum verified copy of a corrupt file won't play either. But it will be verified to be exactly what is on the camera card.

However, I can see the value of a checksum verify for use on a large scale production because because it ads another layer of "CYA" protection because I can point to a verified copy if the client later has issues with a file I delivered.

Anthony Burokas ~
Re: Checksums, Speed, and Acceptable Risk
by David Parker
Yeah, you really missed the point on collisions and hash size.

Collisions have almost nothing to do with the size of the hash (practically, in this usage), and certainly not with the numbers of files you copy. It's relationship to the hash algorithm is the interesting part, which you skipped over. md5 and sha-1 are cryptographic hashes, which are designed to be very resistant to anyone being able to intentionally cause a collision (someone create a file that matches a hash of yours). This takes a lot of extra math and processor work. xxHash is a non-cryptographic hash, which means that is only concerned with creating a hash from a file, an making sure that hash is unique, given the size of the hash. This is all you need for this use case (detecting copy errors or bit rot).
Re: Checksums, Speed, and Acceptable Risk
by Michael Brockington
Interesting article, for sure. I think the analysis is slightly flawed and overstates the risks, though.

With file verification, I think there's only one case where you care about a hash collision:
1. File 'A' has checksum 'X'
2. File 'A' is corrupted during copy
3. The corrupted copy of file 'A' also has checksum 'X'

If you're copying 1000's of files, it really doesn't matter if file 1 has the same checksum as file 2, or even if every single file has the same checksum (however improbable that might be.) The only scenario that can lead to data loss is the one outlined above.

So you don't have to worry about the probability of a collision among a set of 1000's of files, only about the much lower probability of collision between 2 specific files. And you would have to multiply that very low probability by the chance of the file getting corrupted during a copy, which will reduce it still further.

--Michael Brockington
Re: Checksums, Speed, and Acceptable Risk
by Gerhard Riesenhuber
Hi Doug,

I don't think the article was Mac- centric. The content is OS agnostic.

The software "Shot Put Pro" which was used for the explanation is available for Mac OSX and Windows:

I also use "Pomfort Silverstack XT" which is faster than Shot Put Pro for RAW sequences. (like "YoYotta" it is Mac only software)

I'm not aware of any GUI- based Linux software for those verified backup tasks.
But you can use "md5sum" in your shell to generate a md5 checksum. With the help of scripting you can even write your own checksum software.

Best regards,
@Gerhard Riesenhuber
by Dan Montgomery
ShotPut Pro now also offers the same XXHash that Silverstack uses, so I doubt there's any difference in checksumming RAW sequences. In fact, we waited for the 64 bit version and Silverstack had the earlier 32 bit version. Perhaps you're not using the latest SPP version?

Offload with Confidence...
@Dan Montgomery
by Gerhard Riesenhuber
Hi Dan,

Last time I compared the 2, Silverstack was faster on image sequences using md5 on both. Maybe I give it another try. I also like that with Silverstack I'm able to recopy only the files that made problems, which wasn't possible at that time with Shotput Pro.

That said, I always recommend Shotput Pro and Silverstack for offloading media to anyone who asks me!

Best regards,
Re: Checksums, Speed, and Acceptable Risk
by Dan Montgomery

ShotPut Pro is available in both Mac and Windows versions. It's $99 per computer. There are also a few other offload applications on the market as well as checksum capabilities embedded into some camera manufacturer's viewing/copy utilities.

We also offer a stand alone Mac application named ShotSum that is a comparison tool for everything from single files, folders or files, to entire volumes, with the various checksum types and logs/reporting capabilities. It's not a copy utility, it's a comparison utility. $99 per seat.

We also use checksum technology in some of our other applications as a way to uniquely match up files, regardless of where they're stored or named. For example, our LTO control software, PreRoll Post, uses checksums to make sure the files on the tape match back to the originals. And when restored from tape back to a hard disk, that copy also matches back to the original.

ProxyMill, our video transcoding application, uses checksums to match the compressed proxy representation files with the high resolution ones they represent.

Kylee did a good job of explaining that checksums are a lot like insurance policies--they rely in part on probability and risks. One thing I would point out however, is that in an offload-copy situation the files are known not random. In other words, you're only comparing a relatively small set of files to another set. And those are nested in known folders and sub-folders, and have specific names. So the likelihood of 'data collisions' is very very remote for any of the checksum types, because all of those things need to match up before a checksum value is even compared one to another.

In fact, when there's a reported mismatch of files checksum values the most likely culprits are not getting struck by lightening or bitten by a shark, but more mundane things like overheating media card readers, or disks that are beginning to fail, etc.

Offload applications like ShotPut Pro also offer assistance in preventing simple human errors. Things like trying to copy files back onto the same hard disk, or erasing a card before it's been backed up, etc. Common little mistakes that a tired human might make at the end of a long day that can have devastating repercussions.

As to "what to do", look for obvious problems like 'the computer went to sleep during the copy' etc. And of course copy that file or the entire volume again.

As for "doing checksums in the background", yes of course ShotPut Pro tries to save you time. It's calculating the values as the source files are read, then again from the copies that were made. And as added insurance, there's an advanced option to re-read the source after copying is finished to verify the integrity (make sure nothing has changed on the source side). This added check makes sure more files haven't been added in the meantime, and helps catch failing hardware or overheating issues.

BTW, the SHA checksum types are most commonly used in server and UNIX situations and are offered as they may be required.

Checksum values aren't "random characters" per se. They are in fact a very precise string as dictated by the bytes and their sequence within the files. For this reason, they may be stored along with your copied files and referred to anytime in the future to ensure the file still matches it's originating source, whether you're moving the file or just want to test it's integrity.

Offload with Confidence...
@Dan Montgomery
by Kylee Peña
Hey Dan, thanks for jumping into this thread! I was hoping to see you around since I didn't mention ShotSum, which is also cool.

I do think your response about the probability of a collision needs addressing though. If I'm understanding you right, you're implying that a collision is unlikely in our industry because you're dealing with a relatively small set of files in on offload situation. However, my understanding is that the probability of a collision does not depend on the number of inputs. Probability remains the same no matter if there are 50 files or 5000 files, just the same way a coin flip has the same probability of turning up heads even after 500 consecutive heads-up flips.

The hash length does affect the probability, which is the point I was making. If I ask you to choose a number between one and ten and if you choose the number I'm thinking, the sun will explode, that sounds like a dangerous game. But if we change it to a number between 1 and 100, that's a lot different. Still risky, but not like oh crap we're all gonna die risky.

I think it's really important for people to understand that probability in this case is counter-intuitive. Look closely at the birthday paradox. My point in writing this wasn't so much hash collision fear mongering so much as knowing that different hash lengths can affect if you actually do ever see a collision in your life.

Please let me know if there is an aspect of offload copy situations that I'm not grasping here that somehow changes things.

You're right that the values aren't random characters. I should have said random-looking. They're not random at all since they should always generate the same value. But they look bananas if you've never seen one.

twitter: @kyl33t
@Kylee Peña
by Dan Montgomery
Well.... you'd be correct if this were a random act, but it's not. The checksums aren't random, they're specific to the file it's made for. So the verification process is comparing the values for two files that should be the same--every time--unless something has gone wrong. That hasn't anything to do with chance. You can calculate the checksum value for a given file over and over and always get the same value.

Now with a product like ShotSum, you would get into probabilities as you're potentially comparing a random pool of values so the chances of any of those colliding are in the realm of those you stated. In other words, the checksum values are driven by several factors so it is technically feasible, though very remote, that two non-matching files could share the same checksum value. But I'd buy a super lottery ticket before betting on a pair of checksums from non-identical files giving a false positive match.

Offload with Confidence...
@Kylee Peña
by Wun Yung

I believe you're making the mistake that checksums from a list, are compared with another on a list.

And although correct, each individual file's checksum is only compared with their own unique checksum.

Michael Brockington explained it correctly up above.

Your only worry with collision is when a corrupted file's checksum, still matches the original file's checksum.
Re: Checksums, Speed, and Acceptable Risk
by Adam Pyburn
This isn't the first time I've heard of checksums, but it is the first time I've understood their importance in my workflow. As an noob to the checksum game, I'm grateful for the breakdown and comparisons - really nice work explaining things!
I'm also still in need of some of the basic tenants of running checksums - as Doug mentioned - about software, automation, and (most importantly) how to handle errors.
I'm running things on my Mac, but I imagine that dealing with errors could be universal.(?)

Adam Pyburn Digital Media Production
Re: Checksums, Speed, and Acceptable Risk
by Garrett Evans
Great article. In my little part of the video production world, Checksums and their importance is the stuff of nerds like me, and not generally known, certainly to any of the youngsters coming up.

In fact, it was a DVD Replicator who first introduced me to it, and with those gone the way of the dinosaur, I'd like to institute a checksum workflow for our Digital Download business. In particular, we use AWS S3 to upload our video products for eComm. How can I employ MD5 to check my own uploads?

Currently after I make an MD5, I check it before uploading, to maker sure and get a 'File OK'. So once the file uploaded to S3, would I download the .md5 that went with it, and check it the same way on my local box?
@Checksums, Speed, and Acceptable Risk
by Thomas Tomchak
This was such a great post. Your explanation of the different checksum types and technical background helped fill in some gaps in my knowledge. I think I can now better explain to clients why this is so important.

I've been pushing producers to use ShotPutPro for the sole reason of it having MD5 checksums built in, and in more than one case it has made a difference by catching a potential bad copy.

Thanks for sharing this article and the expertise that you have. I really enjoyed reading it.

Thomas Tomchak

@Thomas Tomchak
by Wun Yung
Checksums are great, but this article is incorrect.
Re: Checksums, Speed, and Acceptable Risk
by Douglas Bowker
Interesting article, but a few things would have made it much more useful: First off, it was entirely Mac-centric, when many production studios (or independent digital artists) also use both Windows and Linux systems. The topic would seem to apply to all platforms, no?
Beyond the platform aspect, what is the simplest way to automate this procedure, or even just to try out for the typical reader?
Is this additional software that needs to be added to an OS, or a feature built-in but little known to most users?
Is it free/open source, or commercially available and for how much?
How does this apply to network IO, RAID and server storage considerations?
Is it possible to have a checksum performed in the background?
Lastly, what to do if an error(s) is detected?

Doug Bowker

Motion Graphics, Video and 3D Animation for the Medical and Technical World

Related Articles / Tutorials:
Art of the Edit
Why Does An Edit Feel Right?  (According to Science)

Why Does An Edit Feel Right? (According to Science)

In this episode from the series The Science of Editing, Sven Pape of "This Guy Edits" and Dr. Karen Pearlman, author of "Cutting Rhythms: Intuitive Film Editing" discuss three cognitive concepts that go beyond continuity, including rhythm, subtext, and kinesthetic imagination. Packed with examples from Ridley Scott's Blade Runner, Alfred Hitchcock's Notorious, and many others, the Science of Editing will help even the most seasoned editors -- and viewers -- unlock new dimensions in the cinematic experience.

Sven Pape
Art of the Edit
Unearthing Apollo 11 in Large Format: An Interview with Director Todd Douglas Miller

Unearthing Apollo 11 in Large Format: An Interview with Director Todd Douglas Miller

Director-Editor Todd Douglas Miller creates more than just another space documentary with his film Apollo 11. He has helped expand the horizons of what we thought we knew about one of humankind's signature achievements by unearthing nearly 300 reels of previously unseen large-format film, up to 65 and 70mm, digitized with a first-of-its-kind 8K scanner, along with 11,000 hours of previously unheard audio recordings to provide previously only-imagined perspectives on our first mission to the moon. Creative COW's Courtney Lewis reveals how he put it all together with NASA, the National Archives, post house Final Frame, and tools from Adobe.

Courtney Lewis
Art of the Edit
Editing Eye of the Beholder: The Art of Dungeons & Dragons

Editing Eye of the Beholder: The Art of Dungeons & Dragons

Kelley Slagle began her career in entertainment as an actor, so it’s not surprising the communal storytelling of Dungeons and Dragons caught her eye. She both edited and co-directed the prizewinning documentary "The Eye of the Beholder: The Art of Dungeons & Dragons", speaking to overe 40 artists across the 45-year span of the game's history. Creative COW Managing Editor Kylee Peña spoke to Kelley about the challenge of managing that much material into a 90-minute film, balancing indie filmmaking with the demands of a day job in video production, and the power of art to sustain a community.

Feature, People / Interview
Kylee Peña
Art of the Edit
Editing The Emmy Award-Winning Phenomenon, Wild Wild Country

Editing The Emmy Award-Winning Phenomenon, Wild Wild Country

Wild Wild Country premiered at the 2018 Sundance Film Festival to great acclaim, and when it hit Netflix a few months later, it quickly became a phenomenon, going on to win the Emmy for Outstanding Documentary of Nonfiction Series and netting editor Neil Meiklejohn an Emmy nomination for Outstanding Picture Editing for Nonfiction Programming. Creative COW's Matt Latham spoke with Neil about managing a project of this scope, treating the eight parts as a single film rather than episodes, his use of Adobe Premiere Pro, workflows with visual effects and music, and much more, including career advice for aspiring editors.

Feature, People / Interview
Matt Latham
Art of the Edit
What It Takes to Edit Big TV Shows: This Guy Edits

What It Takes to Edit Big TV Shows: This Guy Edits

Sven Pape of "This Guy Edits" joins TV editor Josh Beal (House of Cards, Bloodline) for a close-up look at editing Season 2 of Counterpart, the Starz series starring JK Simmons in a dual role -- which is only the start of the challenges presented by this high-energy sci-fi thriller. Josh dives deep into storytelling techniques, workflow, teamwork, organization, and even offers some insights for people wondering how to get started as TV editors themselves.

Sven Pape
Art of the Edit
Writer-Director Vidhya Iyer: Parents, Children, & Brown Love

Writer-Director Vidhya Iyer: Parents, Children, & Brown Love

Writer-director Vidhya Iyer is an Indian-Nigerian-American filmmaker, improv comic, AFI graduate, and CAPE (Coalition of Asian Pacifics in Entertainment) New Writers Fellow. Work on award-winning shorts has led to a comedy pilot called "PG 30" about authenticity, adult children learning to become honest with their parents, and the unique "brown love" between immigrant parents and their children. Creative COW Contributing Editor Clarence Deng explores all this and more, including the empowering community that grows up among filmmakers who are helping each other tell their truest stories.

Feature, People / Interview
Clarence Deng
Art of the Edit
The Top 5 Most Common Problems with Student Films

The Top 5 Most Common Problems with Student Films

What are the biggest mistakes of most student films? This "Science of Editing" episode may just have the answer. Join "This Guy Edits" Sven Pape and Macquarie University lecturer Dr. Karen Pearlman, author of "Cutting Rhythms: Intuitive Film Editing" and former President of the Australian Screen Editors Guild for a look at specific things to avoid to make your films your best.

Sven Pape
Art of the Edit
Editing Marvel's Black Panther: Debbie Berman ACE

Editing Marvel's Black Panther: Debbie Berman ACE

This is an epic tale spanning two decades, three countries, 12,000 miles -- and that's just the story of Debbie Berman, ACE, starting in reality TV and indie film in South Africa, making her way to Canada and then the US to edit Marvel's Spider-man: Homecoming and, most recently, Black Panther, already one of the most popular films of all time. In this exclusive interview with Creative COW Managing Editor Kylee Peña, Debbie talks about struggling toward US citizenship, a serendipitous meeting with an ambitious young director, helping to bring representation to the big screen and pride to her home country.

People / Interview
Kylee Peña
Art of the Edit
What Picasso Can Teach Us About Filmmaking

What Picasso Can Teach Us About Filmmaking

Feature film editor Sven Pape takes a unique, entertaining look at Pablo Picasso's approach to art, and offers specific examples from a variety of movies, as well as Picasso's own advice. As Sven puts it, success requires action. Make a film. Fail. Then fail harder. Of course, Picasso and Sven have great advice for succeeding too! You'll get a kick out of this one.

Tutorial, Feature
Sven Pape
Art of the Edit
Searching: Creating Cinematic Drama From Small Screen Trauma

Searching: Creating Cinematic Drama From Small Screen Trauma

The thriller "Searching" takes place on computer screens, but no screen captures were made. Instead, the team built the individual elements in Adobe Illustrator, animated in Adobe After Effects, and edited those elements together with live action footage in Adobe Premiere Pro. Creative COW Managing Editor Kylee Peña spoke to editors Nick Johnson and Will Merrick about the extraordinary lengths they went to to create this exceptionally compelling big screen drama from the family crisis being played out on small screens before us.

Kylee Peña
© 2020 All Rights Reserved