View Bug Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002443 | DCP-o-matic | Bugs | public | 2023-02-11 23:09 | 2023-12-31 03:45 |
Reporter | mhm | Assigned To | carl | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | resolved | Resolution | fixed | ||
Target Version | 2.16.51 | ||||
Summary | 0002443: Always make 8 or 16 channels in mxf audio files | ||||
Description | Both Netflix (https://partnerhelp.netflixstudios.com/hc/en-us/articles/4417542010387-Digital-Cinema-Package-DCP-Specifications-Requirements ) and Deluxe ( https://hpaonline.com/wp-content/uploads/2022/07/Deluxe_Source-and-DCP_Delivery_Specifications_v5-11_20220314-2.pdf ) mandates to produce either 8 or 16 channel audio mxf files only (and pad with silence "black" audio). [Deluxe]: "Audio MXFs shall always have number of tracks in multiples of (2). For combining with other pre-existing [Netflix]: "Audio MXF files must always have an even number of tracks (i.e. divisible by 2). Audio MXF must have either (8) or (16) channels, with unused channels containing silence/MOS." Does DoM currently do this, or does it produce a six channel audio mxf for a 5.1 sound track? Best, | ||||
Tags | No tags attached. | ||||
Branch | |||||
Estimated weeks required | |||||
Estimated work required | Undecided | ||||
|
DoM currently makes a 6-channel MXF for 5.1. I don't understand what Deluxe means by "for combining with other pre-existing elements and/or reels". Do you understand it? This Netflix constraint also seems strange: "Audio MXF files must always have an even number of tracks (i.e. divisible by 2). Audio MXF must have either (8) or (16) channels, with unused channels containing silence/MOS." What's the difference between a track and a channel here? |
|
I believe that HI/VI on channel 7/8 is more ore less mandatory in North America. I think (but I may be wrong) that Deluxe means that because of this you should always use 8 or 16 to be able to combine mxf files/reels that do not contain anything in channels 7/8. Also the same applies to be able to merge with mxf files not containing Dbox, sign language etc.. (eg distributor logos etc). In the Netflix case I think track and channel are used to interchangeably to mean the same thing. At least Deluxe got A LOT of field experience of what works and do not work. So even if we don't know the exact reasons it may be sound advice to always make 8 or 16 channel audio mxf i DoM and pad unused channels with silence. Or what do you think? Best, |
|
Possibly also related to issue 0002393 When reading section A.1 of ST 429-2:2020 you could interpret WTF (Configuration 4) that it indeed requires all 16 channels to be present. Both Deluxe and Netflix seem to agree thoug that either 8 or 16 channels is ok. (Or maybe I am reding it wrong...) Also Deluxe says in their document: 3.4.3 AUDIO FORMAT |
|
I don't think any of this is really clear, to me at least. Perhaps the best we can do is see what passes "validation" by the latest Easy DCP version, since that's what everyone seems to be using for "QC" anyway. It would be easy enough to always use 8 or 16 channels, and I guess relative to the video file it's not a terrible waste of space. |
|
It looks like either Deluxe copied Netflix's "guidelines", or the other way around, since they both have this weird statement about MXFs having an even number of tracks, and also having either 8 or 16 channels. |
|
In SMPTE mode we now always write 16 channels since bb1c1b89260cf36c621f7f2b471eb23f2ff15b0c |
|
Maybe change these to only make 16 channels when there is audible information on any of channels 9-16, and otherwise make 8 channels? I thinkt it is a bit superflous to always make 16 channels. Also, this is how most of the big labs do it in my experience. |
|
|
|
The thread linked above gives a pretty good summary of the arguments against always writing 16 channels
|
|
Maybe the compromise I mentioned above is a way forward? I.e. either 8 or 16 channels. But only 16 channels when some of the channels 9-16 are actually used. Indeed all 7.1 DCPs I have seen have 16 channels (with unused padded with silence). The number of channels I have seen in DCPs in the Wild: 2: Stereo, not OK. But mostly works Eliminating the first to, and use 8 or 16 "dynamically" is a good compromise in my opinion. |
|
It might be the best way. If we did this I guess the DCP channels drop-down would be used to select the number of actual MXF channels. I think this is still useful, if only to decide how many channels are offered for mapping in the audio matrices. |
|
@carl branch channels-again respects the user's choice. |
|
To clarify, am I right in thinking the policy is now:
From observation, I think that's what's happening in DOM 2.16.65. But just wanted to check I have this right. |
|
@mhm One question: You say above "2: Stereo, not OK. But mostly works". I'm interested by the word "mostly". Do you have any in-the-field experience where a 2 channel DCP failed to play back correctly? I think we saw that problem once, but it was hard to disentangle whether the 2 audio channels was the root cause, as there may have been other problems with the DCP or the venue's projection equipment. I ask because it's not uncommon to receive 2-channel DCPs (Resolve produces them, for example if the source is stereo) and am wondering if they should be rejected / rewrapped. |
|
@overlookmotel your observation about 2.16.65 is correct. |
|
Thanks @carl. |
|
@overlookmotel Sorry for the late reply. No, I have actually not seen any problems with this in the field. I mostly handle 2-channel DCPs at festivals and am also very careful to update all equipment to the latest firmware. But I am always a bit nervous when receiving 2-channel DCPs because then the risk of something else being wrong is definately higher.. |
Date Modified | Username | Field | Change |
---|---|---|---|
2023-02-11 23:09 | mhm | New Bug | |
2023-02-11 23:19 | carl | Assigned To | => carl |
2023-02-11 23:19 | carl | Status | new => feedback |
2023-02-11 23:19 | carl | Note Added: 0005470 | |
2023-02-11 23:20 | carl | Note Edited: 0005470 | |
2023-02-12 02:17 | mhm | Note Added: 0005471 | |
2023-02-12 02:17 | mhm | Status | feedback => assigned |
2023-02-12 03:28 | mhm | Note Added: 0005472 | |
2023-02-12 13:53 | carl | Note Added: 0005482 | |
2023-02-12 13:54 | carl | Note Edited: 0005482 | |
2023-02-12 13:54 | carl | Relationship added | related to 0002393 |
2023-02-12 13:56 | carl | Note Added: 0005483 | |
2023-02-25 23:39 | carl | Target Version | => 2.16.45 |
2023-02-25 23:39 | carl | Estimated work required | => Undecided |
2023-03-03 22:51 | carl | Target Version | 2.16.45 => 2.16.46 |
2023-03-05 20:36 | carl | Target Version | 2.16.46 => 2.16.47 |
2023-03-08 00:27 | carl | Target Version | 2.16.47 => 2.16.48 |
2023-03-15 15:45 | carl | Relationship added | related to 0002487 |
2023-03-23 20:24 | carl | Target Version | 2.16.48 => 2.16.49 |
2023-03-27 18:36 | carl | Target Version | 2.16.49 => 2.16.51 |
2023-03-29 19:28 | carl | Status | assigned => resolved |
2023-03-29 19:28 | carl | Resolution | open => fixed |
2023-03-29 19:28 | carl | Note Added: 0005593 | |
2023-06-21 05:12 | mhm | Note Added: 0005768 | |
2023-07-25 10:05 | carl | Note Added: 0005857 | |
2023-07-25 10:09 | carl | Note Added: 0005858 | |
2023-07-25 11:49 | mhm | Note Added: 0005859 | |
2023-07-25 11:59 | carl | Note Added: 0005860 | |
2023-07-25 12:00 | carl | Note Added: 0005861 | |
2023-10-14 12:56 | overlookmotel | Note Added: 0006008 | |
2023-10-14 13:03 | overlookmotel | Note Added: 0006009 | |
2023-10-14 22:25 | carl | Note Added: 0006012 | |
2023-10-15 20:08 | overlookmotel | Note Added: 0006019 | |
2023-12-31 03:45 | mhm | Note Added: 0006171 |