Live data from Hacker News

Why xHE-AAC is being embraced at Meta

engineering.fb.com

51–60 of 61 posts

Re: Why xHE-AAC is being embraced at Meta

#51

Looks like xHE-AAC beats opus on Topic: A Session In The Abyss: xHE-AAC vs OPUS at 12, 24 and 32 kbps (voice & music) (Read 16655 times) https://hydrogenaud.io/index.php/topic,120997.0.html xHE-AAC vs HE-AAC v2 Audio Quality Comparison: War of the Low-Bitrate Codecs https://www.youtube.com/watch?v=74SsKOUHgvo

>Looks like xHE-AAC beats opus on to be fair that tester indicated only voice being ok, and everything else just bearable under condition you are consciously working under severe bw constrain "EDGE poor network is still enough to stream music without issue (in a tunnel, on mountain…)"

Re: Why xHE-AAC is being embraced at Meta

#52

Looks like xHE-AAC beats opus on Topic: A Session In The Abyss: xHE-AAC vs OPUS at 12, 24 and 32 kbps (voice & music) (Read 16655 times) https://hydrogenaud.io/index.php/topic,120997.0.html xHE-AAC vs HE-AAC v2 Audio Quality Comparison: War of the Low-Bitrate Codecs https://www.youtube.com/watch?v=74SsKOUHgvo

Yeah, opus is incredible for speech, but at those bitrates it gives music a kind of sibilant buzzing that I find really hard to listen to, whereas the muffled/underwater effect of mp3 and aac isn't much worse than just a lowpass filter.

What I found a few years ago was that explicitly lowpassing beforehand to match the other encoders (around 4-8kHz) gets rid of the buzzing. Apparently opus' threshold for automatically doing this is a lot lower than the other encoders; it keeps higher frequencies at the cost of more artifacts. I concluded that decimating or setting the encoder to 8kHz/"wideband" or lower was an improvement, with a similar resulting quality to AAC, but I still slightly preferred Fraunhofer at 12-28kbps.

By default, 12 and 24kbps are particularly bad; at 16k the quality goes up from going mono-only, and by 8k bandpassing is automatic.

Re: Why xHE-AAC is being embraced at Meta

#53
post #3

This codec isn’t supported on the web. So it is Android and iOS only. This post talks about the improved audio quality, but I don’t buy it. This was probably done to reduce storage and bandwidth, not to improve audio quality. Phone speakers aren’t good enough to notice. Also, I wish they had backed opus…

Chrome has supported xHE-AAC since 2020 on Android, 2022 on macOS, and added support on Windows last week.

Interesting. What about Firefox? What about hardware acceleration?

Re: Why xHE-AAC is being embraced at Meta

#55
post #3

This codec isn’t supported on the web. So it is Android and iOS only. This post talks about the improved audio quality, but I don’t buy it. This was probably done to reduce storage and bandwidth, not to improve audio quality. Phone speakers aren’t good enough to notice. Also, I wish they had backed opus…

[deleted]

Re: Why xHE-AAC is being embraced at Meta

#56
post #3

This codec isn’t supported on the web. So it is Android and iOS only. This post talks about the improved audio quality, but I don’t buy it. This was probably done to reduce storage and bandwidth, not to improve audio quality. Phone speakers aren’t good enough to notice. Also, I wish they had backed opus…

Well less bandwidth and storage is also good for users.

Less bandwidth. Some users pay for bandwidth. Or have a monthly cap. So less bandwidth is a monetary advantage for users. It also may decrease time to play.

Similar, but less ctitical, for storage.

One rule of thumb when switching codecs is "don't decrease quality". I buy that Meta did that. Which would result in a slight improvement in quality (of course sold as big snd noticable) while getting storage and bandwidth down (or allow for better quality in the bandwidth adaptive case).

That saud. Yes. OPUS! Although other aites got quite some bad press for low bitrate opus.

Re: Why xHE-AAC is being embraced at Meta

#57

Earlier quoted context omitted.

Chrome has supported xHE-AAC since 2020 on Android, 2022 on macOS, and added support on Windows last week.

Interesting. What about Firefox? What about hardware acceleration?

