>I haven't worked enough with S377m to really know, but I do know it's a mess. >Is there a way to differentiate "regular" packed 20-bit audio from S377m in >wav? > >/Tomas
There is a relevant overview of S337m in this dolby paper: https://developer.dolby.com/globalassets/professional/dolby-e/dolby-e-tech-doc_1.2.pdf Page 25, one can read: SMPTE 337M is the primary method by which Dolby E is able to work in existing facilities and with existing devices. The standard is written such that the same AES3 interface can be shared with the normal PCM audio usage either by treating the AES3 channels independently or by alternating between data and linear PCM usage. Devices that are specifically designed for SMPTE 337M/Dolby E compatibility should be able to transition easily between both usages. The whole design is to not signal, not differentiate "normal PCM audio usage" from s337m. And indeed, manufacturers have implemented probing in all their hardware/software (be it linear/SDI input, or mxf/wav files input etc.). Note: ARD/ZDF mxf file format being "the" world exception here, as dolby_e/non-pcm must be signaled, made explicit: https://www.ard.de/ard/die-ard/ARD-ZDF-HDF02a-AVC-I-100-1080i-25-8-Audio-Tracks-100.pdf In ffmpeg, we already have spdif probing in wav, so there is nothing really new technically speaking. Quoting the previous dolby paper, about spdif (IEC61937): The IEC61937 format is similar to the SMPTE 337M format and can be considered a subset of SMPTE 337M for some data types (see SMPTE 337M Section 7), however there are significant differences in the two standards. In particular IEC61937 does not support the Dolby E data type. Nicolas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
