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

61–70 of 162 posts

Re: FFmpeg 9.1's new AAC encoder

#61

Post by jck86 »

BoingBoomTschak wrote: post #58
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.

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…

For replaygain purposes simply ignore the spec and use RG 2.0 tags? That works with Opus too and hardly any players support Opus R128 gain anyway. For very low spec devices Vorbis would do a bit better though. For legacy devices legacy codecs can be a better fit indeed.

But would you really store new material encoded in Vorbis just to be able to play it on an old device? Vorbis can sound fine, even at lower bitrates like 128k or 96k, but Opus would sound much better. So perhaps then use Vorbis at higher bitrates like +192k? I prefer Vorbis to Aac but at that bitrate minor intricacies of the container format become more important than the codec because audio quality wise they are near indistinguishable.

Re: FFmpeg 9.1's new AAC encoder

#62

Post by winstonwinston »

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 was using FDK AAC encoder, I didn’t know Apple encoder was available for systems other than Apple. Though I have once compared AAC FDK to Apple AAC at 192kbps, and couldn’t tell the difference, while the old FFmpeg AAC encoder fall apart at this bitrate.

Re: FFmpeg 9.1's new AAC encoder

#63

Post by bpye »

lesscraft wrote: post #53
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.

Pipewire will quite happily pipe through audio without resampling if it is the only source on a system. You can see this by running pw-top and using speaker-test with various sample rates.

Re: FFmpeg 9.1's new AAC encoder

#66

Post by amluto »

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

> 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 needing to know future samples in order to calculate the actual signal amplitude at a time between samples, then (a) this matters less at higher sampling rates and (b) this is at most a small number of samples and we're talking about block sizes that presumably exceed, say, 5, so this isn't really a big deal.

Re: FFmpeg 9.1's new AAC encoder

#67

Post by amluto »

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.

It was kind of fun being able to easily distinguish 128kbps MP3 from the source audio. (Some early encoders were really bad.)

Re: FFmpeg 9.1's new AAC encoder

#68

Post by Dylan16807 »

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

> Higher sample rates are lower latency for the same block size

And if your goal is latency, it makes far more sense to change the block size rather than the sample rate.

> But all the advantages come down to professional or editing use cases.

That sounds about right.

Re: FFmpeg 9.1's new AAC encoder

#69

Post by toast0 »

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

> Just personally, I have seen little evidence (personally, professionally, or academically) that there is any advantage for lossless audio for consumer applications

I think the advantage of lossless audio is for archival: rip once, archive as lossless; then you can reencode your library with the latest and greatest lossy encoders over time, or just use the lossless if your player can manage it, cpu and storage is less of a limiting factor for players than 20 years ago.

I don't know how many people are actually managing their libraries these days though, so I dunno if makes a huge difference.

Re: FFmpeg 9.1's new AAC encoder

#70

Post by adgjlsfhk1 »

skydhash wrote: post #33
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.

I know that with oscilloscopes, it’s recommended to use 5x instead of nuquist 2x of the highest frequency you want to use., but the most reasonable argument I’ve heard for higher than 48kHz sampling is digital audio effects. But for the end result 48kHz is more than necessary. I can’t even hear any frequency above 17kHz.

yeah for real time signals higher frequency makes sense (very briefly before you fft and kill the high frequencies), but for stored signals nyquist is king.
Post reply on HN