DCP-o-matic

Hello,

When creating a SMPTE DCP, it appears be using a version of SMPTE that adds in a lot of metadata. Is there a way to use SMPTE A which doesn't try to define as much metadata? We are working with getting a trailer through QC at Deluxe and they keep rejecting it because of metadata issues. They recommended using SMPTE A to help avoid it.

Thanks!

Which version of DCP-o-matic are you using? DCP-o-matic tries to be RDD52 compliant, and that should be more relevant than the outdated ISDCF SMPTE test versions.

Can you be more specific towards the complaints? In my opinion, their so called QC simply want's to drive clients towards using THEIR mastering services, as open software is in conflict with their business model. We get these complaints here all the time.

I totally agree that it part of their business model. They did tell us to do SMPTE A if we can to avoid metadata that doesn't conform to "DCI" standard. So I was just curious if that was still an option to make a SMPTE A DCP instead of a SMPTE B DCP. Thanks!

I added an advanced option in the latest version (in the "non-standard") tab to alllow use of SMPTE Bv2.0 (which should remove the MCASubDescriptors stuff) but I have one report that using this makes "verification" fail on Easy DCP with a different error.

If anyone has Easy DCP and some time to help debug this, let me know!

I can't believe that creating Bv2.0 solves any issue with Deluxe or any other commercial mastering service. That may have been a useful option 3-4 years ago, but Bv2.1/RDD52 is the only way to go now.

Wondering - do we issue hints for any of those 'strange' advanced settings when used? I think we should always remind people about them. Also, verification in DCP-o-matic player should issue a warning.

hi Carl, Carsten

For SMPTE-A ;
You just have to delete the paragraph " <meta:ExtensionMetadataList>
In the cpl, and and write only this :
Exemple :
...
<meta:CompositionMetadataAsset xmlns:meta="http://www.smpte-ra.org/schemas/429-16/ ... L-Metadata">
<Id>urn:uuid:19bd5820-987d-4418-8002-014fc7cab5b5</Id>
<EditRate>25 1</EditRate>
<IntrinsicDuration>384</IntrinsicDuration>
<meta:FullContentTitleText language="en-US">test47</meta:FullContentTitleText>
<meta:ReleaseTerritory>001</meta:ReleaseTerritory>
<meta:VersionNumber status="final">1</meta:VersionNumber>
<meta:Chain>All</meta:Chain>
<meta:Distributor>STEPH</meta:Distributor>
<meta:Facility>DCPOMATIC</meta:Facility>
<meta:Luminance units="foot-lambert">14</meta:Luminance>
<meta:MainSoundConfiguration>51/L,R,-,-,-,-</meta:MainSoundConfiguration>
<meta:MainSoundSampleRate>48000 1</meta:MainSoundSampleRate>
<meta:MainPictureStoredArea>
<meta:Width>1998</meta:Width>
<meta:Height>1080</meta:Height>
</meta:MainPictureStoredArea>
<meta:MainPictureActiveArea>
<meta:Width>1920</meta:Width>
<meta:Height>1080</meta:Height>
</meta:MainPictureActiveArea>
</meta:CompositionMetadataAsset>
</AssetList>
</Reel>
</ReelList>

I can't believe that creating Bv2.0 solves any issue with Deluxe or any other commercial mastering service. That may have been a useful option 3-4 years ago, but Bv2.1/RDD52 is the only way to go now.

It's mostly to try and debug/get to the bottom of these complaints from "QC" runs about the MCASubdescriptors, which AFAICS are part of Bv2.1 but not Bv2.0. It seems like these things are currently causing DCPs to be refused by distributors. It might be best just to rent EasyDCP for a month and try to get to the bottom of what they are doing, at least (as it seems a popular choice for checking DCPs).

Sigh. I thought we were safe with RDD52.

I could easily be confused. It's hard to work out what's going on between different Easy DCP versions and awkward distributors.

Hi Carl,
you should make a comboxbox to choose smpte-A (not Bv2.0) and Bv2.1
For Smpte-A do not put xml tags and nodes "<meta:ExtensionMetadataList>"... in the cpl.
Keep audio configuation :4 without mca like the mode Bv2.0 in dcp o matic does.
and then EasyDCP will be happy

Stéphane W.