9 ms·
FFmpeg 9.1's new AAC encoder
- thisislife2 3mo agoFlagged for the wrong link.
- defrost 3mo agoHopefully they see this - there's still time to edit the submission link.
- ledoge 3mo agoIt 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 https://hydrogenaudio.org/index.php/topic,129691.0.html
- defrost 3mo agoYour options are: * quick email to HN@ycombinator.com with a "Help Me please!! and link ( mods can edit link in and sideline (hide) these comments ) * Just live with the rotting fish head of public boo boo (we've all made mistakes, as the Dalek said whilst climbing down off the dustbin) * I can kill the whole thing dead.
- dang 3mo agoIt's fixed now. Our software follows redirs and somehow we got a 302 to our own IP. Perhaps it is someone's idea of a bot detector?
- Aachen 3mo agoUnrelated: Hey, I sent hn@ycombinator.com two emails. One was May 6th, the other June 18th (UTC+2). The former's subject is "Broken prev/next links sometimes". In the latter, I've asked to let me know if it arrived. It didn't bounce so your email server has acknowledged receipt, but based on fast responses to previous emails and someone else mentioning randomly that you responded quickly to theirs in iirc early June, I'm starting to assume you're not seeing mine. I don't know how else to reach out than via an off-topic comment or a dummy submission or so. Is there a fallback mechanism to use when your email doesn't?
- defrost 3mo agoWell, they don't read all the emails -or- respond to @dang, @mod, etc. Your approaches are, ride a comment (as you did, 9 hours, no response, likely didn't read) or lean on a frequent flyer (the only privilege I have is increased ability to [dead] obvious spam not caught by filters - but it gets my emails seen) I sent them an email in past minute - Good Luck! (YMMV)
- HugoTea 3mo 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 3mo agohttps://www.audiolabs-erlangen.de/content/resources/aesCodingTutorial/pns.html https://www.audiolabs-erlangen.de/content/resources/aesCodin...
- dcrazy 3mo agoHah, this sounds like the audio equivalent of Netflix’s grain reconstruction.
- BoingBoomTschak 3mo agoNetflix's or AV1's FGS?
- dcrazy 3mo agoNetflix developed it as a member of AOM.
- lesscraft 3mo agoThe 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 3mo 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?
- deleted 3mo ago[deleted]
- TheChaplain 3mo ago48kHz 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 3mo agoIt's what CDs use, so it would make sense for mp3 encoders to follow suit.
- asveikau 3mo agoI know the opus codec assumes everything is 48kHz and will resample inputs to that.
- atoav 3mo agoMore 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.
- 3mo ago
- sneezychl 3mo agoA very welcomed addition, hopefully I can replace fdk-aac
- cogman10 3mo agoMan 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.
- ndiddy 3mo agoThe 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.
- repelsteeltje 3mo agoSample 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
- ksncksmckwkf 3mo agoOpus is your friend as long as the software you’re using supports it—besides, Apple’s AAC-LC can beat out Opus in low bitrates scenarios. Whether you like it or not, AAC is still the standard.
- ErroneousBosh 3mo agoEditing with any playback-only format like AAC or H.264/5 is a pain. Everyone I've seen complaining about slow choppy playback in DaVinci Resolve appears to be using long-GOP codecs which require a massive amount of processing to decode. It's something like playing out two seconds of video to access every single frame.
- ndiddy 3mo agoNice, 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.
- repelsteeltje 3mo agoWhy not use a lossless codec if you care about quality? Or use Opus, descent for specht and works pretty much anywhere these days.
- CharlesW 3mo 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.
- ksncksmckwkf 3mo agoYou 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 3mo agoThere are a ton of older, but still perfectly usable devices that support AAC well but not Opus.
- Fnoord 3mo agoBecause 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.
- refulgentis 3mo agoOlder 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 3mo agoI always encode my AAC with VBR. Why wouldn't you, right? I guess I'll stick to apple or fdkaac for now.
- JSR_FDED 3mo agoIt’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
- ant6n 3mo agoThe table and comparison uses “Google's new Zimtohrli, ViSQOL, and my own hearing”
- MrBuddyCasino 3mo agoIn 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 3mo agoHA, a blast from the past, when audio encoders were making strides and collecting mp3s was a thing. Same for video encoders.
- amluto 3mo agoIt was kind of fun being able to easily distinguish 128kbps MP3 from the source audio. (Some early encoders were really bad.)
- MrBuddyCasino 3mo agoThese kinds of forums are some of the best parts of the internet. Many still exist, but they're slowly shrinking unfortunately.
- ant6n 3mo agoThis 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.
- SideQuark 3mo agoIt’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.
- ant6n 3mo agoIt'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...
- SideQuark 3mo agoI take it you don't know much about frequency time tradeoffs. It is not possible to convert 48 khz to 44 khz without approximation. And there is incredible room to design filters that have great response at frequency X but terrible at a nearby frequency, since most of filter design is about where to stash the noise. That noise can add perceptible beats to audio. And don't try some silly Nyquist limit stuff - none of that is actually correct in actual filtering. The initial simple reasons are that that stuff assumes infinitely precise, mathematically perfect sample values - impossible since these are PCM. They assume infinitely periodic inputs, also false (and there's an entire industry of trying to find window functions to smooth lack of periodicity, also with flaws and tradeoffs). For perfect reconstruction, they use sinc, which has infinite support, which is not computable. So people think they'll use some windowed sinc, which again then fails to do reconstruction fully. After these ancient, and in practice lacking, ideas, modern filter theory and practice has invented generalized sampling, which has provably (from math and in practice) better signal reconstruction. And even that is only the tip of an iceberg of knowledge. These codes don't simply "work in the frequency" domain as if this is old school DFT stuff. Even in that domain, your claims don't work. These codecs also do psycho-acoustic modeling, to be able to decide which data to drop, alter, increase, or decrease, to get following bitratres to encode at target. Again, these type of filters and models can be terrible at 44, but awesome at 48. So yes, they do need to test before putting this into the world's most used by far audio/video transcoder. So yes, is is cynical, apparently driven by ignorance.
- ximdotro 3mo agoNice, I can’t wait to see how this turns out in practice.
- functionmouse 3mo agoLast 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?
- thomasnowhere 3mo ago[dead]
- pseudosavant 3mo agoI 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.
- lesscraft 3mo agoYou 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 3mo agoWhy do you need VBR for audio encoding? VBR audio encoding sounds horrible and it can't save much of bitrate anyway.
- mondainx 3mo agoThis 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.
- ksec 3mo agoAAC-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.
- 0xKalel 2mo ago[flagged]