It may just work in Firefox on OS with xHE-AAC support since they already rely on the system for AAC decoding IIRC. canPlayType/isTypeSupported probably indicate no support unless they've explicitly added support though.

I'm not aware of any hardware acceleration.

Re: Why xHE-AAC is being embraced at Meta

#58
post #26
post #3

This codec isn’t supported on the web. So it is Android and iOS only. This post talks about the improved audio quality, but I don’t buy it. This was probably done to reduce storage and bandwidth, not to improve audio quality. Phone speakers aren’t good enough to notice. Also, I wish they had backed opus…

Reduced bandwidth obviously leads to better quality at the same target bit rate. Phone speakers are good enough to reproduce some obvious compression artifacts of, say, 32k/64k HE-AAC, let alone higher end headphones. ABR could definitely help.

>>Reduced bandwidth obviously leads to better quality at the same target bit rate

or, more likely, lower bandwidth at similar quality.

Re: Why xHE-AAC is being embraced at Meta

#59
post #3

This codec isn’t supported on the web. So it is Android and iOS only. This post talks about the improved audio quality, but I don’t buy it. This was probably done to reduce storage and bandwidth, not to improve audio quality. Phone speakers aren’t good enough to notice. Also, I wish they had backed opus…

Their web version seems to be the fallback (h264 etc) that is guaranteed to run on every device from the last 20 years pretty much. Then again, they clearly don't care about anything outside of their apps, the web experience (instagram especially) is a complete disaster of a walled garden with highly gimped functionality and extreme limitations everywhere. The only good customer is one that willingly opts into all ad…

> The only good customer is one that willingly opts into all ads I guess.

There's indeed some truth to that as well in the sense that the customer is the one who wants the ad to be displayed in the first place and pays for it. So it's a form of opt in as well.

That being said, the user who sees the ads is not the customer but the product. And yes, the best sellable product (i.e. user) for Meta (Facebook, Instagram etc), Alphabet (Google etc) and the like is the one that willingly opts into all ads.

Re: Why xHE-AAC is being embraced at Meta

#60
post #45

Earlier quoted context omitted.

Opus really is great. My first choice almost all the time. Except... I wanted to stream music across the network to another computer with the lowest possible latency. I didn't care about the extra quality you get from lossless (opus sounded fine to me at 96kbps), but chose flac because it has almost no latency. Opus (and for that matter, all other codecs) added noticeable latency.

Opus goes down to 5ms if you customize it, and there's no point in going any lower for Internet streaming because 5ms of raw audio data is only 480 bytes at 16-bit 48khz (plus lots of UDP packet overhead). For latency-sensitive local streaming things are a lot different, and most of your latency will be from buffering to compensate for network jitter. I used Opus for a VOIP app and I was really impressed with it. It'…

I used the both opusenc and ffmpeg, and twiddled with the configuration endlessly for about a week.

Edit: I'll elaborate here. I went all sciencey and wrote a script to test all combinations of a range of encoder settings that included ranges of comp, max delay, frame size, bitrate etc. Multiplied out, that was a lot of different combinations. I ran the script (which took ages because I had to record the startup latency for each one and capture audio on the remote end, logging ffmpeg output etc etc). Sometimes a particular setting was so bad across 5 tests (with different values for other settings) that I'd scrap that whole batch to save time. The ranges of configurations that were promising were used "in real life" to play music in our living room. I narrowed them down to a few that were "usable", but I asked myself "if I bought this thing as a product, would I send it back?". The answer was "yes".

FWIW, the sender was a Macbook Pro 2015 and the receiver was a Raspberry pi 4B

TL;DR At or below 5ms it had reliability issues (drop-outs) that would occur randomly but frequently enough to ruin music listening experience (like, even a 1s drop per song is completely unacceptable). But it also seemed to stretch audio because the delay would increase over time. Even when I got a high quality (zero drop-out steam) with acceptable latency, the latency would slowly increase over time. So about 1 hour into listening, of I paused the source to answer a call, the decoder end would continue playing for 30+ seconds.

I realised that over a LAN, streaming raw audio technically works, with almost zero latency, so I knew that it was the encode/decode that introduced the latency. That's when I switched over to flac, and noticed an immediate improvement in initial latency, but also stopped having the increasing delay over time.

Post reply on HN