DCPoMatic does not respect structure of the original DCP

Anything and everything to do with DCP-o-matic.
barber
Posts: 63
Joined: Fri Apr 15, 2016 4:03 pm

Re: DCPoMatic does not respect structure of the original DCP

Post by barber »

IoannisSyrogiannis wrote: Fri Jan 16, 2026 12:01 pm The editor, on the other hand, is it now signing the PKL file, etc.?
Yep, Carl fixed that last October. Changing the ContentVersion ID by hand and then re-signing the DCP with Editor might work (?).

Anyway as Ioannis said combining an OV with VFs is the right way to go here.
IoannisSyrogiannis
Posts: 349
Joined: Mon Nov 13, 2017 8:40 pm
Location: Iceland

Re: DCPoMatic does not respect structure of the original DCP

Post by IoannisSyrogiannis »

dcpforever wrote: Fri Jan 16, 2026 12:34 pm [...]
For to make multiCPL DCPs, my main programme is CuteDCPTools. I simply duplicate the composition and change files or add subtitles. It's very simple.
I repackage it again and if I don't change the image (for example), it uses the same original file without duplicates.
[...]

It seems that DoM doesn't work that way. I thought it did because it seems logical that if I import and export a DCP without making any changes, the video and audio files should be the same, with new XML files.
It seems that this is not the case.
But the idea of combining OV and VF might work...
Thank you.
The main difference with DCP-o-matic (main) is that it doesn't consider a project as a potential number of CPLs that share essences. Each of its projects concerns a CPL, that in multi-CPL DCPs you may choose, to go forward.

So, keep the original, make VFs (for that specific CPL) and then combine the results.

There was an idea, brought up by Carl, about a change so that „a single project can produce multiple DCPs“, but that was not solidified nor in development for the time being.

Keeping the original file (when re-packaging), that is a potential choice, but it would need a number of „boxes“ to be ticked, so it would be safe and it would be doubtful if it would have been O.K. and it would have passed all the Q.C. tests. The MXF files created have metadata on their headers that are specific about when they were created, by what/whom, etc. Any change on those would ask for re-packaging.

I believe you can make DCP-o-matic work, but you will need to figure out how things are going to work. When we are working on a project, we often disregard what alternatives could be there that wouldn't allow us to keep it simple. (That's why bug trackers are a thing...)

@barber
Thank you for reminding me. I remember reading something about that, but I haven't used the tool for some time now and it didn't... register.
carl
Site Admin
Posts: 2909
Joined: Thu Nov 14, 2013 2:53 pm

Re: DCPoMatic does not respect structure of the original DCP

Post by carl »

I already did the test: the Combiner Tool does not work properly.

I exported two DCPs from DoM, from a multiCPL DCP, in this case one with 5.1 sound and the second with 7.1 sound. In other words, I exported two DCPs with identical image files in both, but different audio files.

The result of combining both DCPs should be a DCP with two CPLs, with only one image file and two audio files. This is logical since the image is common to both CPLs.
The combiner does not deduplicate, it just adjusts the XML as required and tries to avoid font clashes when merging two Interop DCPs with subtitles.
I compared the checksum of both files and it turns out that it is not the same. The size in bytes is the same, but not the checksum. So Combiner Tool exported a new image file with some differences.
This definitely should not happen - the audio and video MXFs should be bit-for-bit identical in the original and the combined DCP. I can't reproduce this bug though - does it happen every time for you?
carl
Site Admin
Posts: 2909
Joined: Thu Nov 14, 2013 2:53 pm

Re: DCPoMatic does not respect structure of the original DCP

Post by carl »

For to make multiCPL DCPs, my main programme is CuteDCPTools. I simply duplicate the composition and change files or add subtitles. It's very simple.
I repackage it again and if I don't change the image (for example), it uses the same original file without duplicates.
So in CuteDCP you can preview and edit multiple playlists? As Ioannis says, we've thought about that a bit but it's quite hard to imagine a user interface where this is possible without making the common case (a single CPL) more complicated or confusing than it already is.

Maybe if you import a multi-CPL DCP, or choose an option somewhere, the UI should change to offer multiple playlists (so you can edit and preview each one) and then we output a multiple-CPL DCP.
dcpforever
Posts: 12
Joined: Wed Jul 01, 2020 10:21 am

Re: DCPoMatic does not respect structure of the original DCP

Post by dcpforever »

So in CuteDCP you can preview and edit multiple playlists? As Ioannis says, we've thought about that a bit but it's quite hard to imagine a user interface where this is possible without making the common case (a single CPL) more complicated or confusing than it already is.
Well, CuteDCPTools isn't really a programme, it's an After Effects plugin.
It allows you to import DCPs into After Effects, where each CPL appears as an AE comp. Here you can view the DCP and make changes such as removing or adding image or audio tracks, adding subtitles, changing parts of the footage (such as headers), etc.
Once the changes have been made, it allows you to repackage the result, exporting a new DCP. It is very simple to use, the options are minimal but they are the important ones for editing a DCP.
And having a practical timeline helps a lot.
dcpforever
Posts: 12
Joined: Wed Jul 01, 2020 10:21 am

Re: DCPoMatic does not respect structure of the original DCP

Post by dcpforever »

This definitely should not happen - the audio and video MXFs should be bit-for-bit identical in the original and the combined DCP. I can't reproduce this bug though - does it happen every time for you?
As English is not my native language, I may not have explained myself clearly.
At first, I thought it was Combiner Tools that was duplicating the files, but then I wrote Wait.
Because I realised that it wasn't Combiner Tools, but DoM main that didn't export the same files when importing different CPLs. That's what I meant.
To confirm this, I just did a quick test. I have a DCP of a short trailer here, I imported the DCP into DoM and exported it again without changing anything.
It exports very quickly, but the result is that the video and audio files are different, they don't even match in size (there are bytes of difference).
DoM main does something to make them not be the same file.
StephW999
Posts: 70
Joined: Mon May 17, 2021 1:15 pm

Re: DCPoMatic does not respect structure of the original DCP

Post by StephW999 »

hello dcpforever
When you import a DCP into DoM and export it as a DCP, it re-wraps the assets into new MXF files. Therefore, these files will not have the same metadata and especially not the same UUIDs.

English is not my native language either.
dcpforever
Posts: 12
Joined: Wed Jul 01, 2020 10:21 am

Re: DCPoMatic does not respect structure of the original DCP

Post by dcpforever »

Yes, that's exactly what I'm saying. Other software allows copying, but DoM does not. I'm not saying it's good or bad.
Carsten
Posts: 3056
Joined: Tue Apr 15, 2014 9:11 pm
Location: Germany

Re: DCPoMatic does not respect structure of the original DCP

Post by Carsten »

It's simply a different purpose. DCP-o-matic always creates a 'new' DCP including all assets and metadata. This also makes sure the DCP is correct in all aspects. I understand it is not what you expect.
carl
Site Admin
Posts: 2909
Joined: Thu Nov 14, 2013 2:53 pm

Re: DCPoMatic does not respect structure of the original DCP

Post by carl »

We sort of go a little way down this route by re-using encoded JPEG2000 frames (unless you tick the "Re-encode" box). It doesn't seem to crazy to me to take one more step and re-use the whole MXF if possible.