151–160 of 162 posts
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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 i…
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.
Not only is the new AAC Encoder also royalty-free, the AAC-LC codec itself has been declared by Redhat as patent free ( all patent expired ).
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
No matter the process, whether naive fourier transform based, or any possible algorithm that is smarter and tries more things, it cannot make up the true values in all cases, since that data is simply not in the signal.
Ancient methods treated sound as a sum of band limited pure sinewaves, which it is not, and you can claim you reconstructed up to that model, but it's pretty bad, and fails even theoretically for the reasons I posted elsewhere.
So you then start doing all sorts of signal processing, but none can actually reproduce all sounds, and most (all?) methods make tradeoffs - what error do you accept for what gains?
And if you optimize a system for one rate, and don't do it to cover all other sample rates you want to handle well, then you will make some rates worse and some better.
Well designed signal processing has to be careful to handle all the ranges it cares about.
And no one who knows or has worked in these areas would simply drop in a new system that is untested for major uses for such a widespread tool as ffmpeg. Precisely because they understand the nuances in these things.
Earlier quoted context omitted.
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.
They have hardware decoders for JPEG? I have never heard of this and it seems overkill considering how simple it is to decode.
Earlier quoted context omitted.
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.
Opus is used in games.