Opus 1.1 Released

New submitter rvalles writes "Xiph.org just released a major update to their Opus audio codec. Opus 1.1 offers major improvements over last year's 1.0.2 release. Opus is a general-purpose, very flexible, open and royalty-free audio codec that offers low-latency and high quality/bitrate, incorporating technology from Skype's SILK codec and Xiph.Org's CELT codec. Its first release beat everything else last year at 64kbit/s in a listening test held at HydrogenAudio."

Comments

Nice, impressive achievement

[hattig]

A quick question: Is this supported in hardware (to prolong battery life) in mobile devices that can play audio?

I expect more generalised hardware (i.e., programmable DSPs) can be made to support it on the DSP that is present in the audio/video decode functional blocks of the SoC.

Re:Nice, impressive achievement

[Skuto]

Depends on what mobile device? The reference code has extensive ARM optimizations, that's in fact one of the main improvements in 1.1 And yes, it can be accelerated with a programmable DSP if present, IIRC there's some support for C55x in the same reference code.

Audio decoding is fast enough on modern ARM SoC that dedicated hardware isn't strictly needed to get good battery life.

Re:Nice, impressive achievement

[savuporo]

The thing about audio encode/decode is that its relatively low MIPS - with todays mobile CPUs its almost not worth the complexity to offload it to DSP. During a call your CPU has to stay awake anyway and drain battery, there is very little wattage saving moving it to DSP. It would only make sense if you are dealing with multiple, and i mean more than 2 simultaneous encoded streams ( decode is cheap ). The story was different a few years ago when the dominant CPU was ARM9 running in a 150-200 mhz range, where audio codec easily chewed up 50% or more available MIPS.

Video encoding is a whole different matter of course.

Re:Nice, impressive achievement

[savuporo]

Also note - any sort of offload will add some latency, because you have to have a buffer between DSP and main CPU for them to run asynchronously. That latency is often undesireable.

Re:Nice, impressive achievement

[Anonymous Coward]

For audio decode? You know how little data that is? The latency must be microseconds.

Re:Nice, impressive achievement

[savuporo]

You didnt get it - the speech codecs encode data at 10 millisecond or 20 millisecond intervals, depending. Sometimes 50-60 millisecond multiframe packets. For the two cores to work asynchronously, you have to hand over the minimum of one frame, for efficiency's sake preferrably more. So minimum incurred latency is at least one frame or 10 milliseconds - normally more in offloads.

Compatibility

[Anne_Nonymous]

So is this backwards compatible with my existing Monster Cables or do I have to buy new ones?

Re:Compatibility

[jmv]

So is this backwards compatible with my existing Monster Cables or do I have to buy new ones?

You will just need to update the firmware on your cables if you want to maintain optimal RDF (reality distortion field).

Re:Compatibility

[Anonymous Coward]

So is this backwards compatible with my existing Monster Cables or do I have to buy new ones?

Your comment did make me lol just a bit. ;) I can actually see this happening in Monster advertising sometime soon.....

Re:Compatibility

[jones_supa]

The psychoacoustic model of your old cables is completely wrong. To really get a musical experience, there will be rolled out a product just for your needs soon. Starting at the low, low price of $999.

Re:Compatibility

[Anonymous Coward]

I've actually been waiting for monster to put audio files on their website to "recalibrate" the cables. But yours is just evil. Use a magic word like firmware and that hook for the suckers would have much more purchase.

never heard of Opus

[Anonymous Coward]

I've heard of Vorbis and FLAC on Xiph.org though. Thanks for posting the link.

Oh lookie

[Anonymous Coward]

Another audio "standard" that will be completely ignored by everyone other than hardcore geeks. Just like OGG, FLAC, AMR...

Re:Oh lookie

[Skuto]

AMR is pretty widely used as a voice codec, Ogg is used in most major AAA games, and as for Opus/SILK, you might have used Skype before...

Re:Oh lookie

[Anonymous Coward]

Another audio "standard" that will be completely ignored by everyone other than hardcore geeks. Just like OGG, FLAC, AMR...

No it will be ignored by all those that like being fucked with closed ecosystems.
I.e. Apple and Microsoft shitheads. Everybody else will do fine.

My Samsung GS3 plays almost all audio formats, mp3s, OGGs and Flacs. :)

Re:Oh lookie

[Skuto]

