>FFmpeg's AAC DEcoder is busted with regards to stereo PNS, and the bug may be in other AAC decoders too, so we work around it in the encoder. Since no other encoder used PNS, the bug was not found until now.
I don't know what PNS is, but I bet this has been bothering someone's niche use-case for 20 years
The issue was twofold, on one hand, using TNS on top of PNS meant the noise that got inserted was shaped by TNS, which is nonsense since the decoder generated the noise, not the encoder. This made PNS explode.
The second, biggest issue was that using PNS in combination with any stereo tools resulted in noise leaking in both channels equally, ruining stereo imaging. So the best and only thing to do was to enable PNS only if the band in both channels is noise (or is sufficiently non-tonal and masked).
> The encoder was mainly optimized for 48Khz audio. Get over it. It's 2026, resampling is free, 48Khz is the standard. 44.1Khz will work, and so will 96Khz but use 48Khz if you want the best quality.
AAC has a strange quirk that the window size is dependent on the sampling rate, thus requiring a complete psychoacoustics reoptimization of all encoder parameters for each sampling rate, since a 20msec window sounds very different than a 60msec window, to human ears.
I think the closest thing to an actual "standard" is AES5-2018, "Recommended practice for professional digital audio".
Abstract:
> A sampling frequency of 48 kHz is recommended for the origination, processing, and interchange of audio programs employing pulse-code modulation. Recognition is also given to the use of a 44.1-kHz sampling frequency related to certain consumer digital applications, the use of a 32-kHz sampling frequency for transmission-related applications, and the use of a 96-kHz sampling frequency for applications requiring a higher bandwidth or more relaxed anti-alias filtering. This revision further quantifies the preferred choices for higher sampling frequencies.
Edit: From my personal perspective, 44.1kHz is a legacy minor annoyance
Yes and no. It is the standard for audio in film, which explains the author's focus. But is the audio CD bigger and more "standarder" than DVD and Blu-Ray? I think they're equals, and I personally think this encoder only makes sense for video content. Given all the caveats the author mentions (in particular about the sample rate) I would steer clear from using it when ripping CDs.
Don't get me wrong, this sort of thing is a valuable exercise and we are better off with better encoders for these older codecs. But look at the numbers for Opus on this benchmark. It simply blows all the AAC encoders out of the water even at 64 kbps.
Choosing a lossy audio codec has become such a no brainer. Either use opus and be done with it or if for some reason opus cannot be used then use aac for compatibility with insane high bitrate for good quality without having to do research on what encoder and mode to pick.
Still having a good quality and default aac encoder is great. Though I don't get why it is mainly CBR.
The linked article makes the argument that looking at the BSD licensed example code in the RFC that defines Opus would mean that code written based on that understanding would be a derivative work and would have to be BSD licensed. This seems to have something to do with the fact that "clean-room design"[1] is a thing. But as the Wikipedia article points out:
>Clean-room design is usually employed as best practice, but not strictly required by law.
As the article points out, if this was actually true then we could change the licensing on code examples found in RFCs to fix the issue, but there doesn't seem to be any actual issue here. Imagine a world where simply reading some code caused licensing issues...
Nice, I'm looking forward to seeing how this performs in practice. FFmpeg's previous AAC encoder produced poor quality output and often had irritating chirping artifacts, so I've always had to install Apple's Core Audio encoder on any computer I do video recording on to get decent sound. I've done A/B/X comparisons and found that a 320kbps MP3 sounds better than a 320kbps AAC encoded by FFmpeg, but about the same as a 256kbps AAC encoded by Core Audio. If installing Core Audio is no longer necessary, that'll be a huge improvement and people who use something like OBS to do screen recordings or streaming will get a massive sound quality boost the next time they update.
In the Hydrogenaudio discussion thread's metrics table, the new encoder scores better than Core Audio. But this is at constant bitrate (CBR) [edit: maybe not? see lesscraft's reply below]. Core Audio also has variable bitrate modes (TVBR) which the new encoder lacks.
So maybe Core Audio will continue to be the best when TVBR is available, but I'm hopeful the new FFmpeg encoder will be "good enough", especially if more folks find and contribute problem samples to help tune it.
A useful project related to Apple's Core Audio is qaac - it wraps iTunes Windows DLL's in a standalone encoding tool with a CLI interface. I believe it even works under Wine on Linux: https://web.archive.org/web/20250814194428/https://www.andre... So you don't need a Mac or even a full iTunes installation to get high quality AAC encoding.
I was using FDK AAC encoder, I didn’t know Apple encoder was available for systems other than Apple. Though I have once compared AAC FDK to Apple AAC at 192kbps, and couldn’t tell the difference, while the old FFmpeg AAC encoder fall apart at this bitrate.
Older I get, more it seems it’s possible to ping pong between rewrites for good reasons (ex. here, metric maxes but I find it hard to believe VBR and not-48 kHz are silly things and not worth investing it)
This is truly a representative of the old internet: somebody codes up the best AAC encoder ever, and the first response comes from some admin, and it's some bickering about 48Khz vs 44Khz.
Last time I used ffmpeg to encode songs for my iPod nano they were broken; playback was interrupted by pops and clicks every few seconds. I wonder if this is fixed now?
I applaud a new/better FFMPEG AAC encoder, but there are two pretty massive caveats that are mentioned in the specifics that need to be called out:
- CBR only
- Only optimized for 48khz sampling
Not being able to do quality-based variable bitrate encoding is a major gap, and since all of the CD audio in the world is at 44.1k sampling, that seems like a huge miss too.
This is a great update with a clear break-down with lots of detail; bravo lynne! For naysayers Opus is great and has its place, but AAC isn't going anywhere.
AAC-LC is ubiquitous, the only other codec that is wider spread is MP3 and only by negligible margin.
AAC-LC, the earliest version of AAC has been declared as patent free or all patents expired by Redhat for many years already.
AAC-LC was always designed for 128Kbps+ in mind. There are other AAC like HE-AAC and xHE-AAC aiming at lower bitrate.
The current best AAC-LC encoder is done by Apple's Core Audio and most people uses it via qaac. I had always wished Apple to open source it. But now we don't even need that to happen.
The test was done with CBR. So this is extremely promising. Assuming the author is willing to spend more time for VBR I am sure there are plenty of room for improvements.
I wonder if the code follows FFMPEG as LGPL2 or could there be a BSD version.
For music, there is very little reason not to use 256Kbps AAC or even higher bitrate. You get maximum compatibility with near no loss of quality. Last time the group listening test there were only a few samples where 256Kbps AAC-LC failed to match Opus.
Youtube did switched to 256Kbps AAC for a while. Only to returned back to 128Kbps Opus.
I hope there can be further improvement to be made with the encoder.
43 comments
[ 3.1 ms ] story [ 75.0 ms ] threadI don't know what PNS is, but I bet this has been bothering someone's niche use-case for 20 years
Is 48kHz really the standard nowadays?
This was of course fixed in Opus.
Abstract:
> A sampling frequency of 48 kHz is recommended for the origination, processing, and interchange of audio programs employing pulse-code modulation. Recognition is also given to the use of a 44.1-kHz sampling frequency related to certain consumer digital applications, the use of a 32-kHz sampling frequency for transmission-related applications, and the use of a 96-kHz sampling frequency for applications requiring a higher bandwidth or more relaxed anti-alias filtering. This revision further quantifies the preferred choices for higher sampling frequencies.
Edit: From my personal perspective, 44.1kHz is a legacy minor annoyance
Don't get me wrong, this sort of thing is a valuable exercise and we are better off with better encoders for these older codecs. But look at the numbers for Opus on this benchmark. It simply blows all the AAC encoders out of the water even at 64 kbps.
Still having a good quality and default aac encoder is great. Though I don't get why it is mainly CBR.
https://nothings.org/stb/stb_opus.html
This essentially causes opus to never be used in games or in things in stores that may have issues with specific licenses.
>Clean-room design is usually employed as best practice, but not strictly required by law.
As the article points out, if this was actually true then we could change the licensing on code examples found in RFCs to fix the issue, but there doesn't seem to be any actual issue here. Imagine a world where simply reading some code caused licensing issues...
[1] https://en.wikipedia.org/wiki/Clean-room_design
Been around a lot longer than Claude Opus.
So maybe Core Audio will continue to be the best when TVBR is available, but I'm hopeful the new FFmpeg encoder will be "good enough", especially if more folks find and contribute problem samples to help tune it.
- CBR only
- Only optimized for 48khz sampling
Not being able to do quality-based variable bitrate encoding is a major gap, and since all of the CD audio in the world is at 44.1k sampling, that seems like a huge miss too.
AAC-LC, the earliest version of AAC has been declared as patent free or all patents expired by Redhat for many years already.
AAC-LC was always designed for 128Kbps+ in mind. There are other AAC like HE-AAC and xHE-AAC aiming at lower bitrate.
The current best AAC-LC encoder is done by Apple's Core Audio and most people uses it via qaac. I had always wished Apple to open source it. But now we don't even need that to happen.
The test was done with CBR. So this is extremely promising. Assuming the author is willing to spend more time for VBR I am sure there are plenty of room for improvements.
I wonder if the code follows FFMPEG as LGPL2 or could there be a BSD version.
For music, there is very little reason not to use 256Kbps AAC or even higher bitrate. You get maximum compatibility with near no loss of quality. Last time the group listening test there were only a few samples where 256Kbps AAC-LC failed to match Opus.
Youtube did switched to 256Kbps AAC for a while. Only to returned back to 128Kbps Opus.
I hope there can be further improvement to be made with the encoder.