ffmpeg ac3 built-in encoder quality ? [Archive]

pandy

25th June 2015, 07:57

-acodec ac3 will use floating point math, while -acodec ac3_fixed will use fixed point.
Yep, by default float ac3 encoder is used, integer need to be called explicitly but there is no 100% sureness as this is internal ffmpeg life - don't feel so advanced to verify real codec selection...

For sure there is something wrong with ac3 SNR implementation in ffmpeg - it is comparable to ancient mpeg 1 layer 2 (both codecs).

mp2 -ac 2 -b:a 192k
libtwolame -mode stereo -ac 2 -b:a 192k

they give similar SNR results when compared to ac3

I need sufficient SNR (100dB or more) as i need to create pure sine wave for measuring SNR in hardware device - you can't verify 24 bit DAC with 15 bit quality signal... (yes, frequencies are selected in a way to exploit unique characteristic of codec - so called critical frequencies to give pure spectrum).

tebasuna51

25th June 2015, 09:45

pandy

25th June 2015, 10:46

@pandy
Please explain your test to measure the SNR.
Is know than AC3 is not a lossless encoder, then I don't understand what is a 15 bit SNR.

Have you tried a commercial AC3 encoder?
What means "native ac3 encoder from Dolby providing over 20 bit accuracy"?
You say than is lossless until 20 bit?

Ok, i will try to explain but please accept apologies for my English.

For simple sine wave lossy encoding is quasi lossless - for example -20 dBFS 1kHz sinewave shall be lossless with exception related to level (i.e. it may be not perfect -20dBFS at the output as quantization is not uniform as LPCM but use semitresholds).

SNR quality od encoder is easy to measure - this is noise floor produced at the decoder side with assumption that decoder is bitexact (i can use native Dolby decoder which is part of Dolby test suite) - so based on this looks like noise floor for ffmpeg encoder is somehow limited to approx 15 bit.

Lossy encoding is only for complex spectral signal - sinewave should produce (especially with particular frequencies) very accurate lossy free function - DCT can be seen (in inverse DCT) as signal generator - similar concept as for vocoders (bank/set of bandpass filters) - output signal is re-synthesized combination of sinwaves.

To verify dynamics i use Dolby test streams called:
2_aswp4ka.ac3 and 2_200a60.ac3.

Based on Dolby description:
2_aswp4ka.ac3 - 4 kHz sine wave amplitude sweep from 0 to –120 dBFS. 20-bit - Tests THD vs. Level at 4 kHz. Also used for linearity check.

2_200a60.ac3 - Single tone 200 Hz –60 dBFS. 20-bit precision. - These signals are provided to test the ability to decode to the correct spectrum with various input frequencies and levels. Additional uses are spot checking compression, distortion, or linearity.

So yes - i believe DCT coefficients should be accurate enough to provide more than 100dB precision (20 bit is approx -120dB and even going for audio safe 24 bit int everything should work correctly) and as such at the output noise floor shall be way better than -90dB.

Please remember that i'm talking not about complex spectral signal but pure sine which after DCT in special conditions will produce single value and this value feed to iDCT should provide exact (spectrally) sine wave (and there will be only PCM quantization problems).
--
Made some test:

@ffmpeg -f lavfi -i "sine=frequency=200:sample_rate=48000:duration=60,volume=-41.94dB,pan=stereo|c0=c0|c1=c0" -c:a pcm_s32le -y 200a60_ffmpeg.wav
@ffmpeg -i "200a60_ffmpeg.wav" -vn -c:a ac3 -b:a 192k -y 200a60_ffmpeg.ac3
@ffmpeg -i "200a60_ffmpeg.ac3" -vn -c:a pcm_s32le -y 200a60_ffmpeg_32.wav

and with sox

@set dyna=145
@set /a clut=%dyna%/5
@sox --multi-threaded --buffer 131072 -S -V -D %1 -n spectrogram -z %dyna% -w Kaiser -q %clut% -y 1025 -x 2048 -s -o %1_%dyna%.png stat stats -b 16

analyzed results:

http://s18.postimg.org/7liy3co3d/2_200a60_ac3_32_wav_145.png
http://s18.postimg.org/v9yfymkmx/200a60_ffmpeg_wav_145.png
http://s18.postimg.org/ulplfolx5/200a60_ffmpeg_32_wav_145.png

It looks like i was wrong - lopping inside ffmpeg is not bad but i have strange (significantly worse) results on real HW when comparing both streams....

tebasuna51

25th June 2015, 17:27

I don't know how you use sox to know SNR.

My test using your source and encoder:
ffmpeg -f lavfi -i "sine=frequency=200:sample_rate=48000:duration=60,volume=-41.94dB,pan=stereo|c0=c0|c1=c0" -c:a pcm_s32le -y 200a60_ffmpeg.wav
ffmpeg -i "200a60_ffmpeg.wav" -vn -c:a ac3 -b:a 192k -y 200a60_ffmpeg.ac3

To decode I use libav but with:
eac3to 200a60_ffmpeg.ac3 output.wav -full
To obtain the full native libav output 64 float.

Compared the output.wav with input 200a60_ffmpeg.wav the max differences are at -100.8 dB.

With Sonic AC3 encoder (max quality input 24 bit int), same decoder, the differences are at -94 dB. Seems ffmpeg is better with that sample.

Groucho2004

25th June 2015, 19:10

A little test I ran with SpectraPlus:

Source file is a 24 Bit 48 KHz PCM with a 0 dB, 1 KHz signal:
http://s22.postimg.org/nc9zr7zmp/pcm24.png

Convert to 192 Kbps stereo AC-3:
ffmpeg -i "pcm24.wav" -vn -acodec ac3 -ac 2 -ar 48000 -ab 192k "ffmpeg.ac3"

And back to PCM:
eac3to.exe "ffmpeg.ac3" "ffmpeg.wav" -down24

Result:
http://s15.postimg.org/6ogxmfb7v/ffmpeg192.png

Result with Aften:
http://s28.postimg.org/e0gglbb8d/aften.png

pandy

26th June 2015, 09:45

I don't know how you use sox to know SNR.

THis is simple - spectrogram shows levels as color - on right graph side there is stripe with colors and scale in dBFS - just compare color, black means there is floor (lowest possible scale value). Original pictures are bigger but after upload they was downscaled and as such blurry - not so important as they don't change overall result - seem that ffmpeg encoder use some loudnes contour and can provide more than 24 bit quality at parts where ear are the most sensitive.

However picture change with IMD stimulus (two high level sine waves separated by some fixed distance for example 1kHz - so for example 18 and 19 kHz - there is real mess on spectrum plot - but i need to try to play with lower level and see if this is maybe level related distortion or change frequencies - real frequencies are selected to be equal to critical layer II frequencies - in my case sine 17625Hz and sine 19875Hz - combined and limited to -3.103dBFS to avoid clipping in filter bank).

My test using your source and encoder:

To decode I use libav but with:
eac3to 200a60_ffmpeg.ac3 output.wav -full
To obtain the full native libav output 64 float.

Compared the output.wav with input 200a60_ffmpeg.wav the max differences are at -100.8 dB.

With Sonic AC3 encoder (max quality input 24 bit int), same decoder, the differences are at -94 dB. Seems ffmpeg is better with that sample.