>I.e. Apple and Microsoft shitheads

Microsoft was a major contributor to Opus through Skype, both with code and by providing their patents royalty free.

Re:Oh lookie

[Anonymous Coward]

Three bites in fifteen minutes. Not bad...

Re:Oh lookie

[Anonymous Coward]

Correct me if I'm wrong, but I believe Skype contributed Silk many years before Microsoft turned around. Attributing that now to Microsoft seems misguided.

Re:Oh lookie

[jmv]

Sure, this was originally Skype, but Microsoft has continued to work with us even after acquiring Skype.

Re:Oh lookie

[Anonymous Coward]

How does it feel having Ballmer's 10" long, 4" wide throbbing dick up your butt?

Re:Oh lookie

[denis-The-menace]

INFO: Even BlackBerry Z10 phones (and up) supports MP3, Ogg and FLAC natively.

Re:Oh lookie

[Anonymous Coward]

I use ogg, I use flac, they work, and they save me space over mp3 or uncompressed audio.
I might be the only one in the universe... so?

Re:Oh lookie

[Anonymous Coward]

Are you saying you would rather those free and open audio formats disappeared? The RIAA must be proud.

Re:Oh lookie

[jones_supa]

No it will be ignored by all those that like being fucked with closed ecosystems.
I.e. Apple and Microsoft shitheads. Everybody else will do fine.

Aww...ain't you a cute Linuxboy. ;)

Re:Oh lookie

[Desler]

The RIAA has nothing to do with audio formats or their creation/standardization. Also, MP3, AAC, etc. are open formats. One can implement them from publicly-accessible format specs.

Re:Oh lookie

[Anonymous Coward]

Trick question. Ballmer is obviously an over-compensating eunuch, so it doesn't feel at all.

Props to the authors of TFA

[DigitAl56K]

As someone who has previously written outwardly facing articles on complex technology, I have to give props to "Monty" and Jean-Marc Valin for TFA. It takes a lot of skill to communicate good information about some very complex topics in a short amount of space, and they pull it off pretty well. I think it really helps sell the product and keep your enthusiasts more engaged when you can see how much work and thoughtfulness has gone into the guts of it - work that is often unseen, hidden within a dev team, or buried throughout a mailing list somewhere.

Re:Props to the authors of TFA

[Trepidity]

Yeah, Monty's writing on these topics is exceptionally clear. His series on the Daala video codec introduces modern video encoding in a way that's amazingly accessible. Maybe he should write a textbook.

Re:Props to the authors of TFA

[ljw1004]

I love this section from the Opus 1.1 release notes:

1.1 also adds temporal VBR, an accidental discovery from a bug in an earlier pre-release. Temporal VBR is new heuristic that adds bits to loud frames and steals them from quiet frames. This runs counter to classic psychoacoustics; critical band energies matter, not the broadband frame energy. In addition, TVBR does not appear to be exploiting temporal postecho effects.

Nevertheless, listening tests show a substantial advantage on a number of samples. I'll be the first to admit we haven't completely determined why, but my best theory is that strong, early reverberant reflections are better coded by the temporary allocation boost, stabilizing the stereo image after transients especially at low bitrates.

Re:Props to the authors of TFA

[dylan_-]

Can you supply audio information at a latter time, and trick the brain into interpreting it as having happened earlier by "context"?

Re: Props to the authors of TFA

[The Other White Meat]

It really depends on the buffer size, which tends to be brain specific.

Re:Props to the authors of TFA

[Anonymous Coward]

not read TFA, but is this not pretty much what a-law does? less resolution at lower volumes at the cost of dynamic range rather than accuracy granted?

Already has good adoption

[pavon]

Opus wasn't designed for audio files, but for streaming audio. In that realm it's adoption looks very promising. It has already been integrated into the Skype codebase and will likely be used in the next major release of Skype. It is also one of two mandatory audio codecs for in the draft for WebRTC, which is a new standard for browser-based chatting.

Re:Already has good adoption

[X0563511]

Why would browser-based chat need audio streaming?

Re:Already has good adoption

[Desler]

So you can have a voice chat?

Re:Already has good adoption

[aardvarkjoe]

Because not all of us can read lips?

Re:Already has good adoption

[X0563511]

Then use a VOIP solution.

Re:Already has good adoption

[X0563511]

What does lip reading have anything to do with chat (ie, text communication)?

