Why Cinemas Don’t Need to Test DCPs Before the Playdate

Sometimes cinemas ask us for a KDM in order to test their DCP content before the playdate. In actual fact, this is unnecessary. A quick check of the sound levels and credit offset on the day of screening, sure. But a complete DCP rehearsal? It’s not necessary. And all because of the miracle of Checksums. Here’s how they work.

When we encode DCPs we create a master file. This is thoroughly checked, often more than once, in a quality control screening. The master is always perfect. The question is, if we send you a copy of that master, how can we be absolutely sure that no errors have crept in during the delivery process. After all, it’s been copied from hard drive to hard drive, uploaded, downloaded, dropped by a courier, left on a park bench and who knows what else?

At the very moment the master DCP is created, the mastering system will calculate a checksum on the data. This is an algorithm that takes every single 1 and 0 that makes up the DCP data and turns it into a small sequence of numbers and letters.

For instance, the above paragraph, if treated as ASCII text, produces the following md5 checksum: aa5a9e95277cb3543d4dbc11598d6910

But, if I change anything in the text, no matter how small, I will get a completely different checksum. So, if I just add an extra space after the word “master” in the above example the checksum changes to: 6040719cc0663ab44a92fd7f32f972c5.

So, in order to send you the paragraph safely I could send you the text as a text file. And, in a separate file, I would send you the checksum. And I would ask you to calculate a checksum on the text after you receive it and make sure the result matches mine. Because if it doesn’t, we know something has gone wrong and your copy of the text is incorrect.

This is exactly the process used with all kinds of critical file transfers. But it happens behind the scenes without you even knowing. For example, if you’ve ever updated the OS on your mobile you may notice that before it installs your phone takes a long time saying “verifying”. What it’s actually doing is calculating a checksum and comparing it the checksum of the original file before it was downloaded. This is essential because if the update was damaged during download, there’s a good chance your phone could end up being a brick.

And this is exactly how DCP file transfers work. Among all the files that make up a DCP, there is one file called a PKL. Within this file there is a hash value for each and every element that makes up the DCP. When you ingest a DCP your server will go through a verification process, calculating its own checksum and comparing it to the one it finds in the PKL. If they don’t match, your server will tell you the DCP is damaged and it will refuse to play. And your server doesn’t need a KDM to do these checks. You just need to ingest the DCP as normal and your server will automatically do all its checksums along the way.

So, that’s why checking the DCP yourself isn’t necessary. Your server has checked it for you. You know your DCP matches the master because the checksum matches what’s in the PKL. And you know the master has been fully checked by the DCP lab. You can therefore be fully confident that so long as your DCP ingested successfully, there is no need to worry. All thanks to the magic of Checksums.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close