A test and a question about thd+atmos decoding

[hellgauss]

I did some tests to try to understand how atmos works, and try to decode/downmix a correct 7.1 or 5.1 wav/w64 file from a thd audio with atmos. I started with the publicly available file .mkv here, which is tuned for 7.1.2: https://www.demolandia.net/downloads.html?id=5934347

Then I demux a test.thd audio with gMKVExtractGUI+MKVtoolnix, obtaining the following file

General
Complete name : I:\tmp\test.thd
Format : MLP FBA 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
File size : 380 MiB
Overall bit rate mode : Variable

Audio
Format : MLP FBA 16-ch
Format/Info : Meridian Lossless Packing FBA with 16-channel presentation
Commercial name : Dolby TrueHD with Dolby Atmos
Bit rate mode : Variable
Maximum bit rate : 6 027 kb/s
Channel(s) : 8 channels
Channel layout : L R C LFE Ls Rs Lb Rb
Sampling rate : 48.0 kHz
Frame rate : 1 200.000 FPS (40 SPF)
Compression mode : Lossless
Number of dynamic objects : 15
Bed channel count : 1 channel
Bed channel configuration : LFE

ReportBy : MediaInfoLib - v24.03

To convert to 7.1 with different methods i used, in windows10

set "name=test"

rem extract thd core from thd+atmos
ffmpeg -y -bitexact -i "%name%.thd" -bsf:a truehd_core -c:a copy -bitexact "%name%-onlycore.thd"

rem decode thd+atmos and thd files with ffmpeg to .w64
ffmpeg -y -bitexact -i "%name%.thd" -c:a pcm_s24le -bitexact "%name%-ffmpeg.w64"
ffmpeg -y -bitexact -i "%name%-onlycore.thd" -c:a pcm_s24le -bitexact "%name%-ffmpeg-onlycore.w64"

rem decode with drp to 7.1 trying 4 combination full+onlycore/presentation 8/16 (onlycore+p=16 does not work)

"C:\Program Files\Dolby\Dolby Reference Player\gst-launch-1.0.exe" --gst-plugin-path "C:\Program Files\Dolby\Dolby Reference Player/gst-plugins" filesrc location="%name%.thd" ! dlbtruehdparse align-major-sync=false ! dlbaudiodecbin truehddec-presentation=8 out-ch-config=7.1 ! audio/x-raw,format=S32LE ! wavenc ! filesink location="tmp_%name%-drp8.wav"

"C:\Program Files\Dolby\Dolby Reference Player\gst-launch-1.0.exe" --gst-plugin-path "C:\Program Files\Dolby\Dolby Reference Player/gst-plugins" filesrc location="%name%-onlycore.thd" ! dlbtruehdparse align-major-sync=false ! dlbaudiodecbin truehddec-presentation=8 out-ch-config=7.1 ! audio/x-raw,format=S32LE ! wavenc ! filesink location="tmp_%name%-drp8-onlycore.wav"

"C:\Program Files\Dolby\Dolby Reference Player\gst-launch-1.0.exe" --gst-plugin-path "C:\Program Files\Dolby\Dolby Reference Player/gst-plugins" filesrc location="%name%.thd" ! dlbtruehdparse align-major-sync=false ! dlbaudiodecbin truehddec-presentation=16 out-ch-config=7.1 ! audio/x-raw,format=S32LE ! wavenc ! filesink location="tmp_%name%-drp16.wav"

rem "C:\Program Files\Dolby\Dolby Reference Player\gst-launch-1.0.exe" --gst-plugin-path "C:\Program Files\Dolby\Dolby Reference Player/gst-plugins" filesrc location="%name%-onlycore.thd" ! dlbtruehdparse align-major-sync=false ! dlbaudiodecbin truehddec-presentation=16 out-ch-config=7.1 ! audio/x-raw,format=S32LE ! wavenc ! filesink location="tmp_%name%-drp16-onlycore.wav" - THIS DOES NOT WORK!

rem convert drp output to w64-24bit and remap channels
ffmpeg -y -bitexact -ignore_length true -i "tmp_%name%-drp8.wav" -c:a pcm_s24le -af "channelmap=0|1|2|3|6|7|4|5" -bitexact "%name%-drp8.w64"
ffmpeg -y -bitexact -ignore_length true -i "tmp_%name%-drp8-onlycore.wav" -c:a pcm_s24le -af "channelmap=0|1|2|3|6|7|4|5" -bitexact "%name%-drp8-onlycore.w64"
ffmpeg -y -bitexact -ignore_length true -i "tmp_%name%-drp16.wav" -c:a pcm_s24le -af "channelmap=0|1|2|3|6|7|4|5" -bitexact "%name%-drp16.w64"