Re:Already has good adoption

[Desler]

WebRTC is a VOIP solution. You seem to be the only one pigeonholing it as a text-only chat.

Re:Already has good adoption

[Desler]

Since when is WebRTC text-only? From Google's original announcement:

Today, Google made available WebRTC, an open source software package for real-time voice and video on the web that we will be integrating in Chrome.

Re:Already has good adoption

[aardvarkjoe]

What does lip reading have anything to do with chat (ie, text communication)?

Somehow you seem to have come to the conclusion that "chat" means "digital communication using text." It doesn't. The verb "chat" predates digital text communication by a very, very long time.

Re:Already has good adoption

[X0563511]

First time I've seen that, I apologize. I was going off of:
"WebRTC, which is a new standard for browser-based chatting."

Web chatting is just that - chat. Thus my confusion.

Re:Already has good adoption

[X0563511]

I apologize. I was going off of:
"WebRTC, which is a new standard for browser-based chatting."

Blame pavon.

Web chatting is just that - chat. Thus my confusion.

Re:Already has good adoption

[X0563511]

But it's usage on computers has, for the 20 or so years before VOIP was common, been text-only. Witness items such as IRC, ICQ, AIM, etc.

Anyway I did not realize WebRTC was not actually one of these kinds of things, pavon incorrectly described "real-time audio and video" as "web chat."

Re:Already has good adoption

[Anonymous Coward]

"Chat" means only to talk to someone casually. It in no way implies "text chatting". You're either 10 years old or not a native English speaker since people have talked about "chatting on the phone" for decades in the US at least.

Re:Already has good adoption

[Desler]

"Web chatting" has included voice and video for more than a decade.

Re:Already has good adoption

[Desler]

Skype has been a "voice chat" program for going on 10 years. And, yes, it was called as such back in 2003.

Re:Already has good adoption

[MrNemesis]

It may not have been designed for audio files, but it's pretty damn good at them anyway - the hydrogen audio chaps rate is as equivalent to AAC and vorbis at the same bitrate, as well as having excellent quality at low bitrates along with low algorithmic delay. It appears to be a "cake and eat it" codec at present.

See here for their take on this very promising codec: http://wiki.hydrogenaudio.org/index.php?title=Opus

Now the problem that#s always plagued vorbis... will we see widespread hardware support for it? If it's already being deployed for Skype and WebRTC usage then I hope a few SoC manufacturers are going to support it.

Re:Already has good adoption

[Anonymous Coward]

Can we assume that you are unaware that the verb "chat" already meant "talk" long before the internet was even invented ?

So instead of blaming pavlon, I'll blame you being overly pedantic.

Re:Already has good adoption

[aardvarkjoe]

pavon did not "incorrectly describe" anything. You formed an incorrect definition of what "chat" means, which led you to misinterpret what he said. The fact that most "chat" via computers used to be text-only communication is an artifact of the technology that was available, nothing more.

(Note that he didn't even say "web chat", but that's beside the point.)

Re:Already has good adoption

[pavon]

It may not have been designed for audio files, but it's pretty damn good at them anyway - the hydrogen audio chaps rate is as equivalent to AAC and vorbis at the same bitrate, as well as having excellent quality at low bitrates along with low algorithmic delay. It appears to be a "cake and eat it" codec at present.

Not quite. It's true that for the majority of western music it performs just as well as AAC and Vorbis, however there are certain classes of audio that it does poorly with, in particular polyphonic music. This is an inherent limitation (steming from the pre/post comb filter), that cannot be overcome in future encoders.

For streaming audio, this isn't a big deal as it is somewhat of a corner case and people don't hold streaming audio to flawless standards. However, for a music library, you want an audio format to encode anything you throw at it to transparent level of quality, without thinking about the technical details or limitations.

Now the problem that#s always plagued vorbis... will we see widespread hardware support for it?

Opus uses less computational resources than Vorbis, to the point where doing it in hardware is almost pointless for a smartphone (especially for streaming where the radio will be active and using more power than the encoding/decoding), and ultra-low power dedicated MP3 players are becoming scarcer. So it's less of an issue that it was in Vorbis's day.

Re:Already has good adoption

[atamido]

Not quite. It's true that for the majority of western music it performs just as well as AAC and Vorbis, however there are certain classes of audio that it does poorly with, in particular polyphonic music. This is an inherent limitation (steming from the pre/post comb filter), that cannot be overcome in future encoders.

