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

51–60 of 162 posts

Re: FFmpeg 9.1's new AAC encoder

#51

Post by lesscraft »

kderbe wrote: post #45
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…

In the Hydrogenaudio discussion thread's metrics table, the new encoder scores better than Core Audio. But this is at constant bitrate (CBR) [edit: maybe not? see lesscraft's reply below]. Core Audio also has variable bitrate modes (TVBR) which the new encoder lacks. So maybe Core Audio will continue to be the best when TVBR is available, but I'm hopeful the new FFmpeg encoder will be "good enough", especially if mor…

The benchmarks were made using afconvert on OSX with the default VBR settings.

Re: FFmpeg 9.1's new AAC encoder

#52

Post by lesscraft »

booi wrote: post #50
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…

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.

Re: FFmpeg 9.1's new AAC encoder

#53

Post by lesscraft »

superzazu wrote: post #8

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

Pretty much all DACs run at 48Khz by default due to operating systems picking it as a sane default.

Re: FFmpeg 9.1's new AAC encoder

#54

Post by lesscraft »

HugoTea wrote: post #7

>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

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

Re: FFmpeg 9.1's new AAC encoder

#55

Post by scratcheee »

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.

That’s going a bit far. I’m in the games industry and have used opus regularly, it’s a great codec for games, often the hardware decoding is so restricted that we’re using software regardless so we might as well use something like opus.

The licensing restriction is unfortunate, but only restrictive for those with very specific goals, under normal conditions BSD is a wonderful license for game devs since you’re free to use the code and only have to add an acknowledgement somewhere.

I suppose a public domain game might hit the same limitation, though as a non-lawyer I would guess the chance of anyone with standing trying to sue anyone implementing from this spec is realistically zero (though I don’t fault stb for being unwilling to roll those dice!)

Re: FFmpeg 9.1's new AAC encoder

#56

Post by jck86 »

ksncksmckwkf wrote: post #42
jck86 wrote: post #28

Earlier quoted context omitted.

Choosing a lossy audio codec has become such a no brainer. Either use opus and be done with it or if for some reason opus cannot be used then use aac for compatibility with insane high bitrate for good quality without having to do research on what encoder and mode to pick. Still having a good quality and default aac encoder is great. Though I don't get why it is mainly CBR.

[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 too, but way too many choices to make for storing mass material for the long term and be sure the quality is always good enough.

Re: FFmpeg 9.1's new AAC encoder

#57

Post by ack_complete »

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.

Most games use the sound support that comes with their game engine or choice of sound system, so I don't think the lack of an STB version is an issue. Performance is more of a problem. Audiokinetic, the makers of the popular Wwise audio system, estimate that Opus takes ~3-5x the CPU of Vorbis:

https://www.audiokinetic.com/en/community/blog/a-guide-for-c...

Re: FFmpeg 9.1's new AAC encoder

#58

Post by BoingBoomTschak »

jck86 wrote: post #28
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.

Choosing a lossy audio codec has become such a no brainer. Either use opus and be done with it or if for some reason opus cannot be used then use aac for compatibility with insane high bitrate for good quality without having to do research on what encoder and mode to pick. Still having a good quality and default aac encoder is great. Though I don't get why it is mainly CBR.

Eh, I prefer Vorbis mostly because it's still competitive at transparent bitrates (esp. with Aotuv patches) and benefits from a much saner volume normalization spec (simply transfer RG 2.0 tags from the FLAC source): Xiph decided to exclude peak information from Opus' spec while adding that weird thing where album gain is stored in the format header and additional track gain in the metadata.

It also uses less battery on my Rockbox'd Clip+.

Post reply on HN