About Dolby Atmos in Dcpomatic

[carl]

OK, looks like it should work. Could you send me the metadata.xml from your project and the XML files from the DCP you made? carl@dcpomatic.com

[IoannisSyrogiannis]

Given that the result was two IAB MXFs and that cropping was necessary, my first guess would be it wouldn't work.
edgecode, I wonder if the timeline you are sharing is the same of your original project and if the setting was already „split by video content“.
Unless there is a bug there in relation to reels, I don't see how the whole thing would result in two IAB files.

Again, as DCP-o-matic can not manipulate the duration of IAB files without rendering them unusable. Altered (trimmed) IAB files won't work.
The originally produced files should be used in their entirety. Have a look on the previous posts of the thread and explore the threads from the links there. They will help with questions and shed some light on where DCP-o-matic stands with DCI IAB files.

[carl]

We found that the lack of reels is a bug in DCP-o-matic. Do we know for sure that trimming these MXFs is not possible?

[IoannisSyrogiannis]

There is that (adapted) quote from my earlier post in this thread that implies that (unless DCP-o-matic being able to can create theatrical IAB files):

First Frame specifies an edit unit for alignment with the beginning of the associated image sequence of the picture track.
The value for First Frame is set during initial bitstream coding and should not be changed.

To be honest, I don't remember exactly where I got the idea from, but I probably read it somewhere here, that DCP-o-matic can use IAB (DCP) MXF files, but not edit them/re-wrap them. It's the whole deal, coming out of a renderer, or it's nothing. Not being able to chop the start of the file is a fact. Not being able to chop the end..., I can't provide a source right now. I would be happy to be proven wrong, though...

[edgecode]

Why would DCP-o-matic need to modify ATMOS essence to trim it? Isn't CPL is just a playlist?

I opened the last DCP in EasyDCP Player 4.3.1 and IABs are playin in sync. Also the file sizes of ATMOS assets in DCP folder are identical to source so no modification happened.

The final test in the theater isn't happening for a few days but as of now everything looks promising.

[carl]

Why would DCP-o-matic need to modify ATMOS essence to trim it? Isn't CPL is just a playlist?

You're right, it doesn't need to, but it will. Due to some early design decisions it is awkward to change DoM to allow CPL trimming, though thinking about this now it actually might not be so hard to allow it in the case where you don't want to modify the asset (which is probably the most important case).

The tricky case is, for example, where you want to change the gain of an audio MXF and also CPL-trim it. Then DoM has to write the whole MXF, including parts which are not on the timeline. But maybe this isn't really much use!

[IoannisSyrogiannis]

I have been strangling with some software (not DCP-o-matic) for a number of hours now, and I might be missing the clarity to comprehend. So, please go easy on me, if I miss something already written.

I understand that re-writing the entirety of an MXF, including parts that are not heard or seen, is inefficient in some similar way that creating a 16-channel audio file out of a one or two channel(s) source just for EasyDCP not to complain is inefficient. (Maybe the latter is less troublesome, because there is no processing. But maybe it is equally painful, in the case you want to check loudness or validate that file.)

The word "tricky" intrigued me, though. Why is that case tricky?
Would that mean extra work on excluding unscreened parts from peak/RMS/loudness calculation? Or ~ complications on reels that are sharing different parts of the same MXF file?

[carl]

The word "tricky" intrigued me, though. Why is that case tricky?
Would that mean extra work on excluding unscreened parts from peak/RMS/loudness calculation? Or ~ complications on reels that are sharing different parts of the same MXF file?

It shouldn't be tricky, but the way the code is set up, it might be. At the moment, the code which "renders" the content creates some sound, and it gets mixed and ends up in the current reel. In this other case we might have sound coming from content A which ends up in the asset we're writing for the current reel, but then sound from content B needs to go some other asset. This might break a few long-held assumptions.

[IoannisSyrogiannis]

I which example, content A and content B that end up in different assets are different parts of the same file or (if manipulating a DCP) of the same MXF?

Do I understand correctly, that the "trap" may be that changes on the (entire) source file may take place that would end up to the resulting file without the user to have planned them, so issues with audio channel assignments, mixing, gain, re-sampling, color space changes, fade-in and -outs may spring out of "nowhere"?

Do I miss something else?