Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FFmpeg 9.1's new AAC encoder

hydrogenaudio.org

Post reply on HN
Print view View original

111–120 of 162 posts

Re: FFmpeg 9.1's new AAC encoder

#111

Post by AnggaSP »

lesscraft wrote: post #52
booi wrote: post #50

Earlier 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.

There absolutely does, Android did with low power audio. They even goes a step further by offloading bluetooth processing into DSP.

I’m not in this space anymore but as of Android 5-6 era aac and bt is offloaded to hexagon dsp on qualcomm device.

Re: FFmpeg 9.1's new AAC encoder

#112

Post by jpc0 »

duped wrote: post #34
zamadatix wrote: post #24

Earlier quoted context omitted.

Say it or don't but "I have evidence otherwise but don't think I should say" is just as bad a flame war gateway as tempting the junk science audiophiles directly.

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?…

Group delay is a poor argument.

Unless you also have a pretty decent monitoring system the group delay of the speakers isn't going to be consistent so the filters before them wouldn't matter all that much...

Even in that case I would have a hard time believing that any human in a blind test would be able to perceive a group delay of even 360deg above 2k...

You are talking about sub milliseconds differces in the time frequency content arrives at the ears, just tiling your head slightly will have a greater impact...

Re: FFmpeg 9.1's new AAC encoder

#113

Post by ant6n »

SideQuark wrote: post #98
ant6n wrote: post #80

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.

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...

Re: FFmpeg 9.1's new AAC encoder

#114

Post by Sesse__ »

duped wrote: post #89
amluto wrote: post #66

Earlier quoted context omitted.

> 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.

> Also to your point, this is why compliant peak meters use a mandatory 4x upsampling at 48k.

This isn't due to latency, it's because the true peak (in the analog waveform) could be between samples.

Re: FFmpeg 9.1's new AAC encoder

#115

Post by MrBuddyCasino »

JSR_FDED wrote: post #59

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

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.

Re: FFmpeg 9.1's new AAC encoder

#116

Post by ErroneousBosh »

repelsteeltje wrote: post #25
ndiddy wrote: post #20

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…

Sample 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

Editing 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.

Re: FFmpeg 9.1's new AAC encoder

#117

Post by ZeroGravitas »

AnggaSP wrote: post #111
lesscraft wrote: post #52

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.

There absolutely does, Android did with low power audio. They even goes a step further by offloading bluetooth processing into DSP. I’m not in this space anymore but as of Android 5-6 era aac and bt is offloaded to hexagon dsp on qualcomm device.

You might be referring to this but on top of hardware decode some Bluetooth setups can send the actual AAC file to the headphones and decode it there.

Traditionally Bluetooth audio meant decoding and reencoding it into a crappier codec before transmission. So it's an efficiency and quality win.

I think some Google Pixel Bud Pro earphones do this for Opus but that is rarer (there's a few other codecs that have been done like this over the years by different manufacturers).

Re: FFmpeg 9.1's new AAC encoder

#118

Post by kasabali »

moniosi wrote: post #73
ndiddy wrote: post #17

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…

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

because H265 predates AV1 by 5 years. H265’s contemporary was VP9, which was honestly worse than H264 done with a good encoder like x264.

Re: FFmpeg 9.1's new AAC encoder

#119

Post by IshKebab »

a1o wrote: post #38
cogman10 wrote: post #16

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.

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.

He's definitely being way over pedantic. Reading the law like HN programmers imagine it works, rather than how it actually works.

The intent of the legal language in that spec is pretty clearly that you have to use the BSD license if you copy that code, but if you merely read it to understand the spec then you don't.

Re: FFmpeg 9.1's new AAC encoder

#120

Post by MrBuddyCasino »

esafak wrote: post #64

HA, a blast from the past, when audio encoders were making strides and collecting mp3s was a thing. Same for video encoders.

These kinds of forums are some of the best parts of the internet. Many still exist, but they're slowly shrinking unfortunately.
Post reply on HN