Well, yes - thanks to loudness contour seem it is better...

Don't use float as my samples have fully predictable dynamics and INT are more stable than float - but once again - picture for IMD signal change dramatically - not sure if this is codec limitation or not - need to understand how AC-3 MDCT theoretically will affect IMD signal...
Sadly to say - HW is capable to accept PCM but SW support only MPEG 1 Layer II, AC-3, EAC-3 and AAC and freeware AAC is really disastrous on terms of the SNR.

nevcairiel

26th June 2015, 10:50

Note that sine waves are a bit special and a bunch of encoders behave a bit weirdly with them, since that's not what they are optimized for. Just something to keep in mind.

Ely

26th June 2015, 17:47

freeware AAC is really disastrous on terms of the SNR.

Even Fraunhofer FDK ? (libfdk_aac)

That's my go-to AAC encoder and I love it. Haven't done any SNR test on it though, only listening tests.

raffriff42

27th June 2015, 01:22

Haven't done any SNR test on it though, only listening tests.
No need to feel apologetic about that - it is how the codecs are developed in the first place. MP3/History/Development (https://en.wikipedia.org/wiki/MP3#Development) (wikipedia)
The song "Tom's Diner" by Suzanne Vega was the first song used by Karlheinz Brandenburg to develop the MP3. Brandenburg adopted the song for testing purposes, listening to it again and again each time refining the scheme, making sure it did not adversely affect the subtlety of Vega's voice.

OK that's MP3 - ancient history - but I doubt listening tests have been replaced as the final judge of quality. There are precise measurements being made in the development labs, certainly, but they have to do with auditory masking, response of the human ear, etc - psychoacoustics (https://en.wikipedia.org/wiki/Psychoacoustics). Measuring SNR while ignoring auditory masking will not tell you very much about how good the codec sounds.

Oh, BTW, the Hydrogen Audio wiki (http://wiki.hydrogenaud.io/index.php?title=AAC#Current) lists the following encoders in order, best to worst:
1. Apple AAC
2. Fraunhofer FDK AAC
3. Nero AAC
4. FAAC
5. FFmpeg/Libav AAC encoder

pandy

28th June 2015, 17:16

Note that sine waves are a bit special and a bunch of encoders behave a bit weirdly with them, since that's not what they are optimized for. Just something to keep in mind.

How they are special (except they are way simpler to encode)?

If your spectrum is simple and something wrong happen with codec this mean that your codec design is faulty...

Sine wave is same signal like other - main difference is that MDCT coefficients will be null except particular one... i know that some decoders introduce spectral dither substituting null data with random low level but... i see nothing wrong in this.

Even Fraunhofer FDK ? (libfdk_aac)

That's my go-to AAC encoder and I love it. Haven't done any SNR test on it though, only listening tests.

Well... seem that AAC perform worse than simpler codecs and as a result lower SNR (higher noise floor) is offered - i need to check all AAC encoders available to compare - currently have no time for AAC as most of hardware i testing support by definition MP2 and AC3 but in IMD test MP2 provide better results than AC3...
Also be aware that testing of codec is not my intention - i need most transparent codec to provide sinewave clean as possible to test physical HW.
Problem is not related to bitrate or similar things - obviously some encoders perform worse when compared to others on same signal (IMD is high stress from HW perspective but it should be not a problem from codec perspective).

nevcairiel

28th June 2015, 18:44

How they are special (except they are way simpler to encode)?

If your spectrum is simple and something wrong happen with codec this mean that your codec design is faulty...

Sine wave is same signal like other - main difference is that MDCT coefficients will be null except particular one... i know that some decoders introduce spectral dither substituting null data with random low level but... i see nothing wrong in this.

Lossy codecs are designed/tuned for common use-cases, voices, music, etc. Sine waves do not fall into this pattern, and can trip up these optimizations.

pandy

29th June 2015, 07:48

Lossy codecs are designed/tuned for common use-cases, voices, music, etc. Sine waves do not fall into this pattern, and can trip up these optimizations.

This is simply untrue as codec doesn't understand nature of signal - lossy codec works under same, strictly mathematical criteria and sine wave is same type of signal like music - it is only simpler to encode as with even low bitrate there is plenty of available to use bits to store compressed signal...

Accordingly to my knowledge there is no codec on market that use neural networks trained to ignore simple tones...

And on a side - some instruments are near to sine spectrum... i bet that i can add white noise to those two tones and result will be the same... faulty codec implementation have nothing to do with spectral masking and perceptual tuning.

Balling

2nd June 2026, 21:13

User on Reddit has posted the quality of eac3 ffmpeg encoder vs "Dolby Media Encoder" application, took it a while until -drc_scale 0 was used to remove DRC on encoded by Dolby encoder (ffmpeg encoder does not support DRC and thus there is no need to use drc_scale 0 on decoder) and 256 sample priming gap that both encoders insert and unless put in mp4 by ffmpeg it is not removed... Google test zimtohrli suite was used.

https://www.reddit.com/r/ffmpeg/comments/k3z9i9/comment/m3zjt4h/?force-legacy-sct=1

Quote here in full.

My past zimtohrli measurements were all somewhat inaccurate, because ffmpeg decodes (e)ac3 with all samples shifted by 256 samples forward in time, adding ~11ms of silence at the beginning, basically the same issue that formats like MP3 and AAC have as well, so I should have expected that. But with `-drc_scale 0` for decoding and then filtering with `-af aresample=first_pts=256`, the scores should be accurate now.
While zimtohrli should highly correlate with human perception, it's worth noting that it is a pure per-channel metric, so it might unfairly punish coding techniques that involve, for example, reducing quality on one channel if the sound is overshadowed by louder sound from the other channels.

Anyway, here are the zimtohrli scores for the full audio of the Tears of Steel short movie; I removed the LFE channel, and the higher score of each FL/FR and BL/BR pair (which never deviated much from each other anyway):

fdk-aac 384k cbr aac (44.1 kHz):
4.9816 (FL FR)
4.99923 (C)
4.97722 (BL BR)

fdk-aac 384k cbr he-aac:
4.96607
4.99963
4.98321
(this high score surprised me, I would have assumed the static SBR threshold of 12 kHz to be a bit more limiting, but maybe the sample here just didn't contain much very high frequency harmonics)

Dolby 384kbps ac3:
4.72085
4.84867
4.72297

FFmpeg 384kbps ac3:
4.70113
4.80505
4.69726
(FFmpeg holds up extremely well here compared to the Dolby encoder, but looking at the AAC scores, I assume that a significantly better AC3 encoder is possible)

fdk-aac 256k cbr aac (44.1 kHz):
4.89187
4.98928
4.88925

fdk-aac 256k cbr he-aac:
4.93956
4.99519
4.94692
(again very impressive results from the fdkaac encoder)

Dolby 256k ac3:
4.65848
4.79297
4.65313

FFmpeg 256k ac3:
4.62544
4.72272
4.60867

Dolby 256k eac3:
4.62671
4.29229
4.57617
(the center channel gets a rather low score here, listening to it in isolation, the issue is very clear, there is a significant amount of bleeding from the other channels)

Dolby 256k Blu-ray eac3:
4.65497
4.60828
4.58956
(surprisingly, the Blu-ray eac3 profile from the Dolby encoder is more efficient across all channels)

FFmpeg 256k eac3:
4.6278
4.74468
4.62329
(very surprisingly, the FFmpeg eac3 encoder holds up very well with the Dolby competition here!)

fdk-aac 192k cbr aac (44.1 kHz):
4.84574
4.96756
4.84471

fdk-aac 192k cbr he-aac:
4.83493
4.97991
4.83677
(I expected HE-AAC to perform slightly better than AAC-LC at such a lowish bitrate for 5.1, not worse, but maybe it's just the sample...)

Dolby 192k eac3:
4.53272
3.75264
4.38356
(severe bleeding into the center channel)

Dolby 192k Blu-ray eac3:
4.57572
4.44936
4.43095
(again, the Blu-ray profile performs better than the online media profile eac3 on all channels for some reason)

FFmpeg 192k eac3:
3.26063
4.34128
3.69626
(this is some abysmal quality, especially on the most important FL/FR channels; and listening to it, the main issue quickly becomes very clear, the sound is just extremely muffled, and most likely very unnecessarily so)

So, turns out the FFmpeg eac3 encoder is not necessarily bad, it's just really broken at lower bitrates, it seems.

tebasuna51

5th June 2026, 12:42

Thanks for the tests. I was unaware of the Zimtohrli method for verifying quality.
This method seems to confirm the higher quality/size of the AAC (fdkaac) codec compared to AC3/EAC3. I still have some doubts about the supported bandwidth, so I ran some tests.

Using Tears of Steel.ogg 840 Kb/s as the source (the best I could find), I analyzed the M4A/AC3/EAC3 encodings with Spek to see the cutoff frequencies they retain.

I focused on bitrates around 384 Kb/s, which seem close to transparency.

File Size Kb/s min./avg./max KHz
----------------- ----------- ------------------ ----
tears.wav 634.181.828 22
tears_4.m4a 36.386.939 12 / 397 / 927 16.6
tears_384.m4a 35.379.365 312 / 386 / 533 16.2
tears_HE_384.m4a 35.313.900 306 / 385 / 470 22 SBR
tears_dd.ac3 35.232.768 384 18.2
tears_ff.ac3 35.232.768 384 18.2
tears_ff.eac3 35.232.768 384 18.2
tears_dd.ec3 35.232.768 384 18.2

As you can see, the AC3/EAC3 formats all maintain the same acceptable cutoff frequency.

The HE format is surprising because, with its SBR replication, it retains the full bandwidth, even though it was never recommended for high bitrates. It seems the Zimtohrli method disagrees with that.

However, I would request an analysis using that method for VBR encoding at quality 4 with fdkaac. Tears of Steel maintains demanding audio quality throughout its duration, but most of the soundtracks have many silences and only dialogue, which would recommend VBR encoding to save bitrate.

Balling

6th June 2026, 07:12

The original person was using this sample, forgot to mention it. https://media.xiph.org/tearsofsteel/tearsofsteel-surround.flac
I also opened the bug for this. It is likely that slightly worse quality in AC3 in ffmpeg is what leads to Blu-ray profile being better in EAC3+AC3 Blu-ray profile in Dolby encoder.
https://code.ffmpeg.org/FFmpeg/FFmpeg/issues/23317

The most important point here is that already on 256k eac3 in ffmpeg is MUCH BETTER than Dolby's unless you use Blu-ray profile. This puts the use of Dolby encoder at all under question.

j7n

6th June 2026, 08:16

Balling

6th June 2026, 10:51

"fdk-aac 192k cbr he-aac:
4.83493
4.97991
4.83677
(I expected HE-AAC to perform slightly better than AAC-LC at such a lowish bitrate for 5.1, not worse, but maybe it's just the sample...)"

This will be fixed by https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20672

tebasuna51

6th June 2026, 11:11

The most important point here is that already on 256k eac3 is MUCH BETTER than Dolby's unless you use Blu-ray profile. This puts the use of Dolby encoder at all under question.
It doesn't make sense that the Blu-ray profile (core AC3) has higher quality than pure EAC3; pure EAC3 encoding should be more efficient.

Balling, could you please run the Zimtohrli test for fdkaac -m 4?

DJ Bobo

6th June 2026, 17:43

That the industrial EAC3 encoder can achieve near transparency at 448kbps, is an established fact since 2007 (!), as per the study done by the EBU back then (screenshot)
They didn't test 512kbps, but it is clear that the industrial Dolby Digital Plus encoder achieves transparency at this bitrate.

Testing 384k DD against 384k AAC is again pointless, as you can see that even 320k AAC beats 384k DD by a comfortable margin (and 448k DD by a small margin), but 256k AAC can't. So these Zimtohrli scores don't seem to be very accurate.
But I wouldn't care much about AAC 5.1 encoding quality anyway, as virtually no soundbar can handle AAC streaming, so it is absolutely pointless imho.
Most important is AC3 quality, as this is the most compatible setting (followed by EAC3, which is supported by newer soundbars, and can achieve near 384k DD quality at 256k already as per the aforementionned EBU study)

The question is: is there a consumer AC3 encoder that can achieve transparency at 640kbps or not?
I am emphasizing "consumer" here, as industrial encoders seem to apply all kinds of transformations to input levels, with all their (complicated) settings (apart from the fact that they are too expensive), where consumer encoders don't tamper with the dB levels at all - at least not the TMPGEnc encoder: I check the dB and RMS levels, they are identical for the input and the output.
Problem with the TMPGEnc Dolby encoder is a cut-off at 18 KHz, even when I choose 640k; so obviously not transparent (even if I don't hear the difference with the DTS-HD source, as I can't seem to hear beyond 18 KHz :rolleyes: )
Last time I checked FFMPEG quality, I wasn't very pleased (kinda muffled). TMPG seemed better to me.

Balling

7th June 2026, 08:24

It doesn't make sense that the Blu-ray profile (core AC3) has higher quality than pure EAC3; pure EAC3 encoding should be more efficient.

Balling, could you please run the Zimtohrli test for fdkaac -m 4?

Yes, it does make sense because a) clearly bugs in pure EAC3 in Dolby encoder, b) perfectly polished AC3 encoder means that in 5.1 EAC3+AC3 Blu-ray profile the front left, front right and center are reproduced well c) there is no EAC3 dependent stream support for 7.1 in ffmpeg anyways.

Dolby 384kbps ac3:
4.72085
4.84867
4.72297

"But I wouldn't care much about AAC 5.1 encoding quality anyway, as virtually no soundbar can handle AAC streaming, so it is absolutely pointless imho"

Modern TVs can decode 7.1 flac or 5.1 flac correctly and aac 5.1 too and send it over eARC back in LPCM. They use ffmpeg often too, you know. And Lavfilters can bitstream truehd+Atmos.

"Last time I checked FFMPEG quality, I wasn't very pleased (kinda muffled). "

Yes. But this is on 192k. At 256k already nice quality. DRC on the industrial encoders can be disabled on modern AVRs.

DJ Bobo

7th June 2026, 12:17

Modern TVs can decode 7.1 flac or 5.1 flac correctly and aac 5.1 too and send it over eARC back in LPCM
I noticed that my TV can indeed decode AAC 5.1 and send it as Dolby Digital 5.1 to my soundbar if I read from a USB drive connected directly to the TV, but the moment you read from disc, it's over, unless you have eARC as you said to get multichannel PCM, but there is still a solid base of TVs and soundbars that can't do eARC.
But even then, I would rather take Dolby Digital Plus, as it is much better than AAC, and does not require eARC (as you can see on the graph above, huge difference between DD+ and AAC at 256kbps) - but from what I understood, the FFMPEG DD+ encoder is nowhere near that quality?
I would like to add, some soundbars sound worse with PCM than with Dolby. That's the case with Panasonic soundbars at least, where if I bitstream the Dolby Digital track, it sounds more dynamic than the same track decoded by the player and sent as PCM. Probably some DSP routines that kick in only when fed a Dolby or DTS track.

"Last time I checked FFMPEG quality, I wasn't very pleased (kinda muffled). "
Yes. But this is on 192k. At 256k already nice quality.
To be fair, TMPGEnc is not very good at 192kbps Stereo either: it cuts off at 16KHz already at that bitrate, and I need to go up to 256k to get the full 20KHz spectrum.
I asked the Pegasys support as to why that is, even though industrial encoders achieve full 20KHz at 192k already (and at 448k for 5.1); they told me, they don't have any influence on that, the codec being given by Dolby as a black box.
So Dolby is probably doing this on purpose so that you don't get a HQ encoder at a fraction of the cost of their professional encoders.

tebasuna51

7th June 2026, 17:49

Using the FLAC (thanks, Balling), I repeated the tests with similar results.
File Size Kb/s min./avg./max KHz
----------------- ----------- ------------------- ----
tears.flac 346.994.847 3782 21.8
Tears_HE_384.m4a 35.313.900 304 / 385 / 484 21.8 SBR
Tears_f384.m4a 35.379.365 317 / 386 / 532 16.2
Tears_fm4.m4a 36.069.737 12 / 394 / 895 16.6 m 4
Tears_q384.aac 36.427.926 13 / 397 / 756 17.6 CVBR
tears_dd/ff.e/ac3 35.232.768 384 18.2

I added a 384kbps CVBR QAAC encoding, which yields similar results to fdkaac -m 4. As you can see, using variable bitrate provides twice the maximum bitrate of the average bitrate, which undoubtedly optimizes quality.

It seems clear that AAC should be the preferred format. This is also supported by the EBU study, the only one we've seen for some time on multichannel audio.

Another issue is compatibility with our sound systems (soundbars, AVRs) and players (TVs, PCs, DVD/BD players, etc.).

And the next question, and the subject of this thread, is whether, if we only have a system compatible with AC3/EAC3, the open-source ffmpeg encoder offers comparable quality to commercial encoders.

According to the Zimtohrli test proposed by Balling, it seems to offer comparable quality, but a more thorough study (like the one by the EBU) would be needed to evaluate it. Let's see if they're willing to do it at https://hydrogenaudio.org/.

Regarding TMPGEnc, it appears to be based on a Dolby-closed codec, like Audition and others, which shouldn't be different from Dolby's official codecs (Dolby Encoding Engine, etc.).

Balling

7th June 2026, 17:55

"but from what I understood, the FFMPEG DD+ encoder is nowhere near that quality?"

No? Ffmpeg is already better quality than Dolby's eac3 encoder at 256k, though j7n was complaining that Dolby Media Encoder is worse quality than older Audition or eae.exe encoders of Dolby, in fact enhanced coupling is supported in Audition, even ffmpeg decoder does not support that. There is no yet support for dependent stream (Blu-ray profile) in FFmpeg, it is an upcoming patch since eac3 without Atmos patents expired anyways.

Dolby 256k eac3:
4.62671
4.29229
4.57617
(the center channel gets a rather low score here, listening to it in isolation, the issue is very clear, there is a significant amount of bleeding from the other channels)

Dolby 256k Blu-ray eac3:
4.65497
4.60828
4.58956
(surprisingly, the Blu-ray eac3 profile from the Dolby encoder is more efficient across all channels)

FFmpeg 256k eac3:
4.6278
4.74468
4.62329
(very surprisingly, the FFmpeg eac3 encoder holds up very well with the Dolby competition here!)

Now compare this, this is why I am saying that fronts encoding is worse in ffmpeg because ac3 is worse (well numbers are close 4.62544 and 4.6278 vs 4.65848 and 4.65497) so if this is fixed the encoders can be on par
Dolby 256k ac3:
4.65848
4.79297
4.65313

FFmpeg 256k ac3:
4.62544
4.72272
4.60867

"TMPGEnc is not very good at 192kbps Stereo either: it"

Oh, no, it is not stereo. It is all tested for 5.1 FLAC source.

Balling

7th June 2026, 18:20

Regarding TMPGEnc, it appears to be based on a Dolby-closed codec, like Audition and others, which shouldn't be different from Dolby's official codecs (Dolby Encoding Engine, etc.).

About that: Audition 2017 encoder has support of enchanced coupling which is not supported by ffmpeg decoder. And the encoder is actually provided by Rovi. https://trac.ffmpeg.org/ticket/10958

DJ Bobo

7th June 2026, 19:46

"TMPGEnc is not very good at 192kbps Stereo either: it"
Oh, no, it is not stereo. It is all tested for 5.1 FLAC source.
TMPG does not support anything below 384k for 5.1, and as I am a bit of an audiophile, I wouldn't dare go below that anyway! 192k with 5.1 is a blasphemy for me, unless it is AAC-HE, as it comes close to Dolby Digital 448k (!) according to the 2nd phase of the EBU study (see screenshot*). But as said earlier, I don't like using AAC because I almost always play from disc.

* _DTS in the legend means it was transcoded to DTS 1500 by the player to accomodate bitstreaming.

tebasuna51

8th June 2026, 07:10

About that: Audition 2017 encoder has support of enchanced coupling which is not supported by ffmpeg decoder.
Still unsupported, but enhanced coupling is applied with bitrates less than 48 Kb/s per channel and, like DJ Bobo, I can't never rtecommend less than 384 Kb/s for 5.1 Dolby audio.

It seems DJ Bobo has found an updated version of the EBU studio (please provide a link), it would be interesting to learn more about it.

DJ Bobo

8th June 2026, 14:22

updated version of the EBU study (please provide a link)
It's Document Tech3324 (https://tech.ebu.ch/docs/tech/tech3324.pdf)

As it gives completely different results than what this zimtohrli thingy is spitting (especially the 256k AAC VS 384k DD), I wouldn't trust the zimtohrli score at all for any comparison, be it between Dolby encoders or different codecs.
I saw that the newest version on Github is 0.2.1, so it is in a very early stage and not refined well yet. The development seems to have stalled anyway, as there was no update since last year.

Very low bitrates are not interesting anymore imho, as storing movies on CDs is a thing of the past, and we don't need to look for every last bit to save to squeeze a movie on 1 or 2 CDs. I usually burn my recordings on DVD today; that's 4 Mbit/s for video on average. Even at 640k for audio, this is only 16% of the video bitrate, where MP2 on VCD takes over 19%. So as long as it does not exceed 19%, it's perfectly adequate imho.

So I would be definitely be more interested in (reliable) comparisons at the usual bitrates: 384, 448 and 640k.
If I need to go under 384, I would prefer encoding a Pro-Logic II version instead anyway.

I checked Adobe Audition; the only free version available is Audition 3.0, and it does not seem to support AC3 encoding :-S
New versions are only on a subscription basis. No way in hell am I gonna pay Adobe a subscription for anything!! haha

Balling

8th June 2026, 16:52

This thread is not even about aac vs eac3? It is about eac3 quality in FFmpeg.

fdk-aac 256k cbr aac (44.1 kHz):
4.89187
4.98928
4.88925

Dolby 384kbps ac3:
4.72085
4.84867
4.72297
What is the problem, I don't see it?

DJ Bobo

8th June 2026, 17:37

What is the problem, I don't see it?
The Zimtohrli score of the 256k AAC is higher than the score of AC3 384k, which is the complete opposite of what the EBU study says: roughly 76 for DD384 vs 61 for AAC256.

tebasuna51

8th June 2026, 18:44

It's Document Tech3324 (https://tech.ebu.ch/docs/tech/tech3324.pdf)

Thanks for the link, but that second version is also very old (2007) and lacks modern encoders, which I hope have been substantially improved.

It doesn't make much sense that it shows worse results for DD+new256 than for DD+old256, and that AAC HE encodings are so highly valued.

DJ Bobo

8th June 2026, 19:17

that second version is also very old (2007) and lacks modern encoders
I thought about that too, but it is still very representative imho, as AAC was released in 1997. After 10 years of optimization, there is very little headroom left for improvement.

Balling

9th June 2026, 08:26

The Zimtohrli score of the 256k AAC is higher than the score of AC3 384k, which is the complete opposite of what the EBU study says: roughly 76 for DD384 vs 61 for AAC256.

Did you consider that AAC is reencoded from 48000 24 bit original flac to 44100 16 bit wav, while eac3 supports 24 bit flac input?

DJ Bobo

9th June 2026, 11:45

@ Balling
Yes, I did consider this.
It shouldn't matter, as both AAC and AC3 are lossy codecs. Lossy compression does not have an intrinsic bit depth afaik. It just throws out whatever it deems unhearable by humans.
As most input has a dynamic range of 70dB or less (meaning that almost all 24-bit content is fake 24-bit anyway :D ), lossy codecs probably work with 13 bits or less internally, and zero the remaining bits, depending on the detected dynamic range.
And thanks to the cut-off, the sampling rate becomes more of a number than hard reality.
So basically, FFMPEG would work internally with a 37KHz sampling rate on 384k AC3, as it cuts off at 18 KHz, and fills the rest of the spectrum with zeros to accomodate the selected sampling rate, whatever it may be, 44,1 or 48KHz
TMPGEnc cuts off at 17 KHz on 384kbps btw, so I am not sure if it is better than FFMPEG at this bitrate, as an earlier cut-off means more bits that could be allocated to the lower frequency band. I need to do further testing on this; I rarely use 384k.
What I know for sure, is that TMPG's 640k sounds better than FFMPEG's 640k.

What I also know for sure, 192k is borderline, even for Stereo AC3, even with professional encoders. I was just watching a DVD of the 6th Season of the X-Files yesterday, and I was not pleased at all, where I was very pleased with the sound in Season 5. I checked the bitrate, Fox used 192kbps on both seasons, but Season 5 rolls off around 16KHz, where Season 6 comes close to 20KHz (they probably started using better master tapes since Season 6?). Season 6 sounded awful, despite (or because of?) the wider spectrum (reminded me of DTS 5.1 @754k, annoying fatiguing kinda scratching mid-range?)
So the Dolby encoder used in TMPGEnc, cutting off at 16KHz with 192kbps instead of 20KHz like with industrial encoders, might actually be a good choice?!
Definitely sounds better to me than FFMPEG's implementation anyway. FFMPEG has more compression artefacts at 192k Stereo.

j7n

10th June 2026, 02:02

Where did you get the "13 bits" figure from? The dynamic range is adaptive to the current level in lossy codecs much like hearing. But if you place test tones spaced far apart in different bands where they don't mask each other (even if in practice they would), they can even be encoded simultaneously at high bitrate. For example, 8K at -2 dB, 2K and 14K at -96 dB, and 60 at -30 dB. Breaking the audio into bands is the core principle of transform codecs.

AC-3 at 192 kbit/s with the Dolby encoder is only discrete stereo up to 14 kHz, as is revealed by AC3Filter. This was a good decoder, showing various technical information right at playback. Above that the channels are coupled in joint-stereo. Independent stereo needs 256 kbit/s for full bandwidth.

https://imgur.com/a/U228aPX

tebasuna51

10th June 2026, 07:27

What I know for sure, is that TMPG's 640k sounds better than FFMPEG's 640k.
How can you prove that?

My old ears can't tell the difference between ffmpeg encoding and Dolby Encoder Engine encoding.

https://www.sendspace.com/file/m23d9g

DJ Bobo

10th June 2026, 11:45

Where did you get the "13 bits" figure from?
Very easy actually. The number of bits required is directly tied to the dynamic range: 1 bit is required for each additional 6dB of DR.
Meaning, to cover 70dB of DR, you need 70/6 = 12 bits, and you add 1 bit for rounding errors.
Knowing that I am being very generous here with the 70dB figure. Level meters usually show ∞ at the -60dB mark ;)
AC-3 at 192 kbit/s with the Dolby encoder is only discrete stereo up to 14 kHz
I am not complaining about channel coupling. I mean, LAME uses Joint Stereo even with the extreme setting, which averages about 256kbps.
I am complaining about the sound quality if no early cut-off is applied. TMPGEnc basically works with an internal sampling rate of 32KHz when encoding Stereo in 192kbps, which seems to be a sane choice if not even the professional Dolby encoder is capable of delivering nice sound at 192k -.-
I am really angry at studios that use 192k for Stereo on DVD and BD, as even VCD had 224kbps. With all the space available on DVD and BD, at least 256kbps should have been the norm.
Btw, AC3filter does not seem to show that info about the bandwidth with newer versions (just checked with v2.6)
How can you prove that?
My old ears can't tell the difference
I feel you man :D
My hearing is also not what is used to be 30 years ago. But still extremely good for my age (I can still hear up to 17KHz with headphones; equivalent to a 15 years younger average guy! lol)
Obviously, I can't prove anything; just what I hear. FFMPEG sounds muffled at 640k. Definitely not transparent. With TMPGEnc, I k~inda can tell, there is a little tiny bit of intransparency there, but extremely hard to detect. I need to concentrate really hard with headphones on subtleties like how spacious wind sounds in the background.

Balling

10th June 2026, 12:08

There is now a patch to port QAAC / Apple's CoreAudio https://patchwork.ffmpeg.org/project/ffmpeg/patch/178107300223.63.16712151251393644016@29965ddac10e/

"Matches Apple on Zimtohrli and ViSQOL. Beats fdk-aac conclusively. Exact benchmarks in a bit. "

j7n

10th June 2026, 13:22

32 kHz is a valid and available option in the Dolby Encoder of older versions. Not sure how various players handle it, and DVD requires 48 kHz. I would not encode at 192 kbit/s. Adding another 32 kbit to reach the more common DVD rate will improve the sound more than it will worsen the video.

Joint stereo is coarser in AC-3, working with wider bands. Some samples of music (bitrate on the caption). My encoder is only discrete up to 10 kHz at 192 kbit.

https://imgur.com/a/5qq9Kru

AC-3 is good down to 18 bits. AAC has no practical limit.

DJ Bobo

10th June 2026, 15:36

@ j7n
It's not about the displayed sample rate. That's why I said internally. That's a direct consequence of the frequency cut-off at 16KHz. Probably more of a 33KHz sampling rate internally with TMPGEnc at 192kbps. I tried resampling to 32KHz in Audacity, and the roll-off is between 15 and 15,5KHz, not at 16.
I would not encode at 192 kbit/s
Me too. That's why I told Balling to forget about testing 5.1 at 192kbps with AC3, as it is already borderline with Stereo!
Adding another 32 kbit to reach the more common DVD rate will improve the sound more than it will worsen the video
In TMPGEnc, 224kbps is not transparent by design, as it cuts-off at 18KHz.
FFMPEG rolls off at 20KHz, but it is not transparent either at this bitrate.
AC-3 is good down to 18 bits
As said, these numbers don't mean anything in practice. I don't know any source that can fully use the 16 bits of the CD standard. Never ever encountered a source with more than 70dB dynamic range.
I am even ready to bet that no source needs more than 14 bits.

Balling

10th June 2026, 19:24

"I don't know any source that can fully use the 16 bits of the CD standard." Such music that is not compressible much with flac exists. Usually music is compressing to 890 kbit/s with flac, yes. https://www.audiosciencereview.com/forum/index.php%3Fthreads/is-ldac-lossy-or-bit-perfect-for-44-1khz-16bit-red-book-cd-files.15533/

Dolby TrueHD is 24 bit only...

"Never ever encountered a source with more than 70dB dynamic range." If you unfold MQA FLAC maybe you will get it. Nowadays true flac without MQA lossy unfolds also exists. I and others reported that Dolby TrueHD is not perfectly lossless with Dolby encoder in DME, some off-by-one issues. In ffmpeg it is always lossless.

Lynee also posted quality metrics for QAAC port to FFmpeg here: damn, that is crazy how good Apple encoder is. Also after latest changes ffmpeg encoder is better apparently than FDK. https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23430

DJ Bobo

10th June 2026, 20:56

@ Balling
Compressibility has not much to do with the dynamic range. I've seen music with an extremely narrow dynamic range (you know, loudness war kind of music) staying over 1.000kbps with FLAC.
Dolby TrueHD accepts 16-bit audio too. Tried with FFMPEG, it says 16-bit in the output. Many commercial BDs also use THD at 16-bit (Example (https://caps-a-holic.com/c.php?d1=13196&d2=13197&c=5171))
THD is definitely lossless, in the official version and in FFMPEG, but adds the comfort of Dynamic Range Compression in professional encodings, like with Dolby Digital, thus you may find tiny differences in the decoding process when DRC is enabled (gain differences, not sound quality differences)
MQA uses FLAC compression for the first 13 bits up to 24KHz, and lossy compression for the remaining 4 bits along with the rest of the spectrum above 24KHz. So it is more efficient than FFMPEG's THD encoding, but not truly lossless as they used to claim (I think the word is out by now that it is not lossless).

But this is irrelevant to our discussion here, as this topic is about FFMPEG's AC-3 encoding and how it compares to other encoders.
Bottom line is, bit depth shouldn't have any influence on the encoding quality for lossy codecs like AC-3, be it in FFMPEG or other encoders. It is just a flag, more or less.
The real bit depth is usually less than 13 bits due to the maximum of 70dB DR IRL, and has absolutely nothing to do with the codec used; it is solely dependent on how low the noise floor of the recording studio is.
Here in the screenshot, you can see an analysis of a portion of digital silence from a PS5 capture. It is at -78dB! That's 13 bits! Complete silence! haha

Balling

11th June 2026, 02:09

"Dolby TrueHD accepts 16-bit audio too. Tried with FFMPEG, it says 16-bit in the output."

Try with flac output. ffmpeg -i file.thd out.flac

Wav always defaults to 16 bits. This is legacy dicision, but -c:a pcm_s24le can be used to force 24 bit wav.

"THD is definitely lossless, in the official version"

It is not, this was reported here. https://forum.doom9.org/showthread.php?t=185664

MQA first unfold is analog lossless, second unfold is lossy. Third unfold I dunno how it works, not sure it is even real. Though I think it is real as this cannot decode files with supposed 3rd unfold inside correctly https://code.videolan.org/mansr/mqa/

DJ Bobo

11th June 2026, 08:40

It is not, this was reported here.
That same thread you are linking says "There's a chance this is something they have already fixed in a newer version of DEE"
If he is not able to work with a newer version, then he most probably used a cracked version anyway (which we should not care about)

Anyway, forcing 24-bit is dumb if you ask me. It is just there on Blu-ray to fool us into thinking, we are getting a better dynamic range; but we're not. The DR is identical between regular FFMPEG's AC-3, Dolby's AC-3 and Dolby THD, be it 16, 20 or 24-bit.
As I showed before, even complete silence is at -78dB on a digital medium. Far away from the 96dB provided by 16-bit.
You can also see that even expensive AV receivers struggle to achieve a SNR that exceeds 70dB!
Here (https://archive.org/details/Home_Cinema_Choice_Issue_179_2010_04_AVTech_Media_GB/page/n77/mode/2up) for example the Yamaha RX-V2065, worth 850 pounds, barely achieving 65dB at 1KHz! Not even 12-bit level!

So if you ask me, everybody should work with 16-bit files. Remember, Philips deemed 14-bit more than enough for the CD standard. It was Sony who forced 16-bit to future proof the format. Sony was right, because general purpose computer processors work with bytes and words, so even if fed 14-bit, they round up internally to 16-bit anyway.
Anything higher than 16-bit is a waste of bitrate and computation time imho.
I even curse when I see "24-bit" on the description of a BD: a waste of bitrate that could have gone to the video. I always convert to 16-bit before re-encoding.

tebasuna51

11th June 2026, 09:13

Lynee also posted quality metrics for QAAC port to FFmpeg here: damn, that is crazy how good Apple encoder is. Also after latest changes ffmpeg encoder is better apparently than FDK. https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23430
Good news, I hope the improvement will be incorporated into the official version of ffmpeg soon.

Balling

11th June 2026, 12:41

"Anyway, forcing 24-bit is dumb if you ask me."

I guess "forcing" was a wrong way to say it. -c:a pcm_s24le allows thd decoder just like eac3 decoder to enter 24 bit/32 bit float mode. Again you can output to flac and that will be 24 bit flac automatically. 24 bit flac to be decoded to wav also has to be -c:a pcm_s24le. Maybe this should be fixed in ffmpeg, as it is not obvious. And of course if you decode 24 bit wav from TrueHD and then encode again into TrueHD you will get the same TrueHD file, while if you decode to 16 bits assuming bits above 16 are populated the file will be different. Same with EAC3, encoding from 24 bit and 16 bit truncated files will be different.

DJ Bobo

11th June 2026, 12:56

Also after latest changes ffmpeg encoder is better apparently than FDK
The only bitrates that are interesting for us are 128k and 192k, and there is nothing conclusive about them.
At 128kbps, contradictory results, as NMR worse than fdk-aac on Zim, but better on Visqol (shows you how unreliable those so-called "objective" measurements are)
At 192kbps, it looks like NMR wins against fdk-aac on both fronts, but I am pretty sure we are splitting hairs here.

At 128kbps, I wouldn't use AC-3 anyway, so okay, that's out of the window.
At 192kbps, I would take AAC anytime of the day if the target format does not require Dolby Digital, no matter which AAC encoder we're talking about.
By the way, an information that many don't know: you can use AAC Stereo on Blu-ray, if authored as BDAV instead of BDMV. Only requirement is that it is MPEG-2 formatted AAC, not MPEG-4. That's how I burn my Elgato captures to BD-R without re-encoding. It captures with MPEG-4 formatted AAC, which I just patch with AacPatch to the MPEG-2 format.
Again you can output to flac and that will be 24 bit flac automatically
As said, I wouldn't use 24-bit at all for the aforementionned reasons. I was just debunking your statement that Dolby THD is 24-bit only.
FLAC has a bad position here anyway.
If TMPGEnc is not option (I can understand that some people don't wanna pay 120$ for Video Mastering Works, if all they are interested in is the Dolby 5.1 encoder), and you wanna get higher quality than FFMPEG's 640kbps, TrueHD is the way to go, as it is Blu-ray compatible. But in 16-bit please! 24-bit adds 1 Mbit/s for nothing. 1 Mbit/s of unhearable noise. 1 Mbit/s that you can use to get better video quality.

j7n

12th June 2026, 16:35

About the dynamic range. I have downloaded commercial music in E-AC-3 format that contained an accidental voice line at the very end. It was more than 80 dB down, but could be boosted up and heard. So the range is plentiful. But I forgot which album it was and couldn't find it now.

There was a question raised about dither in AC-3 decoders. Since this is offtopic to ticket 11578 (lack of overlap with previous frame), I will reply here. It was found out that the dither in ffmpeg is not (https://trac.ffmpeg.org/ticket/11578#comment:25) deterministic (https://rationalqm.us/board/viewtopic.php?p=23569#p23569), but I don't believe it is a problem, as long as it uniform. However, it seems that the dither is output in bursts every 256 samples. Paul B. Mahol (ElonMusk, richardpl, mycroft) apparently has "fixed" (https://hydrogenaudio.org/index.php/topic,129241.msg1078674.html#msg1078674) it in librempeg.

To check the dynamic range I applied a steep, long fadeout to a sample. The encoder delay has been compensated for.

The dither in Adobe Audition, which presumably uses the official Dolby decoder, is the worst at maintaining the input level. All samples can be boosted back up and the quiet signal is still there, except that the output of ffmpeg contains a buzz.

PlayersClubFade.wav : source
PlayersClubFade_640ac3.ac3 : encoded with MainConcept, decoded with audition, ffmpeg, liba52
PlayersClubFade_640ec3.ec3 : encoded with MainConcept
PlayersClubFade_640ffec3.ec3 : encoded with ffmpeg

https://pixeldrain.com/u/mVVoitbD

DJ Bobo

12th June 2026, 18:10

contained an accidental voice line at the very end. It was more than 80 dB down, but could be boosted up and heard
As you said, "accidental". Exceptions confirm the rule.
And still way below the 96dB possible with 16-bit.
But, no it can't be boosted to hearable levels. When you apply gain, you apply it to the whole track. Modern tracks are often clipped at 0dB, and well mastered tracks are normalized at -6dB or higher, giving a maximum possible boost of 6dB. And EQs are usually limited to +10dB. So anything below -80dB won't be heared, even with EQ applied.
Here (https://archive.org/details/Home_Cinema_Choice_Issue_201_2011_12_AVTech_Media_GB/page/n47/mode/1up) is another AVR, which belongs to the better models. Even this one can't achieve more than 78dB SNR.
You need to remember that the average home has a noise floor of 30 to 35dB, and listening at levels over 90dB is too loud for the average listener. So that brings down the usable dynamic range to 60dB under realistic conditions anyway.

So if you are not happy with FFMPEG's AC-3 output, it has nothing to do with the dynamic range, and encoding using 24-bit with THD (or any other codec for that matter) won't add anything in this regard. Total waste of bitrate. It's pure marketing BS from the studios.

NB: I just acquired a new capture box that can grab 5.1 audio, and even the PS5 cuts at 18KHz, even though it is using 640kbps. So this seems to be a standard limitation in consumer grade Dolby 5.1 encoders.

Balling

13th June 2026, 19:14

"However, it seems that the dither is output in bursts every 256 samples. " i saw that a file eac3 concatenated with the same eac3 file and then decoded does not have the same dither in 2nd part. I then substracted the files in Audition. The result contained audible sizzling as reported in this post https://rationalqm.us/board/viewtopic.php?p=23598#p23598

«First, the main noise isn't white but "echoing" of the working signal instead. Second, the white noise added by FFMpeg can be not only seen but heard as sizzling.»

There is also implementation now that exists for eac3to to not just account for dither flag in AC3 bistream, but also see whether it is silence — then no dither is applied.

I don't think these are acceptable artefacts. Though it is minor issue. Again, Audition has even less noise

Columbo

13th June 2026, 21:28

There is also implementation now that exists for eac3to to not just account for dither flag in AC3 bistream, but also see whether it is silence — then no dither is applied. Close but not quite. eac3to doesn't have access to the dither flag or any control over the decoding. It implements a post-processing of the decoded data to silence dither. Details are at the DG forum. And obviously nothing is different for encoding. It lets you clean up already dither-infected files.

https://rationalqm.us/board/viewtopic.php?p=24105#p24105

Balling

13th June 2026, 22:04

Ticket 11578 is fixed in Paul fork. https://github.com/librempeg/librempeg/commit/049ca1424412fb50f598b869580f4124870d0c59

This commit does it.

j7n

14th June 2026, 03:05

Yes, it appears to be fixed there! The dither during silence is at a level between 18 and 22 bits. You can't even see it when rounding to 16. Even the spikes every 256 samples can't be heard with most content. If those were fixed, the dither would have even lower peaks. Adobe Audition has a dip in level in the dithered bands compared to the input. Most music reveals a "shelf".

Balling

14th June 2026, 17:43

I think bleeding is an expected result of channel coupling in the high frequencies when the target bitrate is low, which would not be as noticeable when listening to the complete mix.

Last two images at 384 kbit/s:
https://imgur.com/a/Vq5vl7u

Ffmpeg does not support normal coupling in the encoder, apparently.

https://github.com/raress96/dolby-atmos-encoder

raquete

14th June 2026, 19:32

Ffmpeg does not support normal coupling in the encoder, apparently.

https://github.com/raress96/dolby-atmos-encoder
😳
Can a very kind person tell me how to use "dolby Atmos Encoder"?

i open the link and don't understand what i have to download and what to do. :confused:

Columbo

14th June 2026, 19:42

The steps are there in the README.md. But I wouldn't bother because the result cannot be played with Atmos on real hardware.

Columbo

17th June 2026, 19:10

See here for the eac3to (avcodec) fix for the spectral "garbage" issue:

https://www.rationalqm.us/board/viewtopic.php?p=24199#p24199

raquete

17th June 2026, 19:40

See here for the eac3to (avcodec) fix for the spectral "garbage" issue:

https://www.rationalqm.us/board/viewtopic.php?p=24199#p24199

Columbo,
I feel like a comet dissolving and wandering aimlessly, observing galaxies full of complex factors.

Columbo

17th June 2026, 20:26

You and me both bro. I'm not one of the 5.

Balling

20th June 2026, 05:34

With regards to replacing integer to float math. This is likely not gonna be accepeted into ffmpeg, we really love integer math. If you can solve this using integer math... "For high-exponent bins (exps >= 23), integer right-shift truncates dither to
zero, creating a non-flat injection pattern across the spectrum. "

I tested the patch it does not change the wav. https://patchwork.ffmpeg.org/project/ffmpeg/patch/651641d2-3793-4f7d-8639-b13950f28a9c@cantab.net/

Columbo

20th June 2026, 13:46

I tested the patch it does not change the wav. https://patchwork.ffmpeg.org/project/ffmpeg/patch/651641d2-3793-4f7d-8639-b13950f28a9c@cantab.net/ You're just wrong. It's proven to fix the spectral banding for streams with coupling and brings the decoder into spec compliance for dithering. I don't know what WAV you are talking about or what you are referring to in its spectrogram. Maybe you refer to something else. The patch was targeted only at the banding, or lines, in the spectrogram.

I know about ffmpeg's preference for integer and that's why the change to float was not submitted. The most recent avcodec doesn't require it to the same extent that avcodec-54 did.

https://www.rationalqm.us/board/viewtopic.php?p=24254#p24254

You keep saying "we" in the context of ffmpeg but I see you are not an ffmpeg team member and in fact have had a contentious relationship with the project.

Balling

20th June 2026, 15:11

You're just wrong. It's proven to fix the spectral banding for streams with coupling and brings the decoder into spec compliance for dithering. I don't know what WAV you are talking about or what you are referring to in its spectrogram. Maybe you refer to something else. The patch was targeted only at the banding, or lines, in the spectrogram.

I know about ffmpeg's preference for integer and that's why the change to float was not submitted. The most recent avcodec doesn't require it to the same extent that avcodec-54 did.

https://www.rationalqm.us/board/viewtopic.php?p=24254#p24254

You keep saying "we" in the context of ffmpeg but I see you are not an ffmpeg team member and in fact have had a contentious relationship with the project.

I was their main issue tracker maintainer since 2022, member since June 2019 previously worked on Chromium/ffmpeg integration and was occasionally providing fixes to mpv and ffmpeg under different names and fixes from different authors than myself. That is 7 years now. Proof about one of the first posts on Trac from 2019. https://trac.ffmpeg.org/timeline?from=Jun+18%2C+2019&daysback=10&authors=&tag_query=&milestone=on&ticket=on&ticket_details=on&wiki=on&tags=on&update=Update

DJ Bobo

20th June 2026, 15:16

@ Balling / Columbo
You guys are sure this is the right thread for such a discussion?
I thought this thread was about comparing FFMPEG's AC-3 encoder to other (AC-3) encoders, so I am not sure how the AC-3 decoder tweaks have anything to do with this?

Columbo

20th June 2026, 15:24

OK, gotcha DJ, sorry.

j7n

21st June 2026, 06:43

Columbo

21st June 2026, 10:52

This is off-topic here as DJ pointed out. Please post at DG forum or open a new thread here if you want to discuss it. I will simply say here that you are wrong on both counts.

Balling

22nd June 2026, 01:14

I see the dither patch works on eac3 samples here https://fate-suite.ffmpeg.org/eac3/

Balling

22nd June 2026, 07:12

Ac3 dither should be kept with a smooth, low amplitude. It's not just about an adherence to a spec. Later codecs like opus also fill missing bands with noise instead of blanking them like mp3.

The example presented on the DG forum didn't show a real problem. It was lowpassed, and then strongly boosted to reveal the dithered, otherwise bands that were still silent for all practical purposes.

You misunderstood what the problem there is. There are lines on the spectrum in iZotope RX 11. That is the only issue they were really concerned about. The lines are shown on this screenshot, when author of the issue clarified what was supposed to be fixed. https://www.imagebam.com/view/ME1DVRKY The problem there was because the dither was the same cause coupling channel was dithered instead of resultant channels, the AC3 spec says that dither should be random in the output. See 7.3.4 Dither for Zero Bit Mantissas (bap=0): Dither is applied after the individual channels are extracted from the coupling channel.
In this way, the dither applied to each channel's upper frequencies is uncorrelated.

But I cannot see any difference in 01.ac3 file with the patch.

Balling

30th June 2026, 16:24

Alright, there was a separate issue with coupling/not coupling eac3/ac3 dither.

I also just realised that the values for coupling eac3 I posted were likely wrong as ffmpeg decoder had a bug in decoupling https://trac.ffmpeg.org/ticket/11321
That one:

Dolby 256k eac3:
4.62671
4.29229
4.57617
(the center channel gets a rather low score here, listening to it in isolation, the issue is very clear, there is a significant amount of bleeding from the other channels)

Balling

30th June 2026, 20:55

Good news, I hope the improvement will be incorporated into the official version of ffmpeg soon.

There were some simple bugs in the new aac coder, and now the quality is even further improved. It seems to be better than Apple in some case x2 https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/23430

Merged: https://hydrogenaudio.org/index.php/topic,129691.0.html

Apparently "stereo PNS" was busted in ffmpeg decoder. Just great.

Balling

11th July 2026, 05:16

ac3 and eac3 encoder is now fully gapless in mp4 as before the files were written with wrong editlist value for media duration, even if input file has samples per channel not divisible by 256. It also is gapless with higher bitrate like eac3 1500k.

Balling

12th July 2026, 12:16

New blind tests about new AAC encoder for 48 kHz only. https://www.reddit.com/r/AudioCodecLab/comments/1uu5vtp/aaclc_128_kbps_listening_test_cbrabr_evaluation/

Yea, now AC3 is fully in the outsiders. Lol

v2 of that blind test with some fixes by Lynee additionally: https://www.reddit.com/r/AudioCodecLab/comments/1v2z995/listening_test_of_the_ffmpeg_91_nmr_aac_encoder/

The new branch by Lynee for aac encoder improvement even further, not merged yet...

Also, there is still an issue that Lynee did not fix -bt:a 0 option (bit tolerance 0) for A2DP bluetooth.

Balling

12th August 2026, 20:23

ac3_fixed decoder fixed (in https://github.com/FFmpeg/FFmpeg/commit/564f92cce23ae95399476617b8a1dc357f002a47 and https://github.com/FFmpeg/FFmpeg/commit/5ba2a2c841259a04742064da5e79e288f50ef9fa ). ac3 float decoder is also fixed (https://github.com/FFmpeg/FFmpeg/commit/2312ae4d10e10e315d12797b78155dbc0bc56cea, we decided to just implement your fix Columbo with moving everything to INTFLOAT and moving tmp1 to INTFLOAT as well but now there is difference on arm64 vs x86_64), then we are gonna apply the fix for downmix (that fixes the first frame where 256 short transform is used on some but not all frames) and also apply dither fix for AC3/EAC3 coupling files.

Also ac3 encoder is gonna get short transforms implementation as well but likely as this is just stealing code from the spec for transient content filter it will not improve the encoder much if it at all. Lynee should test this though.