DCP-o-matic

Hi,

Thanks for the note - I'll fix that (here's a bug report).

It's interesting that you see 5.1 DCPs being made with 8 channels instead of 16. I've not been able to find a reliable reference for this need to add extra empty channels to a DCP - do you have one?

Thanks again,
Carl

I think the major issue here is the common workflow to create 7.1, HI+VI-N, and ATMOS VFs. So they just settle with one common denominator for the channel count that covers all VF types. This is also important for inserts, which need to have the same number of audio channels. I guess they just use a common channel template to make sure their projects fit these needs. However, that is a workflow issue, not a SMPTE standard requirement.

I find it strange that the outcome of all these special audio capabilities that were added with the SMPTE DCP now would result in a situation where all SMPTE DCPs need to carry 16 (mostly silent) audio channels. Add to that the fact that ATMOS DCPs should not carry any audio in main audio, which would mean: 'Yeah, you need to have all 16 audio channels in a SMPTE DCP, but don't put anything in them other than silence or ATMOS TC'. I want Interop back.

I think the major issue here is the common workflow to create 7.1, HI+VI-N, and ATMOS VFs. So they just settle with one common denominator for the channel count that covers all VF types. This is also important for inserts, which need to have the same number of audio channels.

I totally agree with what Carsten said.
Congratulations for all your work Carl, even if on my side I use my own tools also based on ffmpeg, asdcplib, OpenJPEG, ImageMagick and .Net framework.

Attached the CPL of 'Babylon' EN-FR 5.1 and 7.1 to give you an idea of type of wrapping

Thanks for the note StephW999, this should be better in 2.16.53.

2.16.53 : this version is very good, no errors in the cpl. all package is smpte Bv2.1 compliant
Thanks !

Thanks for checking it out!