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

131–140 of 162 posts

Re: FFmpeg 9.1's new AAC encoder

#131

Post by account42 »

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.

Opus is used in games.

Re: FFmpeg 9.1's new AAC encoder

#132

Post by lutoma »

skydhash wrote: post #26
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 would like Opus, but I’m using a subsonic client on iOS and my choice has been Flac (Alac?), MP3, or AAC. Opus wouldn’t play (There are some that supported it, but I didn’t like their UX).

You can give Arpeggi a try. It’s still in beta and Testflight only, but already (imo) by far the best iOS app for Navidrome/subsonic servers. It also supports Opus playback on current iOS versions (since Apple added native support for the codec).

Re: FFmpeg 9.1's new AAC encoder

#133

Post by spider-mario »

legdoge wrote: post #29
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?

AAC has a strange quirk that the window size is dependent on the sampling rate, thus requiring a complete psychoacoustics reoptimization of all encoder parameters for each sampling rate, since a 20msec window sounds very different than a 60msec window, to human ears. This was of course fixed in Opus.

By just always using 48 kHz, from what I recall?

Re: FFmpeg 9.1's new AAC encoder

#134

Post by nwallin »

davidgerard wrote: post #124
jshier wrote: post #76

Earlier quoted context omitted.

YouTube actually supports H.265 and VP9 ingest, depending on the streaming protocol. I can actually stream 4K@60 H.265 from my Mac Studio with https://developers.google.com/youtube/v3/live/guides/ingesti...

yeah I use vp9 with opus for uploads by choice, it's great! YouTube serves vp9 but it always re-encodes my videos as AV1. Annoying. (I would upload as AV1 but the encoder is slooooooooow.)

> (I would upload as AV1 but the encoder is slooooooooow.)

If you're using libaom, try switching to libsvtav1. It's still slow, but it's slooow instead of slooooooooow.

Re: FFmpeg 9.1's new AAC encoder

#135

Post by spider-mario »

duped wrote: post #103
toast0 wrote: post #69

Earlier quoted context omitted.

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

I wouldn't call archiving a consumer application but I understand the point. Really it gets back to the word: fidelity. Some say it means "truth" but really it's latin for faithful or in the context of audio, perceptually identical (a faithful representation). Even among highly trained and skilled listeners, lossy codecs are faithful and imperceptible.

It’s maybe not a universal consumer application, but it doesn’t seem that outlandish to imagine that some of them might want to protect their personal collection. Or am I that extraordinarily attached to mine?

Re: FFmpeg 9.1's new AAC encoder

#136

Post by spider-mario »

divan wrote: post #125
palmotea wrote: post #21

Earlier quoted context omitted.

> Man what a showcase for Opus this is. I take it you mean this Opus ( https://en.wikipedia.org/wiki/Opus_(audio_format) ) not that Opus ( https://en.wikipedia.org/wiki/Claude_(AI) ). I read almost all the way through your comment thinking there was a decent probability you were saying this new AAC encoder was written with Claude Opus.

why is this downvoted? for people who aren't in audio codec dev space, parent comment reads exactly as 'Opus 4.8 rewrote the codec and blew out all competitors'

> for people who aren't in audio codec dev space

You don’t need to be in the audio codec dev space to have heard of one of the most widespread audio codecs of the last decade (used by YouTube, WhatsApp, SoundCloud and added to WebM in 2013).

Re: FFmpeg 9.1's new AAC encoder

#137

Post by Fnoord »

repelsteeltje wrote: post #22
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…

Why not use a lossless codec if you care about quality? Or use Opus, descent for specht and works pretty much anywhere these days.

Because almost all people cannot hear the difference between a high quality lossy codec versus lossless in a double blind test. They think they do, but they don't.

Re: FFmpeg 9.1's new AAC encoder

#138

Post by duped »

Sesse__ wrote: post #114
duped wrote: post #89

Earlier quoted context omitted.

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.

I didn't say it did?

Re: FFmpeg 9.1's new AAC encoder

#139

Post by divan »

spider-mario wrote: post #136
divan wrote: post #125

Earlier quoted context omitted.

why is this downvoted? for people who aren't in audio codec dev space, parent comment reads exactly as 'Opus 4.8 rewrote the codec and blew out all competitors'

> for people who aren't in audio codec dev space You don’t need to be in the audio codec dev space to have heard of one of the most widespread audio codecs of the last decade (used by YouTube, WhatsApp, SoundCloud and added to WebM in 2013).

Sure, you could've heard about it outside of that space. Yet, most likely, you have not.

It just feels wrong when HN commenters downvote comments that try to clear up legitimate confusion.

Post reply on HN