DCP for Cannes Film Festival

[carl]

I don't remember hearing anything further about this. It's fairly common practice to blame DCP-o-matic (or other free software) for everything that's wrong in the world.

We can try to stop DCP-o-matic making "bad" output, either by just forcing things, or by nudging/giving hints to the user. But there's always a way to screw things up...

I guess a major part of the problem is that DCPs are complicated and often handled by people who haven't got the time/inclination work out what's really wrong when something bad happens. The easy way out is to blame DoM or whatever and move on.

I don't have an answer, sadly.

[gunnar]

I am one of them that have being on the both side.
I did work full time as projectionist for 14 years before I left that job and now I run digital cinema and subtitling lab.
I own both Dolby CineAsset, EasyDCP and I have also being DCP-o-Matic user for long time. It was even named DVD-o-Matic when I used it first.

That said having worked as digital cinema (and 35mm) projectionist/technician for 14 years and also used CineAsset, EasyDCP and DoM I can confirm that DCP-O-matic can create very good DCPs that work without any problem.

But over the years when I have been receiving DCPs from others to screen it in cinema then I can also confirm that 90% of the problematic DCPs are made with DCP-O-MATIC but that has nothing to do with the software. The problem is always that the user that created the DCP don't know what he was doing and therefor messed up the DCP creation.
That very same user would also totally mess up the DCP creation if he would use CineAsset.

So when film festival is rejecting DCP just because it is made with DCP-O-MATIC then they are not saying that the DoM is bad. This is more likely to be statement "please do not waist our time by delivering DCP that has technical problems"

And when you receive 5 DCPs and someone will ask "Two of them are badly made, but 3 of them is good. Guess what DCPs it is that ar bad.
It is easiest bet to assume that the DoM DCPs are the bad once, not because of the software. More because it is more likly that the one who don't know that he is doing is using Dom rather than the very expensive CineAsset.

[carl]

It's a very good point. I'm always interested in hearing about ways that DoM-made DCPs are bad, so that we can think about ways to stop it happening! Feel free to share any experiences!

I can certainly understand the pragmatism of just refusing DoM-made DCPs, and I wouldn't add features that would make that difficult (e.g. trying to conceal the tool that made the DCP).

I hope that overall DCP-o-matic solves more problems than it causes, but perhaps that's not the case. Maybe for every film that wouldn't be on the screen without DCP-o-matic, there's another that would be on the screen if DCP-o-matic hadn't existed.

[IoannisSyrogiannis]

Well, I think it would be both educational and entertaining to pin a subject by the name "how wrong things can go with DCP creating".

Yet, since the "DCP-o-matic" board, sub-board of "General" is "Anything and everything to do with DCP-o-matic" maybe that can be another sub-forum, where we can share experiences that include other software as well, which doesn't need to be named.
I, for one, would be able to share examples of DCPs created from freeware, like DCP-o-matic, to software and hardware valued tens of thousands of dollars/euros/pounds.

[carl]

That sounds like an interesting idea... I added a new forum for that - let's see if it's useful!

[IoannisSyrogiannis]

It seems that it is for the privileged.
It didn't let me see it's contends.

[carl]

Sorry, I think it's fixed now...

[macuser]

I would like to tell a 'different' story with DCP-o-matic. I am too work for a filmfestival and started to use opensource software for DCP creation right at the beginning - that was more that 10 years ago. There was not so much information at that time and I started to write everything down that I could find about creating DCP's. The filmfestival I work for uses an unique process in ingesting ALL the DCP's before the festival starts.....

With every year we got more DCP's and many of them were created with DCP-o-matic and other software or even plug-in's. In our experience we noted that most problems we had with DCP's were created with the plug-in ones and NOT with DCP-o-matic! Everytime we had a problem with a DCP we responded to the creator of the DCP with a note telling them what was 'wrong' and how they should proceed next time....

Sharing knowledge gathered over time was and is the key in our case and in these 10 years we had never ever one DCP that did not work. Just to give you an idea of what I am talking about: The festival shows between 220 and 280 DCP's each year and the copy process for all the screens - 9 to be precise plus 3 back-up systems - copies around 40TB of data every year - in around 15 day's by one person.

The complete process is more complex than that what I wrote above but it works very well.

Kind regards
Max

[Carsten]

The fundamental thing about DCP-o-matic is, at least since many years now, and, leaving out the occasional bug (which occurred mostly in test versions, not release versions), is that the 'inner working' of DCP-o-matic makes sure that the DCP created is always formally correct, which means, it will play on every server without technical issues. That is a very strong point for DOM, and I can assure you from the occasional intense nightly email exchange with Carl that whenever we noticed an issue that could be the reason for formally incorrect DCPs being created, that Carl was extremely concerned and engaged to analyse the issue, find and eradicate a potential issue as fast as possible.

Now, if users put the wrong audio in the wrong channels, stretch their video, introduce unnecessary black parts, use wrong color conversion, create bad names, etc. - that is actually their business and DCP-o-matic can only prevent this to a certain extent. No software can detect wether a left audio track is wrong in the right audio channel. DCP-o-matic helps as much as possible by making careful decisions (e.g. file naming, aspect ratio), but always allowing manual overrides (and even using bad manual overrides will still create a formally correct DCP). I think that makes it very different from many other solutions that existed and exist.

I remember some non-commercial and even commercial (Adobe!) DCP solutions that simply used any source or timeline pixel dimensions as DCP container sizes - you were actually able to create a DCP with a VGA (640/480) container with that software! Some software simply passed 16 Bit audio at 44.1 KHz into the audio MXF.

DCP-o-matic prevents all this from happening, but the user still needs a minimum of knowledge to create a 'proper' DCP. Anyone being able to actually use a video editor SHOULD have the necessary technical skills, they just need to make themselves familiar with some DCP constraints. Using a video editor is MUCH more complicated than to use DCP-o-matic to create a proper DCP.