Next-Gen Low-Latency Open Codec Beats HE-AAC

Aldenissin writes "From the Xiph.org developers, Opus is a non-patent encumbered codec designed for interactive usages, such as VoIP, telepresence, and remote jamming, that require very low latency. When they started working on Opus (then known as CELT), they used the slogan 'Why can't your telephone sound as good as your stereo?', and they weren't kidding. Now, test results demonstrate that Opus's performance against HE-AAC, one of the strongest (but highest-latency) codecs at this bitrate, bests the quality of two of the most popular and respected encoders for the format, on the majority of individual audio samples receiving a higher average score overall. Hydrogenaudio conducted a 64kbit/sec multiformat listening test including Opus, aoTuV Vorbis, two HE-AAC encoders, and a 48kbit/sec AAC-LC low anchor. Comparing 30 diverse samples using the highly sensitive ABC/HR methodology, Opus is running with 22.5ms of total latency but the codec can go as low as 5ms."

Re:sorry for being dense, but...

[Anaerin]

As mentioned, it's needed for VoIP systems. With a full-duplex system, more than 150ms of lag is audible and noticeably uncomfortable, breaking the flow of conversation (As the apparent lag is doubled in a "conversation", with the delay at each end adding cumulatively). For simple half-duplex systems like gaming, more lag is not really noticeable.

That's all fine and dandy, but....

[adolf]

Who cares what codec is being used for my VoIP phone at home or on my desk, when anyone I call is still most likely to be connected over the PSTN with g.711 or g.723, or (far worse) a cell phone?

And don't get me wrong: I want to care; I really do. And maybe I did care, at one point. I was going to build an Asterisk system for home -- I even collected some of the hardware to make it work.

But I stopped caring when the boy got old enough to properly want a cell phone, the wife got a cell phone, and I had a cell phone. After that, I dropped the home phone line altogether, since it was just a waste of money.

I have no interest, at this moment, in having any sort of telephony tied to my premises.

And while I could, I suppose, run some manner of VoIP client on my Droid over cellular, I think that's a complete non-starter at the moment: I had trouble earlier today getting a 64kbps MP3 to stream correctly over 3G Verizon (even though I controlled both ends of the stream), but that was just an inconvenience.

It'd be a lot more than simply inconvenient if my phone calls were that spotty. I don't care how good it sounds if it doesn't work.

Is there any good and practical use for this new codec?

Re:That's all fine and dandy, but....

[nog_lorp]

Lol what? You're crazy. I suppose it is never worth inventing a new codec ever, since everyone uses old codecs! /fail argument

Re:HE-AAC is worse than LE-AAC in terms of quality

[woolpert]

HE-AAC uses SBR to reduce its data footprint. This results in worse reproduction of the source audio than LE-AAC at same bitrate (and often even lower bitrate). The whole deal with HE is that it can maintain good quality at very low bitrate, by giving up accuracy. So far, Apple's LE-AAC encoder in their Core Audio framework is the best choice for digitally non-lossless compression.

While your rant appears informative if not insightful on its face, it is completely missing the point.

This is a test of audio codecs at low bitrates.

I don't know what this "LE-AAC" is you speak of (and rather suspect you don't either) but AAC-LC was actually in this test, as the low anchor.

At these bitrates (~64kbps) HE-AAC (despite its "low-accuracy" as you put it) is perceptually better sounding than AAC-LC. Lossy audio codecs (even the LE-AAC [sic] encoder in Apple's Core Audio framework you love) can only be judged by how they sound, not how they look. "Accuracy" is not a metric very worthy of discussion.

Re:Next level beats

[Skuto]

Perhaps they could switch to "has not yet been challenged in court for any possible patent infringement". But who would use a codec like that? Besides Google, of course.

Companies do this all the time. Anyone shipping H.264 has this risk, as the patent pool provides zero guarantee no outside patents will pop up.

Actually, anyone shipping anything at all has this risk.

Realistically, it's more like "does not infringe any known patents, or has licenses for them, and is not infringing any other patents that we could find in a patent search".