del tmp*.*

From the test.thd source, this provided five .w64 output files with the same exact size.


test-drp16.w64 <--- This is same length but bit-different
test-drp8-onlycore.w64
test-drp8.w64
test-ffmpeg-onlycore.w64
test-ffmpeg.w64

Four out of five .w64 files are also bit-identical, the only one which differs is the one obtained with drp and atmos+presentation=16. Similar results have been obtained from a few full-length UHD movie audio tracks. Replacing "out-ch-config=7.1" with "=11" is bit-equivalent.

At first sight, opening presentation=16 with audacity shows no substantial difference with the other files.

For reference, I also extracted a 7.1.2 file, which is what the source was tuned for (I hope to swap channels correctly, I cannot test it)

rem convert to 7.1.2 for reference
"C:\Program Files\Dolby\Dolby Reference Player\gst-launch-1.0.exe" --gst-plugin-path "C:\Program Files\Dolby\Dolby Reference Player/gst-plugins" filesrc location="%name%.thd" ! dlbtruehdparse align-major-sync=false ! dlbaudiodecbin truehddec-presentation=16 out-ch-config=7.1.2 ! audio/x-raw,format=S32LE ! wavenc ! filesink location="tmp_%name%-drp712.wav

ffmpeg -y -bitexact -ignore_length true -i "tmp_%name%-drp712.wav" -c:a pcm_s24le -af "channelmap=0|1|2|3|6|7|4|5|8|9:7.1.2" -bitexact "%name%-drp712.w64"


As seen from audacity (see screen) the difference seems to be that the Ls+Rs channels are "splitted" in Ls/Tfl + Rs/Tfr

https://thumbs4.imagebam.com/74/3b/4d/MEWH604_t.jpg (https://www.imagebam.com/view/MEWH604)

MY QUESTION

Since with my audio hardware I'm not interested in the full spatiality of the Atmos but I'm quite satisfacted with a "standard" 5.1 ac3 downmix or maybe a 7.1 eac3, should I use ffmpeg (which is free) or drp+presentation=16 to decode to 7.1, or it is substantially equvalent? Which extra data Atmos contains that is extracted with presentation=16 ch=7.1 and not contained in the thd?

I imagine the following hypothetical example: I'm seeing a movie with Godzilla fighting vs Kong. Their audio is stored in the "standard" thd file as 7.1. During the fight a giant prehistoric mosquito is flying everywhere frightened. Perhaps both it's waveform and position metadata are stored in the atmos part? I'm not interested in the full spatiality of the mosquito, however I would like not to fully "miss" it's sound. Is it safe to extract the .thd core from the .thd+atmos, e.g. just like extract the lossy core from a lossless dts-hd-ma?

[tebasuna51]

As seen from audacity (see screen) the difference seems to be that the Ls+Rs channels are "splitted" in Ls/Tfl + Rs/Tfr

