FFAStrans forum

Dear all,

we currently play with the thought if it makes sense to introduce Dolby-E decoding support. (currently ffmpeg can only decode it but not encode)
For anyone who does not know what it is, it's a very special audio Codec (which hides itself in 2 PCM tracks) that you usually only find in Broadcasters native files, no end customer will ever need to deal with it. So, in case you need DolbyE support, you should "know" it already.

If anyone needs that, please try if the following workflow basically fulfills your needs or tell us what is missing.
The workflow is designed to just decode any Dolby E "track" that is in the source file. It should not matter at all which track/channel layout your sourcefile has got originally.
For Example, if you have xdcamhd, 8 tracks each 1 channel, and dolbye is on 3+4, the original channel 3+4 is replaced by the 6 decoded ones(or less or more channels, depends on your dolby configuration). It would "move" the original channel 5+ to a later position.

For Playing, you can replace the xdcamhd encode processor in this workflow by whatever you like, filters, audio mappers, etc... But you should not touch any existing processor before the xdcamhd proc. Thanks in advance!

The only time I ran into Dolby-E in our plant was for satellite backhaul transmission. I think we pulled out our Dolby-E decoders, they took the "fake" Dolby-E PCM stream and turned it into discreet AES pairs that other equipment could use, probably ten or more years ago. Dolby-E was a great way to sneak 5.1 sound through encoders and decoders that, back then, charged a premium for adding extra audio channels, especially on the encode side. And woe unto anyone who plugged that Dolby-E stream into an audio monitor's PCM port, what a god awful noise. I don't recall ever running across Dolby-E in the file delivery world. A really long way of saying, that this is very cool but I'm not sure I see the real world application for it. Just my two cents!