Skip to main content

Topic: xHE-AAC. Is it ready yet? Any encoders out there? (Read 9642 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • IgorC
  • [*][*][*][*][*]
Re: xHE-AAC. Is it ready yet? Any encoders out there?
Reply #25
From the same paper https://dl.dropboxusercontent.com/u/61700377/misc/20130920_Streaming_Codec_Study_Report.pdf

Quote
Interestingly, results were quite flat starting at 32 kbps, suggesting that listeners did not hear marked
improvements at higher bit rates
:o
This is so wrong I don't even know which argument to start with.
Let's just put it in a technical terms.

If your codec and /or test present the same not so good quality (MUSHRA 60 = MOS 3) both at 24-32 kbps and higher bitrate 64 kbps then there is something really wrong with your codec and/or test. 

Also according to their test  their xHE-AAC 64 kbps = MP3 96 kbps. Even MP3pro (MP3+SBR) 64 kbps is on par with legacy MP3 96 kbps. So  this particular tested implementation of xHE-AAC doesn't bring nothing new to 14 years old SBR (?). 




Another interesting statement about bitrates and 4G.
Quote
Based on our research, we recommend keeping the bit rate of streams
as low as possible, consistent with high audio quality.  For the HE‐AAC codec, we believe this balance is achieved
at a constant stream rate of 48 kbps

Something obvious but still.  Audio quality isn't  high  at 48 kbps with any codec. OK quality, maybe.

 I don't beleive that such low bitrate 48 kbps can prevent dropout.
1. It's impossible to "pre-buffer" a real-time radio.
2. The rate of 4G is far superior than any logical audio bitrates. I have an unlimited 4G 30 Mbits connection on my phone. A speed  can drop down to ~300-700 kbps in worst congestion case (and I still get Spotify working at 96/160/320 kbps)
Still far superior to 48-100 kbps.  But if there is some area with no 4G You lose a connection per completely then  even xHE-AAC 16 kbps won't help here.

So all this point of very low bitrate on 4G is very moot.

P.S. They push low bitrates and xHE-AAC for an obvious reason.
Why would someone pay more if LC-AAC (which is almost 20 years old) is doing already great at  80-96 kbps without all that extra pay for a newer low-bitrate codec with a load of patents for semi-parametric or parametric coding tools like SBR, PS, SBS, MPS, advanced LPC, IGF, ELT etc.
  • Last Edit: 09 October, 2016, 02:32:38 PM by IgorC

  • polemon
  • [*][*][*]
Re: xHE-AAC. Is it ready yet? Any encoders out there?
Reply #26
IgorC: A result like that is a little shaky, and I think their graphs are a little weird, too.

I think as for low bitrates in the mobile market it doesn't make much sense these days, as providers are pushing for higher bandwidths constantly.
A point where it makes sense to me though, is when it comes to streaming costs. Most providers (mine included) charge for traffic volume. So, when you have less traffic you pay less, so that makes sense. Especially, when you're using that streaming service in your car, etc. where sound quality isn't perfect anyway.

But I'm only really interested in how it performs against Opus. What they claim is one thing, as long as I can't test it myself, it's not really that interesting to me. I don't see myself using DRM over AM, as I don't really have a need for that. But I guess it'd make sense if you're in a remote area, or on a boat or something, and all you can get is AM radio.

I'm a big fan of Codec2, which to me covers the "lower end" of the bandwidth spectrum. I'm a little surprised by the fact the radio operators don't settle on Opus, as it is free, it is a low-latency codec, and provides adequate quality on low bandwidths. I'm not a marketing person, so I guess there's something I simply don't see.
-EOF-

  • IgorC
  • [*][*][*][*][*]
Re: xHE-AAC. Is it ready yet? Any encoders out there?
Reply #27
polemon,
Quote
Most providers (mine included) charge for traffic volume. So, when you have less traffic you pay less, so that makes sense.
That's true.

Quote
But I'm only really interested in how it performs against Opus.
That depends on particular implmentation(encoder) of xHE-AAC.
While there is only one Opus reference implementation there can be multiple xHE-AAC encoders with different audio quality.

You can find some samples of USAC (xHE-AAC) here https://hydrogenaud.io/index.php/topic,106938.msg875351.html#msg875351
That is a reference high quality USAC encoder which isn't available.

I have compared it with Opus some years ago and here are my conslusions:
32 kbps, stereo. USAC is better than Opus.  It's not a surprise as Opus is a low-delay codec and frequency leakeage is big at very low bitrate. While USAC benefits from 100+ ms delay.

48 kbps, stereo. That's where it starts changing. Opus 1.1 was somwehat inferior to HE-AAC and USAC. But the latest alpha 1.2 should be already on par with USAC and somewhat better than HE-AAC.

64 kbps and higher bitrates, stereo. That's where both Opus and USAC already push the limits what can be done with lossy audio compression. Both are good and better than HE-AAC and LC-AAC. It will take at least 5 years or so to make something better than that.

But that's with USAC reference highest quality encoder which isn't available publicly.
That particular xHE-AAC encoder from paper isn't very high qualtiy implementation of standard.
If You want to know an average MUSHRA scores for Opus  the I can provide them knowing the previous results of Hydrogenaudio tests and from my personal experience with it.
MUSHRA:
Opus 48 kbps ~65-70.
Opus 64 kbps ~80-85
Opus 96 kbps ~90-95

The main rule is MOS (hydrogenaudio tests) = MUSHRA/20

Also there is some information about Opus vs EVS (enhanced for low delay xHE-AAC) at 48 kbps, mono
https://hydrogenaud.io/index.php/topic,106938.msg875399.html#msg875399
But Opus 1.2 (which is in development now) shoud do better
  • Last Edit: 10 October, 2016, 02:18:41 PM by IgorC

  • rogeriol
  • [*]
Re: xHE-AAC. Is it ready yet? Any encoders out there?
Reply #28
it's a shame that no encoders are available for general use. it seems this codec is very restricted, only in dedicated hw for now.