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
The Science of Editing

The Science of Editing

Sven Pape, aka @ThisGuyEdits, joins Dr. Karen Pearlman -- former President of the Australian Screen Editors Guild and a three-time nominee for Best Editing at the Australian Screen Editors Guild Annual Awards -- for a provocative look at "Editor's Thinking," a cognitive skill set that you can use to improve your screenplay before you start principal photography of your film.

Sven Pape
Art of the Edit
Film Editing Tutorial: How To Crush The First Notes

Film Editing Tutorial: How To Crush The First Notes

It's happened to you. The first cut sounds noisy, has compression artifacts, actors aren't giving their best performances -- and the director has notes about all this and more. Follow along as Sven Pape from "This Guy Edits" works through some of these very issues on the film he's working on, with tips on how deliver exactly what YOUR director is looking for.

Sven Pape
Art of the Edit
Editing Movie Trailers with Patricio Hoter

Editing Movie Trailers with Patricio Hoter

More and more, films that are currently in production are working alongside with their marketing teams to establish a strategy months in advance of its release. That means that there’s more time to explore several options when crafting a trailer, but the workload also becomes heavier, and the stakes become higher. Avid Media Composer editors Christian Jhonson and Patricio Hoter (The Jungle Book, The Last Witch Hunter, Green Room, Titanic 3D, and more) explore this evolving artform.

Christian Jhonson
Art of the Edit
5 Tips for Finding the Right Edit Point

5 Tips for Finding the Right Edit Point

Accomplished editors tend to point to instinct and experience when it comes to the exact edit point. Here are 5 tips from veteran editor Sven Pape of "This Guy Edits" that may help you get there. Some editors say that great editing is invisible. So is the right frame the one we don't notice?

Sven Pape
Art of the Edit
The Surprising Upside Of Procrastination In Film Editing

The Surprising Upside Of Procrastination In Film Editing

What if you wouldn't have to stop procrastinating? Sven Pape of "This Guy Edits" demonstrates how to use procrastination to achieve some of your best film editing work. "Why do I procrastinate?" asks Sven, "I give you Aaron Sorkin who has one of the best procrastination quotes: "You call it procrastination I call it thinking.""

Sven Pape
Art of the Edit
The Secret World of Foley, One of Cinema's Most Magical Arts

The Secret World of Foley, One of Cinema's Most Magical Arts

The Secret World of Foley is an evocative, wordless insight into one of the cinema’s most magical arts: the creative addition of synchronized sound effects in post known as Foley. This short film is also one of the most beautiful things you've seen in a long time. We highly recommend it to any fans of movies, sound, and the inspiration of watching true artists at work.

Tim Wilson
Art of the Edit
FuseFX & mocha: VFX for Walking Dead, Empire, AHS & More

FuseFX & mocha: VFX for Walking Dead, Empire, AHS & More

The 100+ member team at FuseFX juggles over 30 television episodics a season, while also working on features and commercials. Current credits include: FOX's Empire, ABC's Agents of SHIELD, AMC's The Walking Dead, SyFy's The Magicians, CBS's Zoo, and FX's American Horror Story. Brigitte Bourque, FuseFX's Digital Effects Supervisor and a 20 year industry vet, talks to us about the work that FuseFX does, and how Imagineer Systems mocha fits into their pipeline.

Feature, People / Interview
Imagineer Systems
Art of the Edit
Editing: The Kuleshov Effect Put to the Test

Editing: The Kuleshov Effect Put to the Test

One of the most powerful discoveries in the early days of editing became known as The Kuleshov Effect: the same piece of footage means different things depending on the shots that surround it. It is a mental phenomenon by which the audience derives more meaning from the interaction of two sequential shots than from a single shot in isolation. One hundred years later, Sven Pape of This Guy Edits puts this venerable axiom to the test. Does this fundamental principle of modern editing still hold up? Prepare to be amazed.

Sven Pape
Art of the Edit
Game of Thrones: Battle of the Bastards VFX

Game of Thrones: Battle of the Bastards VFX

Deluxe Entertainment Services Group (Deluxe) has shared with us that its Australian animation and visual effects studio Iloura delivered a significant suite of work for the recent "Battle of the Bastards" episode of HBO's tentpole series Game of Thrones. Working on the epic battle sequence for the Season 6, Episode 9 crescendo, Iloura's team of visual artists used a mix of VFX and hand-crafted animation techniques to realize the vision for the bloody showdown. As a bonus, we include HBO's production featurette on staging and shooting Game of Thrones' most epic scene yet.

Iloura VFX
Art of the Edit
How To Become A (Wanted) Film Editor

How To Become A (Wanted) Film Editor

What does it take to master the art of film editing? Sven Pape, host of This Guy Edits, shares 7 recommendations that may just turn you into a storyteller in demand. Or more specifically, he says, these are his thoughts on how to become what you love, whether directing, screenwriting, shooting, acting: anything that you have a passion for.

Sven Pape
© 2016 All Rights Reserved