Hello.
This question is related to another thread I posted today, but it is different.
I was able to create a DCP with several CPLs (7.1 and 5.1 sound and subtitles). It also has several reels.
I imported it into DCPoMatic just to modify some metadata. I exported it again, but the new DCP created by DoM only has one CLP and one reel, meaning that it does not respect the CPLs or reels of the original DCP.
I wonder if there is any way for DCPoMatic to respect the original CLPs and reels when exporting a new DCP...
Any options I haven't found? Any way?
DCPoMatic does not respect structure of the original DCP
-
dcpforever
- Posts: 12
- Joined: Wed Jul 01, 2020 10:21 am
-
carl
- Site Admin
- Posts: 2909
- Joined: Thu Nov 14, 2013 2:53 pm
Re: DCPoMatic does not respect structure of the original DCP
Did you use the combiner tool to get your multiple-CPL DCP?
If so I would suggest editing the metadata with the editor tool. The main DCP-o-matic does not deal with multi-CPL DCPs very well.
If so I would suggest editing the metadata with the editor tool. The main DCP-o-matic does not deal with multi-CPL DCPs very well.
-
Carsten
- Posts: 3056
- Joined: Tue Apr 15, 2014 9:11 pm
- Location: Germany
Re: DCPoMatic does not respect structure of the original DCP
Well, first of all, DCP-o-matic is not a 'DCP-Editor'. You can do 'some' things, but digging into a multi-CPL structure for microinvasive changes is not it's intended purpose. Did you use DCP-o-matic main application, or the DCP-Editor module?
As for reels, you can tell DCP-o-matic to keep the original reel structure under 'reel settings'.
As for reels, you can tell DCP-o-matic to keep the original reel structure under 'reel settings'.
-
dcpforever
- Posts: 12
- Joined: Wed Jul 01, 2020 10:21 am
Re: DCPoMatic does not respect structure of the original DCP
Thank you for responding. To both of you.
OK. I see.
It would be to import the DCP and create four copies, each with a different CPL. And then combine the four DCPs.
As long as when importing the DCP you can specify which CPL to import... is that possible?
As for the reel, I was expecting something like ‘keep original reels’, so I guess it will be based on video content, right?
I didn't know that apart from DCO-o-matic main there was an editor. A player, yes, but not an editor.
As for the metadata I want to change, it's ‘ContentVersion Id’.
But I see that's not in the editor.
Thank you.
OK. I see.
It would be to import the DCP and create four copies, each with a different CPL. And then combine the four DCPs.
As long as when importing the DCP you can specify which CPL to import... is that possible?
As for the reel, I was expecting something like ‘keep original reels’, so I guess it will be based on video content, right?
I didn't know that apart from DCO-o-matic main there was an editor. A player, yes, but not an editor.
As for the metadata I want to change, it's ‘ContentVersion Id’.
But I see that's not in the editor.
Thank you.
-
carl
- Site Admin
- Posts: 2909
- Joined: Thu Nov 14, 2013 2:53 pm
Re: DCPoMatic does not respect structure of the original DCP
Yes, you can right-click a DCP in the content list and go to "Choose CPL..."
-
carl
- Site Admin
- Posts: 2909
- Joined: Thu Nov 14, 2013 2:53 pm
Re: DCPoMatic does not respect structure of the original DCP
You want to change the <Id> of the <ContentVersion>, or the <LabelText>?As for the metadata I want to change, it's ‘ContentVersion Id’.
But I see that's not in the editor.
-
dcpforever
- Posts: 12
- Joined: Wed Jul 01, 2020 10:21 am
Re: DCPoMatic does not respect structure of the original DCP
The ContentVersion ID, not the laberText
A distributor has rejected my DCP because the ContentVersion ID is incorrect. That's why I want to change it.
But I've run tests and DoM exports the DCP correctly. The problem is that it doesn't maintain the structure.
But if I export the four DCPs and combine them, that might work. I have to run the test.
A distributor has rejected my DCP because the ContentVersion ID is incorrect. That's why I want to change it.
But I've run tests and DoM exports the DCP correctly. The problem is that it doesn't maintain the structure.
But if I export the four DCPs and combine them, that might work. I have to run the test.
-
dcpforever
- Posts: 12
- Joined: Wed Jul 01, 2020 10:21 am
Re: DCPoMatic does not respect structure of the original DCP
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.
However, the Combiner Tool created the DCP by also doubling the image files, which are exactly the same.
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.
I don't think this is how the tool should work. If the image is the same, what is the point of duplicating the files, making the DCP twice the size?
Wait. I checked and they are not the same as the original. They are a different size than the original file, which means that DoM has not duplicated the file, it has modified it...
And I don't remember touching anything, just importing and exporting. If that's the case, shouldn't DoM use the same file, simply duplicating it?
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.
However, the Combiner Tool created the DCP by also doubling the image files, which are exactly the same.
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.
I don't think this is how the tool should work. If the image is the same, what is the point of duplicating the files, making the DCP twice the size?
Wait. I checked and they are not the same as the original. They are a different size than the original file, which means that DoM has not duplicated the file, it has modified it...
And I don't remember touching anything, just importing and exporting. If that's the case, shouldn't DoM use the same file, simply duplicating it?
-
IoannisSyrogiannis
- Posts: 349
- Joined: Mon Nov 13, 2017 8:40 pm
- Location: Iceland
Re: DCPoMatic does not respect structure of the original DCP
It seems to me that you could benefit from some digging on how to do what you are after. I, for one, am really not sure what that is.
Are you building upon an OV and want to keep that OV intact? Are you creating a new package, with newly made video, and want to make a multiple-CPL DCP? Something else?
In the two first cases, you should better keep an original video file and OV and create VFs. Then, combine.
Why is that? You write:
„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.“
If you have made two OVs, with different video files, even if not re-encoded, the files will be different. Will have a different checksum, because (besides the j2c images packed) the information there is different. Therefore, the image files will not be common on both CPLs. The combiner will not discard one of them, in favor of the other, and that is logical, since it won't check frame by frame if one video file is with burned-in subtitles and the other isn't, for instance.
The editor, on the other hand, is it now signing the PKL file, etc.?
If not, that could be a problem with the distributor's QC system, supposed that you were to use the editor.
Are you building upon an OV and want to keep that OV intact? Are you creating a new package, with newly made video, and want to make a multiple-CPL DCP? Something else?
In the two first cases, you should better keep an original video file and OV and create VFs. Then, combine.
Why is that? You write:
„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.“
If you have made two OVs, with different video files, even if not re-encoded, the files will be different. Will have a different checksum, because (besides the j2c images packed) the information there is different. Therefore, the image files will not be common on both CPLs. The combiner will not discard one of them, in favor of the other, and that is logical, since it won't check frame by frame if one video file is with burned-in subtitles and the other isn't, for instance.
The editor, on the other hand, is it now signing the PKL file, etc.?
If not, that could be a problem with the distributor's QC system, supposed that you were to use the editor.
-
dcpforever
- Posts: 12
- Joined: Wed Jul 01, 2020 10:21 am
Re: DCPoMatic does not respect structure of the original DCP
I am surely influenced by the way other programmes work. I only use DoM sporadically, to be honest.
What I want to do is create a new multiCPL DCP from one that has already been created. This is because the existing one is missing some markers and gives QC errors in some places, and DoM allows me to adjust them.
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.
What I want to do is create a new multiCPL DCP from one that has already been created. This is because the existing one is missing some markers and gives QC errors in some places, and DoM allows me to adjust them.
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.