ffmpeg ac3 built-in encoder quality ?

[DJ Bobo]

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]

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]

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]

@ 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]

"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]

@ 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]

"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]

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]

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]

"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]

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]

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]

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]

"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]

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]

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

This commit does it.

[j7n]

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]

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]

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]

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]

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

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

[raquete]

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]

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

[Balling]

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]

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]

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]

@ 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]

OK, gotcha DJ, sorry.

[j7n]

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.

[Columbo]

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]

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

[Balling]

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 is 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.