This is not actually "true" now. I remember reading a while back that this was one of the major goals of the 1.1 release, and it looks like they largely met that goal.

Look for the section labeled "Tonality Estimation".
http://xiph.org/~xiphmont/demo/opus/demo3.shtml

The short of it is that they have additional code to detect when there are many tones, and when "we consider the frame to be tonal and increase its bitrate." The samples they have of the page seem to show a 25-50% increase in bitrate when it does detect. So, you could easily use it to transparently encode your music library with the caveat that some samples will encode at a significantly higher bitrate. Really though, unless your library consists of a lot of harpsichord music, you're unlikely to see a real impact from this.

Opus flawed test results

[danknight48]

" Its first release beat everything else last year at 64kbit/s in a listening test held at HydrogenAudio."

No offence, but this test was solely based on "user preference".
- Wheres the Spectrum analysis of each codec?
- Which codec is more true to the original .wav, using the above data as comparison?
- Which codec cuts below 50hz?
- Which codec emphasizes certain frequencies (8-10khz, typical LAME mp3)?
- I'll automatically assume, your Opus codec (which is based on a voice codec) prioritizes bitrate quality between 500hz-4khz.

I still trust believe .ogg is the king of audio compression.
If you want to encourage more users to try Opus, you actually want to be a "serious" about your work on the codec, you'll need to do at least one "scientific" test.

Re:Opus flawed test results

[Anonymous Coward]

Looking at the waveform of a compressed piece of audio is really not a "scientific test".
As long as the ear can't hear the difference between the original file and the compressed one it doesn't matter a bit if they look very different.

  - Peder

Re:Opus flawed test results

[xiphmont8352]

>No offence, but this test was solely based on "user preference".
Offense taken.
That's how testing works in the audio industry. Mainly because it's the only thing that makes sense.

>- Wheres the Spectrum analysis of each codec?
A spectrum tells you almost nothing about how a codec sounds. Thus listening tests.

>- Which codec is more true to the original .wav, using the above data as comparison?
That's what a listening test answers. I know very few people who listen to music by unplugging their speakers, watching the spectrogram scroll by, and pretending to know what it sounds like.

>- Which codec cuts below 50hz?
Only telephony codecs do that; the highpass improves speech intelligibility according the studies done by Bell Labs.
Opus has a 3Hz highpass to eliminate spectral leakage in samples with a DC offset.

>- Which codec emphasizes certain frequencies (8-10khz, typical LAME mp3)?
Listening tests will tell you that. A spectrogram will not. Some amount of detailed critical band energy analysis can give you quantization bias figures, but that still won't tell you how it sounds. That's a test you run _after_ hearing a boost to determine where it's coming from.

>- I'll automatically assume
That's why I'm taking offense.

> your Opus codec (which is based on a voice codec) prioritizes bitrate quality between 500hz-4khz.
No. Opus is based on CELT, a music codec, and SILK, a speech codec. You didn't even read the demo page? Dude, tons of pretty pictures. You missed the party hat though.

Re:Opus flawed test results

[danknight48]

Offense taken.
That's how testing works in the audio industry. Mainly because it's the only thing that makes sense.

