FFmpeg 9.1's new AAC encoder

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

by ledoge • 21 days ago

448 148 21 days ago

hydrogenaudio.org

thisislife2• 21 days ago

Flagged for the wrong link.

defrost3• 21 days ago

Hopefully they see this - there's still time to edit the submission link.

ledoge• 21 days ago

It doesn't let me edit the link, but I'm confused by what even happened here... I posted this from my phone and that wrong link doesn't show up in my clipboard history.

Link should be: https://hydrogenaudio.org/index.php/topic,129691.0.html

HugoTea• 21 days ago

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

mcoliver• 21 days ago

https://www.audiolabs-erlangen.de/content/resources/aesCodin...

dcrazy3• 21 days ago

Hah, this sounds like the audio equivalent of Netflix’s grain reconstruction.

lesscraft5• 21 days ago

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

superzazu• 21 days ago

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.

Is 48kHz really the standard nowadays?

TheChaplain• 21 days ago

48kHz has been the recommended setting with Premiere Pro as long as I can remember.

44.1kHz, isn't that what lameMP3 uses as default?

williadc• 21 days ago

It's what CDs use, so it would make sense for mp3 encoders to follow suit.

asveikau• 21 days ago

I know the opus codec assumes everything is 48kHz and will resample inputs to that.

atoav2• 21 days ago

More or less. Streaming is often done with 48, video content has ben 48 for a while now, so unless you still produce content for CDs it is the standard.

44100 Hz had reasons no longer really needed (storing audio in 3 samples per line in VHS: 490 lines × 3 samples × 30 GPS = 44100 sample/s).

Qualitywise both are more than enough snd 99.99% of people would not be able to tell it apart in a blind test. Higher sample rates than 48kHz only needed when you want to pitch down ultrasonic recordings (of whales, bats and other such animals for example).

Aside from this higher than 48 kHz sample rates may have only downsides, like increased size and potential distortion in the ultrasonic frequency range that has sidebands in the audible range. Yet there is a persistent, but unscientific "more-is-better"-crowd in the HiFi-sector.

duped5• 21 days ago

Higher sample rates than 48kHz only needed when you want to pitch down ultrasonic recordings (of whales, bats and other such animals for example).

There are numerous use cases for higher sample rates that go beyond this but it's hard to talk about it without starting flame wars filled with junk science.

someonebaggy2• 21 days ago

VHS doesn't store audio in samples nor does it have 490 lines or 30 G(?)PS. NTSC uses 525 lines per frame and PAL uses 625, both with interlacing at 60 fields per second. The VHS system is analog for audio and video, though analog video has discrete lines, and VHS records discrete stripes on the tape which should be one field each.

44100 was chosen for CD, as 20kHz upper limit of human hearing, doubled for Nyquist theorem, plus a 10% guard band so that anti-aliasing filters don't have to be made of magical fairy dust, plus a bit (maybe to make it relatively prime with something else in the system).

izacus• 21 days ago

Yes, pretty much all new hardware uses it as default output setting as well (by that I mean laptops, phones, smart speakers, etc.)

xuhu• 21 days ago

For one, audio transcription services that use Whisper will sample the input down to 16Khz mono first.

legdoge• 21 days ago

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.

This was of course fixed in Opus.

spider-mario3• 20 days ago

By just always using 48 kHz, from what I recall?

pipo234• 21 days ago

48kHz makes alignment between video and audio so much easier. (I.e.: Lip synchronization after edits)

Joeboy• 21 days ago

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

daneel_w• 21 days ago

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.

lesscraft5• 21 days ago

Pretty much all DACs run at 48Khz by default due to operating systems picking it as a sane default.

bpye• 21 days ago

Pipewire will quite happily pipe through audio without resampling if it is the only source on a system. You can see this by running pw-top and using speaker-test with various sample rates.

chronogram• 21 days ago

Even if it reports 44.1 it resamples internally to 48 in all hardware I've seen.

sneezychl• 21 days ago

A very welcomed addition, hopefully I can replace fdk-aac

cogman102• 21 days ago

Man what a showcase for Opus this is.

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.

ndiddy4• 21 days ago

The biggest advantage for having a good AAC encoder isn't efficiency, it's that for nearly the past 2 decades the de facto standard for live streamed video has been RTMP with H.264 video and AAC audio. There is basically no support for any other codecs. If you want to send a video stream to Youtube or Twitch, you will be sending H.264 and AAC. If you want an idea of how ubiquitous this is, I just checked in OBS and it will not even let you select different video and audio codecs in streaming mode, it just (correctly) assumes that anybody who's streaming will be streaming H.264 and AAC.

repelsteeltje2• 21 days ago

Sample accurate editing is with AAC is a pain though. Especially if you also have video, because frame rates are usually incompatible.

If you want flexibility without fully transcoding both audio and video, Opus is your friend

CharlesW5• 21 days ago

Plus, at 96+ kbps (assuming an Apple-quality AAC-LC encoder) Opus loses its quality advantage. So at higher bitrates, the benefit of choosing Opus is that encoders/decoders are royalty-free.

