Nice, I can’t wait to see how this turns out in practice.
FFmpeg 9.1's new AAC encoder
81–90 of 162 posts
Re: FFmpeg 9.1's new AAC encoder
#82Last 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?
Re: FFmpeg 9.1's new AAC encoder
#83[dead]
Re: FFmpeg 9.1's new AAC encoder
#84Earlier quoted context omitted.
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
No one really offloads AAC, apart from Apple. Opus can be decoded on very cheap microcontrollers entirely in software using the reference library.
On a microcontroller doing nothing else sure. But on a phone, a tablet, a laptop, you absolutely want hardware decode to preserve your battery life.
Re: FFmpeg 9.1's new AAC encoder
#85Man 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.
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.
[deleted]
Re: FFmpeg 9.1's new AAC encoder
#86Man 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.
Most of my collection is Opus 256K, the only downside is support. A lot of tools like Bliss/Roon don't support it :(
Re: FFmpeg 9.1's new AAC encoder
#87Earlier quoted context omitted.
[flagged]
> Falser words hath never been spoken. Why? Care to explain? I have fully switched to opus for lossy since I cannot be bothered to find the sweet spot for aac encoders and bitrate. Opus simply is too good and convenient and has been for ages. What other lossy codec is better and for what reason? Under what circumstances and use cases? I really need put effort in looking for edge cases to not choose opus. Aac is good…
I have the same experience as you and wondered if GP (green account at the time of writing) was trolling. Their other comments seem reasonable though. Based on those, I'm guessing their issue might be compatibility. (Still a flippant and useless comment in isolation, though)
I've not had any issues myself (all players I use supported it already once I learned of Opus' existence about six years ago), but GP doesn't seem to be the only one in this thread. Platforms like youtube don't seem to have an incentive to switch, everyone wants to be compatible with them and they'll re-encode uploads anyhow
Re: FFmpeg 9.1's new AAC encoder
#88Earlier quoted context omitted.
> 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.
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.
To be fair, Opus was never a great name. I always feel the need to specify further when using it outside of a clear context of music codecs (also way before Claude was announced). Love it in every other way though
Re: FFmpeg 9.1's new AAC encoder
#89Earlier quoted context omitted.
Higher sample rates are lower latency for the same block size and resampling is not "free" (pick 2: performance, aliasing, latency) so there can be advantages to working with audio archived at higher sample rates. But all the advantages come down to professional or editing use cases. There's next to zero advantage to using it as a storage format for listening. Just like 24 bit audio (do you have an amp with 96dB SNR?…
> Higher sample rates are lower latency for the same block size This a truly bizarre statement. On the one hand, of course higher sampling rates are lower latency for the same block size measured in samples . But all sampling rates have (almost [0]) identical latency for the same block size measured in time and lower sampling rates allow less computation for those shorter blocks. [0] If you are concerned about needin…
The unit of a block size is samples (frames, technically), not seconds. When configuring audio devices for playback you tune both sample rate and block size for latency. It used to be far more common to tune sample rate than block size alone for tracking. This is getting into the weeds of actual devices though.
Also to your point, this is why compliant peak meters use a mandatory 4x upsampling at 48k.
Re: FFmpeg 9.1's new AAC encoder
#90Earlier quoted context omitted.
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.
Am I reading that chart wrong? I see Opus ahead across every bitrate.
The evaluation tools used are helpful for encoder development, but at best they're imperfect proxies for human perception, and their predictions are often inconsistent with the human experience. I assume that statements like "apparently the best AAC encoder" aren't meant to be taken too seriously, since everybody who does this stuff knows that ABX/MUSHRA tests with real humans is what tells the tale.
On Opus vs. AAC specifically, there's a long history of studies like https://www.researchgate.net/publication/301428302_Perceived... to help answer that question. (There are interesting charts at the top of page 1175.)