If you see the image in the mkv the Top channels seems Tsl-Tsr and not Tfl-Tfr (https://mediaarea.net/AudioChannelLayout)for that are mixed with Ls-Rs and not with L-R

(I hope to swap channels correctly, I cannot test it)
Yes they are correctly swapped. If you listen the mkv the time order is:
L,R,C,LFE,Ls,Rs,Lb,Rb,Tsl,Tsr
but in the wav file the visual order is FL,FR,FC,LFE,BL,BR,SL,SR,TFL,TFR
without exact equivalence to Tsl,Tsr

...should I use ffmpeg (which is free) or drp+presentation=16 to decode to 7.1, or it is substantially equvalent? Which extra data Atmos contains that is extracted with presentation=16 ch=7.1 and not contained in the thd?

Maybe the Dolby decoder do something different when first downmix to presentation 8 than do presentation 16 and after downmix to 7.1 but must be equivalent at all.

Is it safe to extract the .thd core from the .thd+atmos, e.g. just like extract the lossy core from a lossless dts-hd-ma?

It is more safe because the dts core is lossy and the thd core is lossless also.
Like you say ".w64 files are also bit-identical"

[Balling]

There is no need to use -bitexact for first command in ffmpeg.

format=S32LE as I was the one to suggest it originally... You realise TrueHD is only ever 24 bit? So need to downsample S32LE to S24LE with ffmpeg.

[tebasuna51]

BTW gst-launch-1.0 do not support 'format=S24LE':

"WARNING: erroneous pipeline: could not link dlbaudiodecbin0 to wavenc0, dlbaudiodecbin0 can't handle caps audio/x-raw, format=(string)S24LE"

we need ffmpeg to always downsample to 24 bit with rounding errors because the output S32LE have:

"The original audio track has a constant bit depth of 32 bits."

Then the output from gst-launch-1.0 is not lossless.

[hellgauss]

@Bailing
When doing this kind of tests i'm used to always put -bitexact option (both in input and in output) to reduce the possibility of different outputs. Perhaps there can be non determistic data in headers (e.g. timestamps), and even if it is not the case, better to add a little string than look for precise documentation.

The point of the test was not to check the bit-depth of atmos, nor to check if it is lossless (of course decoded-atmos is not lossless, since when decoded it loose positional metadata and is irreversibly tuned for a precise speaker setup)
The point and results of the test are:
- "Atmos part" is ignored with presentation=8, even by official decoders
- Most of all, I wanted to check if some important extradata are stored in the atmos part. I did not find a satisfactory answer and explanation, so I'll use presentation=16 for safety. Refer to the "mosquito" example in my OP.

To complete the post, I can notice that
- atmos.thd is 380MB, while onlycore.thd is 298MB (the same happens with movie tracks). I think the difference is too big to be only metadata. I read about a similar issue in DoVi. Some 4K blu-ray have the "standard" hdr stream with *very* poor quality with respect to the full DoVi. Indeed, the DoVi stream alone can be up to several Mbits in bitrate. In that case I use dovibaker to "mix" the two streams in a raw output: this should be in the same spirit as "downmix" to 7.1 with presentation=16.

[tebasuna51]

@hellgauss
My opinion is:
- "Atmos part" is ignored with presentation=8, even by official decoders
Then to obtain a standard 5.1 or 7.1 you can use a official decoder or ffmpeg with the same output
- Most of all, I wanted to check if some important extradata are stored in the atmos part.
Important to obtain any extra speakers output over 5.1/7.1, usseless for 5.1/7.1.
Of course 3D sounds ("mosquito") are incomplete but enough for 2D sound.
I think the downmix from presentation=16 to 7.1/5.1 can be worse than presentation=8

- atmos.thd is 380MB, while onlycore.thd is 298MB (the same happens with movie tracks). I think the difference is too big to be only metadata...

I don't think so. The TrueHD is lossless then the core have the exact channels 7.1.
Any extra data only can distort the original 2D audio.

[Balling]

BTW gst-launch-1.0 do not support 'format=S24LE':

"WARNING: erroneous pipeline: could not link dlbaudiodecbin0 to wavenc0, dlbaudiodecbin0 can't handle caps audio/x-raw, format=(string)S24LE"

we need ffmpeg to always downsample to 24 bit with rounding errors because the output S32LE have:

"The original audio track has a constant bit depth of 32 bits."

Then the output from gst-launch-1.0 is not lossless.

Yes, you will have to downsample it with ffmpeg. If it is just 24 bits in 32 bit container ffmpeg will remove zeros and you can get lossless data by getting back from 24 to 32.

[junh1024]

Dolby Designed DA to have backwards compatibility with std THD 71, so sound is never lost, just downmixed & maybe slightly lower volume. This also applies when listening to 71 on 51 speakers, no sound is lost, only downmixed & maybe volume.

As for extra data, the extra data is the differential to the DA presentation. If you were to decode DA then downmix that to 71, the result should be very similar , , as you are effectively discarding the differential . Why make it harder for yourself?

[Balling]

@Bailing
When doing this kind of tests i'm used to always put -bitexact option (both in input and in output) to reduce the possibility of different outputs. Perhaps there can be non determistic data in headers (e.g. timestamps), and even if it is not the case, better to add a little string than look for precise documentation.

.


Erm, timestamps are deterministic. You cannot remove editlists or non zero timestamp or VFR with bitexact. Bitexact if anything will make the precision of timestamps bigger...

[hellgauss]

@hellgauss
My opinion is:

Then to obtain a standard 5.1 or 7.1 you can use a official decoder or ffmpeg with the same output

Important to obtain any extra speakers output over 5.1/7.1, usseless for 5.1/7.1.
Of course 3D sounds ("mosquito") are incomplete but enough for 2D sound.
I think the downmix from presentation=16 to 7.1/5.1 can be worse than presentation=8



I don't think so. The TrueHD is lossless then the core have the exact channels 7.1.
Any extra data only can distort the original 2D audio.

Lossless does not mean exact, which is a vague concept. It means that there is a function, preferably invertible, which allows to reconstruct a specific input wav from the compressed file. It is like .wav.zip. Reversibility means that the ".zip" contains no extra information with respect to the wav, and it is a more subtle concept. Is thd core invertible? Can a specific .thd core be exactly reconstructed from a 7.1 wav?.

AFAIK the atmos part does not contain extra channels. It contains (extra?) objects, with position/velocity metadata to reconstruct a particular wavform for your speakers setup and exact position.

Focusing on the wav form of my last 7.1.2 example you see that the atmos part has informations either on how to "split" a channel in two (small metadata), or to "cancel" a channel and create two new ones (big data). How atmos works? If the mosquito is in the thd core, what happens if I want to "cancel/split" only the mosquito from 7.1 core and replace it with a full 3D mosquito in a 7.1.2 setup?

Also I briefly re-checked presentation=16 output. In some points there is a 1-2 ms shift in some audio channels (it is 30-50 cm at sound speed), so it may be some smart muxing algorithm which can takes into account speakers and source positions. It could be not neglectable in large cinemas setups.

Erm, timestamps are deterministic.
Some containers (I did not check if it is the case for wav and w64) allows to record the creation date/time in the header. I have hash function integrated with shell, so I simply ctrl-click File1+File2 --> Rightclick+Hash and check crc. This method does not work if timestamps are included in the files. I'm used to ALWAYS put -bitexact for safety, although it is not 100% safe since there can be many non-determinism causes.

[Balling]

Some containers (I did not check if it is the case for wav and w64) allows to record the creation date/time in the header. I have hash function integrated with shell, so I simply ctrl-click File1+File2 --> Rightclick+Hash and check crc. This method does not work if timestamps are included in the files. I'm used to ALWAYS put -bitexact for safety, although it is not 100% safe since there can be many non-determinism causes.


Wav only differs with name of library that wrote it and that is removed with bitexact, but maybe w64 it is more complex. You can just do -c:a pcm_s24le -f md5 -

You can also use beyond co pare to compare files byte by byte.

[Balling]

"To complete the post, I can notice that
- atmos.thd is 380MB, while onlycore.thd is 298MB (the same happens with movie tracks). I think the difference is too big to be only metadata. I read about a similar issue in DoVi. Some 4K blu-ray have the "standard" hdr stream with *very* poor quality with respect to the full DoVi. Indeed, the DoVi stream alone can be up to several Mbits in bitrate. In that case I use dovibaker to "mix" the two streams in a raw output: this should be in the same spirit as "downmix" to 7.1 with presentation=16."

Yes, DoviBaker can restore 12 bit stream in 16 bit container, in some cases FEL has also 4000 nits, maybe some problems with LMS color space still. Anyway, NO, you are wrong. Metadata in TrueHD is very high quality, for "lossless" https://forum.doom9.org/showthread.php?p=1914599#post1914599

The reason is explained here by Cavern author: https://www.audiosciencereview.com/forum/index.php?threads/atmos-finally-decoded-in-pc-mac.32351/page-12#post-1420126

[hellgauss]

Thanks for refering VoidX discussion. There is a nice post at page 10 https://www.audiosciencereview.com/forum/index.php?threads/atmos-finally-decoded-in-pc-mac.32351/page-10 . I refer to question from a user with MY EXACT SAME issue (#183) and voidX answer (#194). Perhaps the discussion is on DD+ and Atmos, but should apply also to thd.

Quote from voidX answer:
There is a funny addition to this question. When you decode the PCM data of Dolby test tones, the levels are off, one of the surrounds is mixed at a seemingly random gain. Applying Atmos metadata fixes this, the test tones are the same level after remixing it from 5.1 to 5.1.

If I understood well, better keep presentation=16 and downmix using official tools. This is not surprising since the 7.1 core, which is basically compressed-pcm, should be optimized to be somewhat easily "extended/replaced" by the object layer without doing mess.

[Emulgator]

That confirms my darker assumptions.
First the keymaker seeks his gain in adding a layer to "improve things" from a base product
(first with DV: add a layer with half resolution (I call it "DV backlight" stream) to add the delta of 10 bit to 12 bit. Fine.
Now noone can keep him from intentionally make the base layer mediocre in a pattern only he can define.
Only paying and adding the proprietary enhancement layer will be able to compensate that.
Looking at GPS scrambling that was there for ages, miltary devices had the keys and algos to unscramble, no civil use possible.
As soon as clever minds had that scrambling muted, civil use gained traction.
Now lets assume what happens if scrambling is active again...

[tebasuna51]

If I understood well, better keep presentation=16 and downmix using official tools. This is not surprising since the 7.1 core, which is basically compressed-pcm, should be optimized to be somewhat easily "extended/replaced" by the object layer without doing mess.

If I understood well your comment, the 7.1 core of thd Atmos is intentionally a wrong downmix to 2D from the full 3D sound.
It is a harsh accusation.

Can a specific .thd core be exactly reconstructed from a 7.1 wav?.
Must be.

[hellgauss]

I do not think it is an accusation, since the only qualitative word I used are "better", "optimized" and *without* mess.

For lossy+lossless audio, such as dts-hd-ma with dts core, the core + lossless-correction is quite simple: create a lossy stream with less quality+bitrate for compatibility, store the corrections in the lossless part and perform a simple sum. For thd-core + atmos it is different.

Consider the mosquito object in my example. It should be included in the core, which is a 7.1 wav file, taking into account a lot of variables: volume and phase adjustment due to distance, perhaps also frequency change due to doppler effect. Then, for a full 3D audio, it should be removed from the core, and then added a gain with new parameters. You cannot simply "add" the mosquito to the core or to extra speakers. How this operation is performed? Which optimization steps are taken to create a core which is raw data for further complex processing? Why presentation=16 is different even with 7.1? What data/metadata is contained in the 82MB of the demo? What does VoidX comment means and implies?

They are a lot of question which make me think that it is better to keep as most informations as possible up to final downmix. Of course, while doing so, use ufficial tools, since they know what is happening.

[Balling]

Looking at GPS scrambling that was there for ages, miltary devices had the keys and algos to unscramble, no civil use possible.
As soon as clever minds had that scrambling muted, civil use gained traction.
Now lets assume what happens if scrambling is active again...



Are you being serious? The fact is it was not there for ages, Selective Availability was switched off on May 2, 2000. Not to mention the error was 50 m horizontally anyway. That is compared to 2.5 meters nowadays achieved only with dual frequency GNSS. If you want 1 meter accuracy you need triple frequency (only chinese satellites, GPS is subpar) carrier range ADR. If you need cantimeter you need Galileo high precision signal and DGNSS/PPP. If you need sub suntimeter accuracy you use Real time kinematics (RTK), but that needs some station and a rover.

Vertical accuracy is much worse and no one has M code access anyway, cause the MNSA keys are private. The code was reverse engineered though, but without keys it is useless. The fact is GPS M code is useless nowadays because laser weapons can just destroy GPS on the orbit.

[Balling]

"What does VoidX comment means and implies?"

I talked to him while we worked on cavern atmos decoder, what you read is outdated, e.g. we know that TrueHD does not store pure objects like in a cinema, but uses JOC, because Cavern can decode TrueHD atmos using JOC metadata from EAC3 track. This is what he told me on gmail:

VoidX: We don't even know what's in the TrueHD metadata, it's just gibberish to the E-AC-3 parser. E-AC-3 is optimized for a small size, while TrueHD isn't. It has a format favoring precision, unlike E-AC-3, which, for example, only has 32 object positions on each axis.

Me:


> probably has a format favoring precision, unlike E-AC-3, which, for example, only has 32 object positions on each axis.

Why would it? They both use spatial encoding.

VoidX: Yeah, but 5 bits are a bit slim for a position.

Me: Did not we agree on that you can use panning metadata from EAC3 on TRUEHD base layer decoded to wav?
So, I am going to play with TrueHD a little bit. I think you mentioned here that TrueHD metadata may be higher quality? Interesting, how do you know that? Maybe Huffman tables are just that good in EAC3? Also 5 bit is why X, Y, Z are not full precision?

https://www.audiosciencereview.com/forum/index.php?threads/atmos-finally-decoded-in-pc-mac.32351/post-1420126

VoidX:

> Interesting, how do you know that?

The answer is at the same topic. The size of the unknown Atmos metadata blocks can surpass 1 Mbit/s, which is more than the entire DD+ stream.

> Maybe Huffman tables are just that good in EAC3?

That wouldn't help, we're talking about a tenfold size difference.

> Also 5 bit is why X, Y, Z are not full precision? (This was talking about the XML atmos panning metadata, as in text of the panning metadata.)

Yes, that's not that much, not even comparable to the master. It doesn't really matter though, because it can be encoded as such that it's not audible. I personally wouldn't really care if all mixes were channel-based, that was the idea behind the current LAF.

[Balling]

If I understood well your comment, the 7.1 core of thd Atmos is intentionally a wrong downmix to 2D from the full 3D sound.
It is a harsh accusation.



Harsh accusation?? Objects are stored in the same stream with steganoraphy. This is no different from MQA first layer unfold that then contains 2nd layer filter unfold metadata that then contains 3rd level unfold round off metadata (this one is not really digital metadata, it is more complex), the first unfold is using meridian coding, as in the same MLP used in TrueHD. See https://code.videolan.org/mansr/mqa and https://code.videolan.org/mansr/mqa/-/blob/master/render-filters.txt?ref_type=heads for second unfold filters.

[tebasuna51]

But if the downmix to 2D 7.1 from presentation=16 is better than the used core, for what is not used that downmix to create the thd lossless core?

Users with AVR 7.1 without Atmos have a sound with less quality.

I have a AVR configured to 5.1.2 and with Atmos decoder, it is not a problem for me.
If I want a copy with less size and than can be used with a player than can't send thd, but yes EAC3, to my AVR (like my TV), I use presentation=16 output 5.1.2 and encode it to EAC3 5.1.2.

[hellgauss]

But if the downmix to 2D 7.1 from presentation=16 is better than the used core, for what is not used that downmix to create the thd lossless core?

Users with AVR 7.1 without Atmos have a sound with less quality.


Because the 7.1 core needs to be BOTH a downmix AND raw data for further processing. Note that this is not an answer, but an hypothesis, I have no documentation nor evidence.

Or perhaps the mosquito is also stored as a separate lossless object, so it can somewhat be removed from the core and added again for advanced setups. This hypothesis is also valid due to the large amount of extradata of atmos. This made the two options substantially equivalent, with some round-off errors due to calculations which I find acceptable at 24 bits.

@Balling
Objects are stored in the same stream with steganoraphy.
This is a very nice information indeed. Have you got official reference or evidence about it for dolby?

-----------------

A side but related story

About 20-25 years ago a friend of mine bought his brand new fantastic dolby digital surround system (actually: an all-in-one at the discount).

A weekend he invited me for pizza, and ask me to bring my [sci-fi dvd movie with lot of fx], so that we can have a movie night.

Despite my poor ears, I remember the very immersive sensation of surround audio, and also... incredible basses! I ask myself how the hell it is possible that this cheap subwoofer performs better than a mid-tier system? And I answered me that a subwoofer is optimized for bass, and perhaps my friend boosts its volume for coolness.

Only recently I discovered that standard 5.1-->2.0 downmix discards LFE. Now... I would not be surprised if the mosquito too is in the "LFE channel".

[Balling]

But if the downmix to 2D 7.1 from presentation=16 is better than the used core, for what is not used that downmix to create the thd lossless core?

Users with AVR 7.1 without Atmos have a sound with less quality.

I have a AVR configured to 5.1.2 and with Atmos decoder, it is not a problem for me.
If I want a copy with less size and than can be used with a player than can't send thd, but yes EAC3, to my AVR (like my TV), I use presentation=16 output 5.1.2 and encode it to EAC3 5.1.2.

All encrypted data in MQA or Atmos is there before the unfold removes them and places in correct places, in MQA it is worse because MQA has the "4th actual substream" (eqvivalent) placed in pcm samples too.

[Balling]

Only recently I discovered that standard 5.1-->2.0 downmix discards LFE. Now... I would not be surprised if the mosquito too is in the "LFE channel".


I mean not really: "Include LFE in stereo downmix" https://wiki.coreelec.org/coreelec:audio

The other 5 channels for 5.1 are supposed to contain the normal bass and the LFE contains "extra" for "booms & explosions", etc.

The little woofer in most systems isn't really a subwoofer...

A subwoofer dedicated LFE channel has its own so called cut off which is different for IMAX sound in DTS:X IMAX new standard of 2022. And there are also 2 LFE in DTS:X.