booi• 21 days ago

Also the fact that hardware-accelerated AAC and even full AAC offload is ubiquitous in modern-ish hardware. I think my rice cooker can play AAC audio

stefan_• 21 days ago

I think often of how all it would have taken was a bomb for the 10 or so people that years ago at some browser vendor consortium out of pure self centeredness went „nah lets fragment“. We could have saved many many collective years, electricity and eyeballs simply watching the most basic content.

jshier• 21 days ago

YouTube actually supports H.265 and VP9 ingest, depending on the streaming protocol. I can actually stream 4K@60 H.265 from my Mac Studio with < 5% CPU usage due to the hardware encoder support in OBS.

https://developers.google.com/youtube/v3/live/guides/ingesti...

someonebaggy2• 21 days ago

The RTMP protocol comes from Adobe Flash which only supported a limited set of codecs, the only still useful ones being H264 and AAC. Nobody published the needed protocol extension "enhanced RTMP" until 2022 and it still isn't supported widely. RTMP is not a generic container for any codec, like Mastroska - RTMP is tightly coupled to the codec.

palmotea• 21 days ago

Man what a showcase for Opus this is.

I take it you mean this Opus (https://en.wikipedia.org/wiki/Opus_(audio_format)) not that Opus (https://en.wikipedia.org/wiki/Claude_(AI)).

I read almost all the way through your comment thinking there was a decent probability you were saying this new AAC encoder was written with Claude Opus.

theandrewbailey• 21 days ago

I've never been AI guy, and have more fascination with audio. I've long stopped being excited when I read "Opus" on HN. It's refreshing when it turns out to be the audio codec.

pezezin2• 21 days ago

No, he was talking about the Opus Dei because this code quality can only be reached by God himself /jk

numlock86• 21 days ago

Opus, the codec, has been a thing looong time before Claude.

divan2• 21 days ago

why is this downvoted? for people who aren't in audio codec dev space, parent comment reads exactly as 'Opus 4.8 rewrote the codec and blew out all competitors'

skydhash2• 21 days ago

I would like Opus, but I’m using a subsonic client on iOS and my choice has been Flac (Alac?), MP3, or AAC. Opus wouldn’t play (There are some that supported it, but I didn’t like their UX).

CharlesW5• 21 days ago

You might like Poppy (in beta), which supports all media servers (including OpenSubsonic/Navidrome) and Opus as a first-class music format. https://www.reddit.com/r/PoppyApp/comments/1tiyki0/about_pop...

lutoma• 20 days ago

You can give Arpeggi a try. It’s still in beta and Testflight only, but already (imo) by far the best iOS app for Navidrome/subsonic servers. It also supports Opus playback on current iOS versions (since Apple added native support for the codec).

jck862• 21 days ago

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.

BoingBoomTschak2• 21 days ago

Eh, I prefer Vorbis mostly because it's still competitive at transparent bitrates (esp. with Aotuv patches) and benefits from a much saner volume normalization spec (simply transfer RG 2.0 tags from the FLAC source): Xiph decided to exclude peak information from Opus' spec while adding that weird thing where album gain is stored in the format header and additional track gain in the metadata.

It also uses less battery on my Rockbox'd Clip+.

a1o2• 21 days ago

I think the biggest issue with Opus is the problem with its specification being lacking, see:

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.

kderbe2• 21 days ago

This essay says it's not possible to make a public-domain implementation of Opus. But it could be released under BSD (as libopus is), which is fine for games, as evidenced by the Licenses section of the credits in many games.

scratcheee• 21 days ago

That’s going a bit far. I’m in the games industry and have used opus regularly, it’s a great codec for games, often the hardware decoding is so restricted that we’re using software regardless so we might as well use something like opus.

The licensing restriction is unfortunate, but only restrictive for those with very specific goals, under normal conditions BSD is a wonderful license for game devs since you’re free to use the code and only have to add an acknowledgement somewhere.

I suppose a public domain game might hit the same limitation, though as a non-lawyer I would guess the chance of anyone with standing trying to sue anyone implementing from this spec is realistically zero (though I don’t fault stb for being unwilling to roll those dice!)

ack_complete• 21 days ago

Most games use the sound support that comes with their game engine or choice of sound system, so I don't think the lack of an STB version is an issue. Performance is more of a problem. Audiokinetic, the makers of the popular Wwise audio system, estimate that Opus takes ~3-5x the CPU of Vorbis:

https://www.audiokinetic.com/en/community/blog/a-guide-for-c...

IshKebab• 21 days ago

He's definitely being way over pedantic. Reading the law like HN programmers imagine it works, rather than how it actually works.

The intent of the legal language in that spec is pretty clearly that you have to use the BSD license if you copy that code, but if you merely read it to understand the spec then you don't.

account42• 20 days ago

Opus is used in games.

upofadown• 20 days ago

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

[1] https://en.wikipedia.org/wiki/Clean-room_design

sbseitz• 21 days ago

Most of my collection is Opus 256K, the only downside is support. A lot of tools like Bliss/Roon don't support it :(

arikrahman• 21 days ago

Took me a second to realize you were talking about the encoder not the model before going into this article

subarctic• 21 days ago

Definitely thought you meant claude opus but now from reading a couple other comments it sounds like you mean something else called opus?

Mashimo• 21 days ago

The open source codec opus https://opus-codec.org/comparison/

richrichardsson• 21 days ago

https://opus-codec.org/

Been around a lot longer than Claude Opus.

bob1029• 20 days ago

https://en.wikipedia.org/wiki/Opus_(audio_format)#/media/Fil...

ndiddy4• 21 days ago

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.

repelsteeltje2• 21 days ago

Why not use a lossless codec if you care about quality? Or use Opus, descent for specht and works pretty much anywhere these days.

CharlesW5• 21 days ago

Why not use a lossless codec if you care about quality?

(1) Lossy codecs are transparent at half the file size (or less) of FLAC/ALAC.

(2) AAC (strictly, AAC-LC) is universal, where FLAC and Opus are not yet there.

ksncksmckwkf2• 21 days ago

You can care about quality to the extent that a lossy codec allows. Lossless is not always necessary or wanted. This is like saying “why care about transcoding quality when you can keep the video as is?”. There’s a myriad of use cases and preferences at play here.

cosmic_cheese• 21 days ago

There are a ton of older, but still perfectly usable devices that support AAC well but not Opus.

Fnoord• 20 days ago

Because almost all people cannot hear the difference between a high quality lossy codec versus lossless in a double blind test. They think they do, but they don't.

kderbe2• 21 days ago

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.

lesscraft5• 21 days ago

The benchmarks were made using afconvert on OSX with the default VBR settings.

madars• 21 days ago

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.

zymhan• 14 days ago

Well tyvm, I found a new tweak for my transcoding pipeline :)

