I met a retired software programmer, now Ubering scruffy people like me about, who could rattle off the nuances of programming languages D-Base, Fortran, and Cobol with the greatest of ease. Most of you reading this will be searching Wikipedia to figure out what ancient relics of programming lore I’m talking about. This man, however, wasn’t living in the past. He still runs a business supported by programs written in these languages, all running on MS-DOS, the command-line operating system pre-empted by Microsoft with the introduction of Windows in the 90’s. His reward for sticking to arcane software is that it runs faster with every upgrade in hardware. For his application, there is no reward to upgrading the software. While one can only hope that this man will never run a cinema, his case is worthy to take note of.
Up until recently, software upgrades to digital cinema systems were largely limited to bug fixes. The reward for upgrading was the avoidance of known problems. Things have now changed. The US exhibition industry is in the midst of changing its distribution format from Interop DCP to SMPTE DCP. The reward for upgrading is…well…one might need to search for that. Both formats will play the movie. It’s not clear why an exhibitor would choose one DCP over the other. The lack of reward for upgrading is a problem.
One value that is sometimes quoted is that SMPTE DCP, in its most recent form, allows distributors to send more data about the movie to the exhibitor. This is a good feature to have. Another is the ability to distribute text-based 3D subtitles. But these features have no value without sophisticated software on the exhibitor side to act on it, and such software doesn’t come for free.
Digging a bit further, the SMPTE DCP defined by SMPTE is not quite the SMPTE DCP now in distribution. It is a subset of SMPTE DCP 2011, an improvement of the original version in 2009. The subset in use excludes 4 of the 5 sound formats defined in the 2011 standard, relying on a generalized 16-channel sound format originally proposed to accommodate DCI testing, now used as a container for the Interop DCP sound format. The problem is that the SMPTE DCP standard requires media blocks to route audio channels to the proper output if sounds are to be heard through the correct speaker system. The Interop version requires no routing. The mixup occurs with Hearing Impaired (HI) and Audio Description (VI-N) sound, when no routing is applied to SMPTE DCP. These channels are meant for headphones and not the auditorium speaker system, which is where they are heard when no routing is in place. The use of Interop DCP audio in SMPTE DCP solves this problem.
There is another kink to SMPTE DCP. In 2013, an amendment was made to the standard, incorporating the individual labeling of audio channels. One can say that the amendment solves a problem that no one complains about, adding an unnecessary layer of complexity to compliant distributions and systems. With the 2013 amendment, SMPTE DCP offers three methods for packaging 5.1 and 7.1 sound. Distributor #1 could choose one way, distributor #2 another, and distributor #3 could choose the third way. The ability of playback systems to properly interpret these three versions will vary, opening the door to poor interoperability, as opposed to improving the odds of interoperability. The beauty of the undocumented version now in use is that it limits the number of methods for packaging 5.1 and 7.1 sound to the one method proven to work across all systems: Interop DCP audio. This invites a review of SMPTE DCP. With object-based audio on the horizon as yet another audio format-to-be, now would be a good time to rethink the entire audio scheme.
Unfortunately, nowhere in this dialog has the reward of upgrading to SMPTE DCP been unearthed. For both exhibitors and distributors, movement to this format requires tandem distribution of both SMPTE DCP and Interop DCP. This results in duplication and inefficiency, multiplying the number of DCPs to be distributed, consuming distribution bandwidth, and filling up exhibitor storage systems. With negative benefits such as these, my Uber driver’s “no upgrade” policy could turn into a real movement in digital cinema.
What about the nice-to-have features of SMPTE DCP of additional metadata and 3D timed-text subtitles? The truth is that the limitation of these features to SMPTE DCP is arbitrary. The same features could be implemented in Interop DCP, without the pain of duplicate DCPs in distribution and exhibition, as the features are backwards compatible and will not break systems that do not recognize them.
The message in this dialog is not that SMPTE DCP is bad. In fact, it’s necessary. But the ideology behind the management of transition to SMPTE DCP poses real risk to success. The challenge of upgrading technology at the distribution level cannot be overestimated. One way of better managing the transition to reduce pain is to pursue Track File Prioritization (discussed in this publication and in another publication). But ideas such as this have no merit until there is pain, and the pain has only begun.