Fair comment and i see your reasoning, however, if you want to appeal to more "knowledgeable" users in your tests, you should supply the following info:
- What hardware playback device were you using for the tests?
- What speakers/headphone devices were tested (DT 990 pro's / Ipod standard)
- Were you tests consistent across the board of devices used?

A spectrum tells you almost nothing about how a codec sounds. Thus listening tests.

A spectrum analysis tells you everything regarding a codecs compression/quality ratio.
If your aiming for your codec to simply "sound good" but actually "be completely false in reproduction", your codec will be ignored by professionals.

That's what a listening test answers. I know very few people who listen to music by unplugging their speakers, watching the spectrogram scroll by, and pretending to know what it sounds like.

True, but the professionals who actually make that "audio", will use a spectrogram to determine the optimal playback quality for a set device (usually iPod + iPod headphones).
If the Opus codec fails in basic "true reproduction" of their audio, it will not be given the light of day.

Only telephony codecs do that; the highpass improves speech intelligibility according the studies done by Bell Labs.
Opus has a 3Hz highpass to eliminate spectral leakage in samples with a DC offset.

You could increase that to 20hz for improved quality/compression ratio.
20hz is generally regarded as the cut off point for all audio production, mainly due to the fact its a pure vibration, and, causes unnecessary compression issues in the mix. 40hz for music production.
Low pass is 13khz for modern music production.

No. Opus is based on CELT, a music codec, and SILK, a speech codec. You didn't even read the demo page? Dude, tons of pretty pictures. You missed the party hat though.

Pretty pictures might work on most people, but a page full of "hear say" does nothing to help Opus.
My feedback was designed to get Opus re-thinking its target audience. Wheter they take some of that on board, or not, is no loss to me. .ogg still is my prefered choice. Changing that is down to the quality/information provided in your tests.

Re:Opus flawed test results

[Anonymous Coward]

Sorry, this is a bit snarky, but..
If you don't want to be "ignored by professionals", you shouldn't claim to be encoding audio with a media container format.
The audio codec is Vorbis. Ogg is a container format that is often used with Vorbis.

It's not like they have to convince anyone, except possibly some developers of audio players/streamers, but for what it's worth, this AC thinks Opus is a really neat codec, and I trust the Opus developers to be exactly as scientific and professional in their approach as the Vorbis developers. :)
Definitly give it a chance if you're ever in the position of choosing an audio codec on technical merits.

Re:Opus flawed test results

[xiphmont8352]

>- What hardware playback device were you using for the tests?
>- What speakers/headphone devices were tested (DT 990 pro's / Ipod standard)
In this style of test, that's mostly irrelevant. One wants testing on a wide range of equipment, and no, the list of equipment is not documented. I can say though it encompasses the range from earbuds to electrostats.

>- Were you tests consistent across the board of devices used?
Oh right. You didn't read anything about it. You're just commenting.

>A spectrum analysis tells you everything regarding a codecs compression/quality ratio.
No, no it does not. Even if you want to be pedantic about it, the spectrum loses all phase and time alignment information. And even if it didn't (and we're _not_ being pedantic) it does not present it in a form your ears can parse or you can otherwise interpret in an appropriate way anyway.
You're saying the equivalent of 'we don't need to actually test software, we have the source code! That tells us everything about how it behaves, so actual testing is redundant'.

>If your aiming for your codec to simply "sound good" but actually "be completely false in reproduction", your codec will be ignored by professionals.
At 64kbps and below, all codecs are synthesizing most of the spectrum and have been for the past 10-20 years. You really have no idea what you're talking about.

>You could increase that to 20hz for improved quality/compression ratio.
>20hz is generally regarded as the cut off point for all audio production,
No, 50Hz is (to control power draw and excursion) unless it's an audiophile production, then it's Pretty pictures might work on most people, but a page full of "hear say" does nothing to help Opus.
Hi, I'm one of the authors of the codec. I wrote detailed pages explaining how aspects of the codec work, which you could not be bothered to read before lecturing us on what's supposedly wrong with Opus. Which one of us is indulging in 'hearsay' again?

Re:Opus flawed test results

[xiphmont8352]

Interesting, the comment system removed several lines of text right smack in the middle of the comment.

Re:Opus flawed test results

[xiphmont8352]

The text that got mangled:

>You could increase that to 20hz for improved quality/compression ratio.
>20hz is generally regarded as the cut off point for all audio production,
No, 50Hz is usually the default cutoff (to control power draw and excursion) unless it's an audiophile or 'classy' production, then it's less than 1Hz often as low as .1Hz, at least in the codec. The goal is only to remove DC.

>Pretty pictures might work on most people, but a page full of "hear say" does nothing to help Opus.
Hi, I'm one of the authors of the codec. I wrote detailed pages explaining how aspects of the codec work, which you could not be bothered to read before lecturing us on what's supposedly wrong with Opus. Which one of us is indulging in 'hearsay' again?

Re:Opus flawed test results

[atamido]

>Pretty pictures might work on most people, but a page full of "hear say" does nothing to help Opus.
Hi, I'm one of the authors of the codec. I wrote detailed pages explaining how aspects of the codec work, which you could not be bothered to read before lecturing us on what's supposedly wrong with Opus. Which one of us is indulging in 'hearsay' again?

Oh, snap! That was awesome.

Re:Opus flawed test results

[Anonymous Coward]

Dan, You have no idea at all what You're talking about.