Birbla

Discussion summary

FFmpeg 9.1 introduces a new AAC encoder, with users hopeful about improved quality and performance. Some express nostalgia for older encoders and discuss the relevance of AAC versus Opus.

What the discussion says

  • Users are optimistic about the new AAC encoder's potential improvements.
  • Some recall past issues with audio quality in FFmpeg encodings.
  • Debate on AAC's future relevance compared to Opus.
“Hopefully they see this - there's still time to edit the submission link.”
— defrost
“Last time I used ffmpeg to encode songs for my iPod nano they were broken.”
— functionmouse

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • A very welcomed addition, hopefully I can replace fdk-aac
    by sneezychl
  • 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.
    by mondainx
  • HA, a blast from the past, when audio encoders were making strides and collecting mp3s was a thing. Same for video encoders.
    by esafak
  • These kinds of forums are some of the best parts of the internet. Many still exist, but they're slowly shrinking unfortunately.
    by MrBuddyCasino
  • It was kind of fun being able to easily distinguish 128kbps MP3 from the source audio. (Some early encoders were really bad.)
    by amluto
  • 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.

    by ksec
  • 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)
    by refulgentis
  • I always encode my AAC with VBR. Why wouldn't you, right? I guess I'll stick to apple or fdkaac for now.
    by binaryturtle
  • 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
    by JSR_FDED
  • The table and comparison uses “Google's new Zimtohrli, ViSQOL, and my own hearing”
    by ant6n
  • 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.

    by MrBuddyCasino
  • 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.
    by ant6n
  • 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.
    by SideQuark
  • 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.

    by pseudosavant
  • Why do you need VBR for audio encoding? VBR audio encoding sounds horrible and it can't save much of bitrate anyway.
    by ezoe
  • 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."
    by lesscraft
  • > 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?

    by superzazu
  • Yes, pretty much all new hardware uses it as default output setting as well (by that I mean laptops, phones, smart speakers, etc.)
    by izacus
  • 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.
    by daneel_w
  • Pretty much all DACs run at 48Khz by default due to operating systems picking it as a sane default.
    by lesscraft
  • I know the opus codec assumes everything is 48kHz and will resample inputs to that.
    by asveikau
  • 48kHz makes alignment between video and audio so much easier. (I.e.: Lip synchronization after edits)
    by pipo234
  • 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.

    by legdoge
  • 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.

    by atoav
  • 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

    by Joeboy
  • >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

    by HugoTea
  • https://www.audiolabs-erlangen.de/content/resources/aesCodin...
    by mcoliver
  • 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).
    by lesscraft
  • 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.
    by ndiddy
  • 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
    by moniosi