winstonwinston• 21 days ago

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.

ndiddy4• 21 days ago

It gets installed when you install iTunes. If you don't want to install iTunes, you can pull out the codec installer by opening an old version of the iTunes installer in 7-zip and extracting the MSI. Here's a copy I keep around for whenever I have to do a screen recording on a new computer, it's signed by Apple so you don't have to trust me. https://www.infochunk.com/obs/AppleApplicationSupport64.msi

moniosi• 21 days ago

i will never understand apples cuckoldry for proprietary codecs, if it wasn't for their adoption of h265 we would live in the av1 utopia

kasabali• 21 days ago

because H265 predates AV1 by 5 years. H265’s contemporary was VP9, which was honestly worse than H264 done with a good encoder like x264.

refulgentis• 21 days ago

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)

binaryturtle• 21 days ago

I always encode my AAC with VBR. Why wouldn't you, right? I guess I'll stick to apple or fdkaac for now.

timcobb• 21 days ago

Why do you record AAC?

JSR_FDED• 21 days ago

It’s fascinating so much of this comes down to the developer’s own ears - disturbing and quite cool at the same time how subjective this is

ant6n4• 21 days ago

The table and comparison uses “Google's new Zimtohrli, ViSQOL, and my own hearing”

MrBuddyCasino2• 21 days ago

In audio, this is usually the case. Musepack was niche-popular for some time as a simple, but very well tuned codec.

Its the same with speakers and headphones. People think its the component quality, but it’s mostly competency in overall audio physics and the ability to tune well.

esafak• 21 days ago

HA, a blast from the past, when audio encoders were making strides and collecting mp3s was a thing. Same for video encoders.

amluto2• 21 days ago

It was kind of fun being able to easily distinguish 128kbps MP3 from the source audio. (Some early encoders were really bad.)

MrBuddyCasino2• 21 days ago

These kinds of forums are some of the best parts of the internet. Many still exist, but they're slowly shrinking unfortunately.

ant6n4• 21 days ago

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.

SideQuark3• 21 days ago

It’s not that cynical. The author didn’t test on the most common rate in use, so it would be ludicrous for any serious project to wholesale replace a decades old working pipeline with it. It makes perfect sense to wait till due diligence is done.

ant6n4• 21 days ago

It's not cynical. It's dismissive. Especially given that these codecs work in the frequency domain anyway.

>...use 48Khz if you want the best quality.
Yet most of the worlds audio is 44KHz...

ximdotro• 21 days ago

Nice, I can’t wait to see how this turns out in practice.

functionmouse• 21 days ago

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?

pseudosavant• 21 days ago

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.

lesscraft5• 21 days ago

You can use -q:a, for "true" VBR, but its metrics are a few percent (imperceptable, we still win) less. "The benchmarks I posted were done mainly on 44.1Khz. I tuned by ear on 48Khz data though, so some of the windowing/transient logic is tied to 48Khz. It translated to 44.1Khz well enough that I left it as-is, since the timing difference isn't that large."

ezoe• 20 days ago

Why do you need VBR for audio encoding? VBR audio encoding sounds horrible and it can't save much of bitrate anyway.

mondainx• 20 days ago

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.

ksec2• 19 days ago

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.

FFmpeg 9.1's new AAC encoder

Related Stories