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.
FFmpeg 9.1's new AAC encoder
141–150 of 162 posts
#/media/File:Opus_bitrate+latency_comparison.svg){kind=link}
Re: FFmpeg 9.1's new AAC encoder
#142Re: FFmpeg 9.1's new AAC encoder
#143Earlier quoted context omitted.
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.
That's their point though. Basically no modern phone/laptop/tablet other than Apple offloads audio decoding (of any codec) to hardware. You can check this on Android phones by installing the Codec Info app.
Yeah no. All chips in computers, tablets, etc. have hardware decode. Intel chips have hardware decode. AMD, Arm, Raspberry Pi, what have you.
Re: FFmpeg 9.1's new AAC encoder
#144I 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.
Why do you need VBR for audio encoding? VBR audio encoding sounds horrible and it can't save much of bitrate anyway.
Re: FFmpeg 9.1's new AAC encoder
#145Earlier quoted context omitted.
That's their point though. Basically no modern phone/laptop/tablet other than Apple offloads audio decoding (of any codec) to hardware. You can check this on Android phones by installing the Codec Info app.
Yeah no. All chips in computers, tablets, etc. have hardware decode. Intel chips have hardware decode. AMD, Arm, Raspberry Pi, what have you.
I’m pretty sure no x86 chip has hardware decode/encode for audio. Together with dGPUs, they tend to have decoders for JPEG and decoders/encoders for H.264, H.265, AV1 and sometimes VP9.
Re: FFmpeg 9.1's new AAC encoder
#146Man 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.
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...
Re: FFmpeg 9.1's new AAC encoder
#147Earlier quoted context omitted.
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…
That paper was published in 2014. The reference Opus encoder has certainly had a number of improvements that affect sound quality since then, whereas very few AAC implementations have.
Re: FFmpeg 9.1's new AAC encoder
#148Earlier quoted context omitted.
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…
That paper was published in 2014. The reference Opus encoder has certainly had a number of improvements that affect sound quality since then, whereas very few AAC implementations have.
> The reference Opus encoder has certainly had a number of improvements that affect sound quality since then…
Yes, but not for high-bitrate music applications.¹ For example, Opus 1.2 really improved the quality of music encoding at 32–48 kbps. Opus doesn't have to be great at everything to be great at what it does, just like AAC-LC doesn't have to be. (¹Opus 1.6's experimental Opus HD looks very promising for this!)
Apple's and Fraunhofer's closed-source AAC-LC encoders have seen regular, minor quality tuning, and they benefit from the research and engineering work that have been done for the AAC family of encoders (HE-AAC for bitrates down to ~48 kbps, HE-AAC v2 to 32 kbps, xHE-AAC below that).
Re: FFmpeg 9.1's new AAC encoder
#149Earlier quoted context omitted.
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.
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...
I 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.
Re: FFmpeg 9.1's new AAC encoder
#150Earlier quoted context omitted.
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...
I 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…
If the original source is 44.1KHz, and this codec prefers 48KHz, is there an issue up-sampling to 48KHz before doing the AAC encode?
I think that's really the question with this work: up-sampling to 48k, not down-sampling to 44.1k.