It's Opus, it rocks and now it's an audio codec standard!

In a great victory for open standards, the Internet Engineering Task Force (IETF) has just standardized Opus as RFC 6716.

Opus is the first state of the art, free audio codec to be standardized. We think this will help us achieve wider adoption than prior royalty-free codecs like Speex and Vorbis. This spells the beginning of the end for proprietary formats, and we are now working on doing the same thing for video.

There was both skepticism and outright opposition to this work when it was first proposed in the IETF over 3 years ago. However, the results have shown that we can create a better codec through collaboration, rather than competition between patented technologies. Open standards benefit both open source organizations and proprietary companies, and we have been successful working together to create one. Opus is the result of a collaboration between many organizations, including the IETF, Mozilla, Microsoft (through Skype), Xiph.Org, Octasic, Broadcom, and Google.

A highly flexible codec

Unlike previous audio codecs, which have typically focused on a narrow set of applications (either voice or music, in a narrow range of bitrates, for either real-time or storage applications), Opus is highly flexible. It can adaptively switch among:

Bitrates from 6 kb/s to 512 kb/s
Voice and music
Mono and stereo
Narrowband (8 kHz) to Fullband (48 kHz)
Frame sizes from 2.5 ms to 60 ms

Most importantly, it can adapt seamlessly within these operating points. Doing all of this with proprietary codecs would require at least six different codecs. Opus replaces all of them, with better quality.

The specification is available in RFC 6716, which includes the reference implementation. Up-to-date software releases are also available.

Some audio standards define a normative encoder, which cannot be improved after it is standardized. Others allow for flexibility in the encoder, but release an intentionally hobbled reference implementation to force you to license their proprietary encoders. For Opus, we chose to allow flexibility for future encoders, but we also made the best one we knew how and released that as the reference implementation, so everyone could use it. We will continue to improve it, and keep releasing those improvements as open source.

Use cases

Opus is primarily designed for use in interactive applications on the Internet, including voice over IP (VoIP), teleconferencing, in-game chatting, and even live, distributed music performances. The IETF recently decided with “strong consensus” to adopt Opus as a mandatory-to-implement (MTI) codec for WebRTC, an upcoming standard for real-time communication on the web. Despite the focus on low latency, Opus also excels at streaming and storage applications, beating existing high-delay codecs like Vorbis and HE-AAC. It’s great for internet radio, adaptive streaming, game sound effects, and much more.

Although Opus is just out, it is already supported in many applications, such as Firefox, GStreamer, FFMpeg, foobar2000, K-Lite Codec Pack, and lavfilters, with upcoming support in VLC, rockbox and Mumble.

For more information, visit the Opus website.

Jean-Marc Valin has a B.S., M.S., and PhD in Electrical Engineering from the University of Sherbrooke. He is the primary author of the Speex codec and one of the main authors of the Opus codec. His expertise includes speech and audio coding, speech recognition, echo cancellation, and other audio-related topics. He is currently employed by Mozilla to work on next-generation multimedia codecs.

https://jmvalin.ca/

89 comments

Ashley

Interesting! Any idea if this will become mandatory to implement for HTML5 audio as well? That’s another area in sore need of a single format that works everywhere.

September 11th, 2012 at 11:56
1. Timothy B. Terriberry
  
  We certainly hope so, and we’re working to get all the other browsers to support it.
  
  September 11th, 2012 at 12:02
2. Shmerl
  
  I second this question. Can we expect Opus to become mandatory for the audio tag support?
  
  September 11th, 2012 at 12:11
  1. Shmerl
    
    Sorry, missed the reply :) Thanks for answering.
    
    September 11th, 2012 at 12:12
3. Ryan B.
  
  It still seems HTML5 is on the cusp of mainstream yet somehow always manages to slip away. One day we’ll be all caught up…
  
  September 15th, 2012 at 22:44
Anonymous

Any plans to create a version of WebM that replaces the Vorbis codec with Opus?

September 11th, 2012 at 12:12
1. Timothy B. Terriberry
  
  This is something we’re still discussing with the rest of the WebM community. One of the advantages of WebM is that you don’t have to implement a plethora of codecs in order to support it. The bitrate savings of Opus are smaller when stacked against the bitrate of most video, but they might still be worth giving up that simplicity.
  
  Some day we’ll want to use a next-generation video codec, though. Pairing that with Opus will certainly make sense.
  
  September 11th, 2012 at 12:21
Bruce Perens

Hi Jean-Marc and Tim,

Congratulations on getting this through standards track.

It is unfortunate, though, that companies have already asserted their patents under RAND terms with “Possible Royalty Fee” that aren’t compatible with Open Source implementations. These are:

Qualcom: https://datatracker.ietf.org/ipr/1520/
Huawei: https://datatracker.ietf.org/ipr/1712/

Are you making any effort to keep your codecs free of the named patents?

September 11th, 2012 at 12:30
1. Monty
  
  Hi Bruce,
  
  QC and Huawei have both made IPR declarations against Opus. We reviewed their claims; they are without merit. But the declaration process does not require companies to defend claims. They can just make them and walk away (and have a history of doing exactly that in a wide swath of working groups).
  
  It’s an effortless tactic to make free licensing money; sadly it means nothing other than ‘even settlements are expensive, cough up the two dollars’. It’s an outright abuse of the system, and we made a formal complaint on the subject. QC’s response boiled down to “We don’t care, it’s legal.”
  
  The good news is that their declarations had to include patent numbers, and though it meant burning legal time we were able to review the patents in detail. They don’t apply. We would not ship code (or a standard) that was not RF, full stop, no fine print.
  
  September 11th, 2012 at 12:56
  1. Bruce Perens
    
    Hi Monty,
    
    Well, I’m angry. Because whether their patents apply or not, their efforts create a climate in which _there is no Free Software_. The presence of these IPR assertions can be used to support a claim of treble damages for knowing infringement, rather than simple damages, if they convince a jury that their claims are valid. And having just watched the Apple v. Samsung case, we should know that you can convince a jury of very wrong things, regarding patent cases.
    
    And we, as a community, cooperate with standards organizations that happily take a RAND stance, and promote that RAND is acceptable for Open Standards (see open-stand.org) and we build much of the software in the products of the companies that, in turn, seek to encumber us.
    
    September 11th, 2012 at 13:43
2. Timothy B. Terriberry
  
  Hi Bruce,
  
  Please see the statement on Opus’s royalty-free status from our previous article: https://hacks.mozilla.org/2012/08/opus-support-for-webrtc/
  I believe everything we said there was accurate and still applies.
  
  We’d love to say a lot more about the IPR disclosures you referenced, but are still waiting for approval from our legal department. I’m sure you understand the difficulties with being allowed to say in public as much as we already have.
  
  September 11th, 2012 at 13:06
  1. Bruce Perens
    
    Hi Tim,
    
    I wrote to the appropriate people at Qualcom about this, asking for them to help to get the company on board. I don’t know anyone at Huawei.
    
    I understand that you won’t be allowed to say anything without approval of counsel.
    
    If companies that obviously make use of tons of Open Source software in their products take the stance that they will also attempt to encumber our work, we really should put some social pressure upon them. This is regardless of whether _we_ think their patents are actually applicable or not – they are making the claim and should bear the cost of that. Of course, we should allow some time for them to change their minds, or for private contacts to do their work. But there should be a date beyond which we _do_ something, if these declarations are unchanged.
    
    I am happy to speak confidentially with any party, +1 510-4PERENS if you’d like to call.
    
    September 11th, 2012 at 13:17
spellchecker

Great news! Please change Foobar2000 with foobar2000.

Thanks.

September 11th, 2012 at 12:37
1. Robert Nyman
  
  Thanks! We fixed the spelling!
  Also: I know nothing bad is meant with the name you chose here, but it could be offensive to people – therefore, I’ve removed the first part.
  
  September 11th, 2012 at 13:36
roger

How does one use this within ffmpeg?

September 11th, 2012 at 12:51
1. Timothy B. Terriberry
  
  Running “ffmpeg -codecs” with a recent version of ffmpeg says:
  D.A… opus Opus (decoders: libopus )
  
  So decoding should “just work” if you build with libopus support enabled (–enable-libopus at configure time). There are a few minor issues (e.g., sample accurate end-trimming, required for gapless playback, is not implemented), but I’m sure those will get ironed out.
  
  September 11th, 2012 at 13:20
Audy

Pretty cool accomplishment. Any plans to follow this up with a similar standards effort for a lossless codec? Perhaps FLAC?

September 11th, 2012 at 12:55
1. Timothy B. Terriberry
  
  The IETF, at least, seemed uninterested in standardizing a pre-existing format without being allowed to make changes and improvements, and we had to go to some effort to convince them this was not what we were trying to do with Opus. Making a new, incompatible version of a format as mature and well-deployed as FLAC just to get the blessings of an SDO probably isn’t worthwhile. If doing this somewhere else made sense, though, I can’t imagine Xiph would be opposed to the idea.
  
  September 11th, 2012 at 13:27
2. starwed
  
  Isn’t FLAC *already* open and royalty-free?
  
  September 11th, 2012 at 13:29
  1. Dusk
    
    FLAC is a lossless codec — it typically generates output at a bitrate *orders of magnitude* higher than lossless codecs such as OPUS, and there’s no way to “dial it down”.
    
    September 11th, 2012 at 13:40
    1. natermer
      
      You want to archive audio with 100% quality using Flac.
      
      Opus is for were you are willing to give up some amount of audio quality for the ability to massively increase compression ratio. Using low bit rate Opus may yield a 3MB file for a song, were as FLAC may end up being 150MB for the same audio.
      
      What I do for audio is to store it using flac, but encode it on the fly using other codecs for streaming for transfering to devices. That way I always get the best audio quality possible to go along with the best compression possible.
      
      September 11th, 2012 at 14:30
    2. Z4ppy
      
      “[…] higher than *lossy* codecs such as OPUS […]”
      ;-)
      
      September 11th, 2012 at 14:53
  2. Ryan
    
    Yes, but it’s not even remotely similar to Opus, nor is it usable in most of the contexts targetted by Opus. Read more, comment less.
    
    September 15th, 2012 at 19:11
Reino

BASS audio library (http://www.un4seen.com/bass.html), is also one of the applications supporting OPUS.

September 11th, 2012 at 13:27
Audy

I agree that if any SDO wanted changes that would make FLAC backwards-incompatible then seeking such blessings would not be worth it. But FLAC could benefit from changes anyway like supporting file sizes greater than 2 GB and perhaps changes to make it easier for music production-side efforts to use. So I hope xiph pursues something like this for FLAC if SDO blessing can be achieved in a backwards-compatible way. Since both Microsoft and Apple have lossless formats that compete with FLAC, I don’t think ubiquitous FLAC adoption is ensured yet or the long term, and I think SDO support can help ensure FLAC’s success. Perhaps not quite an SDO, getting the DLNA folks to add FLAC gapless to their standards would help too. But not to distract from today’s accomplishment – congrats on Opus!

September 11th, 2012 at 14:39
1. Jessica
  
  I don’t believe that the FLAC format itself is limited to 2GB, indeed, the offsets used the seektables seem to be a full 64 bits. From what I can work out, the 2GB limit is only a problem with the reference implementation on Windows.
  
  September 11th, 2012 at 17:05
  1. Ryan
    
    That’s Winblow$.
    
    September 15th, 2012 at 19:13
gonewest

Has someone got the “quality v. bitrate” graph for bitrates above 128 kbps?

Curious if Vorbis, Opus, mp3 and AAC are asymptotically converging or if the plots cross and diverge above that point.

September 11th, 2012 at 16:13
1. Timothy B. Terriberry
  
  Unfortunately, it’s hard to get statistically significant listening test results at rates that high, because (except possibly for MP3), these formats are already basically transparent at 128 kbps.
  
  September 11th, 2012 at 16:52
  1. Gonewest
    
    I see. Didn’t realize these were based on qualitative listening tests.
    
    Thanks-
    
    September 11th, 2012 at 19:12
dimitri flores

And who is going to deal with 5.1, 7.1, x.1 sound?

September 11th, 2012 at 17:19
1. Timothy B. Terriberry
  
  I’m not sure what you’re trying to ask. The .opus format supports multichannel audio. Firefox doesn’t support multichannel output (https://bugzilla.mozilla.org/show_bug.cgi?id=521615, currently blocked on https://bugzilla.mozilla.org/show_bug.cgi?id=782507), but as a temporary measure we added support for playing multichannel Opus files by downmixing them to stereo in https://bugzilla.mozilla.org/show_bug.cgi?id=748144 (currently available on the Aurora channel, and scheduled for release in November).
  
  September 11th, 2012 at 17:28
Chun-Kwong Wong

We’re one step closer to the truly open web. Congratulations, people! And thank you for all the hard works. Now we just need the same thing to happen on the video counterpart.

September 11th, 2012 at 17:33
1. Ryan
  
  But unfortunately some nasty East Asians are making spurious patent assertions against Opus.
  
  Qualcom: https://datatracker.ietf.org/ipr/1520/
  Huawei: https://datatracker.ietf.org/ipr/1712/
  
  (quoted from above)
  
  September 15th, 2012 at 19:15
Jon

Skype may have helped develop Opus, and are now part of Microsoft, but Microsoft have made it pretty clear they have no intention of allowing royalty-free codecs like Opus to become attached to standards like Web Audio and RTC. After all, that would open the door to actual interoperability and competition. Much better to give lip service to both by working in the standards groups, but then only support a couple of proprietary, patent-encumbered codecs, citing vague, unsubstantiated IP concerns about the royalty-free alternatives that everyone else supports. If we ever see IE shipping with Opus support, I’d be very surprised.

September 11th, 2012 at 17:37
1. Timothy B. Terriberry
  
  I know the default assumption is that Microsoft will hold back progress on royalty-free codecs, but the people involved with Microsoft’s WebRTC standardization efforts came out in direct support of making Opus mandatory to implement on the mailing list:
  
  http://www.ietf.org/mail-archive/web/rtcweb/current/msg05075.html
  http://www.ietf.org/mail-archive/web/rtcweb/current/msg05080.html
  http://www.ietf.org/mail-archive/web/rtcweb/current/msg05081.html
  
  September 11th, 2012 at 17:46
ferongr

Too bad Google is dragging its feet in implementing support for it in Chrom*, while it’s obvious they don’t lack the manpower to implement whatever their NIH-syndrome replacements like iSAC and webP. crbug.com/104241 is wontfixed and according to a comment Opus support is “not a priority”.

September 11th, 2012 at 18:30
1. Jean-Marc Valin
  
  Google’s been very supportive during the development (e.g. in testing) and have publicly stated that they preferred Opus over iSAC. There’s no NIH involved here. There’s just lost of stuff to do in Webrtc.
  
  September 11th, 2012 at 20:48
user

No Linux downloads. :-(

September 11th, 2012 at 18:30
1. Shmerl
  
  Many Distros already include it (on Debian for example search for opus-tools and libopus). Of course you can also compile the sources.
  
  September 11th, 2012 at 18:43
2. Timothy B. Terriberry
  
  There is source code :). Rather than provide binaries for all the flavors of Linux, it’s a better use of our time to just work with their maintainers to get libopus and opus-tools packaged like any other piece of Linux software. Even slightly older versions like the one in wheezy (http://packages.debian.org/wheezy/libopus-dev) should work fine.
  
  September 11th, 2012 at 18:47
David Piepgrass

This sounds too good to be true. How was it possible to make a new codec that simultaneously lowers latency and increases quality compared to all popular competitors at a given bitrate–all without stepping on any patents? Besides that, how can it work at such a broad range of bitrates? I look forward to seeing a explanation for this (y’know, something not overly esoteric, for those of us with only a basic grasp of huffman codes and FFTs). Does it use many different techniques, like 7-zip, or is it as simple and unified as possible?

September 11th, 2012 at 18:37
1. Robert O’Callahan
  
  It’s possible because the Opus developers are awesome :-). But yeah, it would be cool to have someone describe Opus’ technical advances in an accessible way.
  
  September 11th, 2012 at 19:24
  1. Timothy B. Terriberry
    
    We’ve got Jean-Marc’s talk from LCA 2012 up at http://www.opus-codec.org/presentations/
    Hopefully we should have some more recent talks I’ve given on Opus available on that page soon.
    
    See also my older talk on CELT from LCA 2009 at http://www.celt-codec.org/presentations/
    Though many of the details from that presentation are no longer accurate, the general ideas haven’t changed.
    
    September 11th, 2012 at 19:39
2. Jean-Marc Valin
  
  My non-technical answer to “how is this possible” is that we actually had a bunch of developers interested in working *together* to produce the best codec possible. This was not about shoving as many patents as possible into a standard, nor was it about following highly bureaucratic requirements about what should and shouldn’t be done. We had a bunch of requirements, but we also did our best to exceed them wherever we could without having to fight. Once you remove that idea that it’s all about putting your patents in, it’s amazing what you can achieve. That’s my only explanation anyway because there are very bright folks working on MPEG/ITU codecs and it’s a shame to see the output of that (well, it’s good for Opus).
  
  September 11th, 2012 at 20:44
3. David Piepgrass
  
  Well, I had a look at the RFC. The technical details are largely impenetrable… for example the introduction to Range Coding should really say something about what fl[k], fh[k], and ft represent (and what’s [k], an array subscript?), and they really should not have waited until section 4.1.3.3 to introduce the concept of a Probability Density Function, since it appears to be a fundamental idea…
  
  …Anyway, Opus is basically two codecs in one: a linear prediction (LP) codec for speech (based on a standalone codec called ‘SILK’) and a MDCT-based codec for music (based on a standalone codec called ‘CELT’). An Opus encoder can instantly and seamlessly switch between the two codecs at any time according to the bitrate and the dominant character of the input, and there is a hybrid mode where SILK is used for low frequencies and CELT for high frequencies.
  
  CELT is built on the same psychoacoustic principles as other modern codecs (e.g. Vorbis), but adds innovations to permit low latency without hurting overall audio quality. SILK is designed for low bandwidth and low-latency speech (though the principles behind it remain totally opaque to me), while CELT is better for high bandwidth audio (music or speech or anything else) but can still operate at very low bitrates when the sound is not speech or speech-like and therefore unsuitable for SILK.
  
  The operating modes of Opus are designed so that the two codecs “fit together” nicely, and it can switch between the two on 10ms boundaries (sampling range can similarly change among 8/12/16/24/48 kHz, ditto for mono/stereo). Opus also offers other real-time and VOIP features, such as CBR and forward error correction and other tricks to compensate for packet loss.
  
  Some final niceties of Opus: the encoder and decoder can operate at independent sampling rates (or one can be mono and the other stereo), and the (continuously variable) bitrate is independent of the operating mode (e.g. want stereo at 48 kHz at 8 kbps? It’s probably a bad idea, but it’s not outright prohibited). So basically Opus covers virtually all scenarios. The codec to end all codecs, indeed.
  
  (correct me if I’m wrong about any of this, dear experts).
  
  Now can I just get a codec that achieves very low bitrates by observing long-term audio patterns and making backward references to similar audio many seconds in the past? kthxbye :)
  
  September 12th, 2012 at 14:23
  1. Jean-Marc Valin
    
    Now can I just get a codec that achieves very low bitrates by observing long-term audio patterns and making backward references to similar audio many seconds in the past?
    
    This is still a research topic and last I heard, we weren’t anywhere near a practical codec using that. The topic you might want to search for is something like sparse over-complete basis functions.
    
    September 15th, 2012 at 20:21
4. Ryan
  
  Go take a look at the first image on the Wikipedia article. Most modern codecs support a range of bitrates. The majority are either targeted at archival/downloaded audio or real-time/streaming/VoiP.
  
  Opus simply combines the best of 2 codecs, in a way that allows it to support the whole range of useful bitrates for lossy compressed audio. It does this by being somewhat complex but the advantage of being complex is that it unifies the whole thing into a single standard, suitable for most use cases, under a single name.
  
  It’s not magic, it’s just building on existing knowledge and research, thanks to people like xiph.org (and no thanks to trolls like Qualcomm and Huawei)
  
  September 15th, 2012 at 19:35
Dave Haynie

Is this 2012 or 1992? A brand new audio CODEC specification that’s built to 48kHz limits? With cheap pocket field recorders supporting 24-bit at 96kHz, and higher quality audio standards like Blu-ray scaling up to 192kHz, this seems terribly retro. Even AAC supports sample rates to 96kHz.

Kudos on the low-latency and scaling from voice to “CD-quality”. But not quite for everything.

September 12th, 2012 at 05:00
1. Monty
  
  > 48kHz sampling is itself an outdated anachronism. The reason Opus does not support > 48kHz sampling is because it’s not 1982. 96kHz was already unnecessary in 1992.
  
  The problem is that consumers (and many professional users) don’t realize high sampling rates were about getting around technological limitations of the earliest DACs. Bigger is not better in this case.
  
  Have a look at:
  http://people.xiph.org/~xiphmont/demo/neil-young.html
  
  September 12th, 2012 at 05:11
2. Leon
  
  Don’t be fooled by the audiofools… :)
  Frequencies above 20Khz(48Khz sampling rate) are inaudible by humans. I tested myself and I can only barely make out a 19Khz test tone on monitoring headphones and I’m 27.
  So wasting bits on higher frequencies on a limited bitrate will only DEGRADE the audio quality, because those bits could have been allocated on the frequencies we can actually hear.
  48Khz/16bit is all we will ever need for playing back audio.
  
  September 13th, 2012 at 07:07
  1. David Piepgrass
    
    21 kHz may be inaudible by humans, but why shouldn’t I be able to record and play back a dog whistle? Or heck, how about audio-based remote controls?
    
    I heard Opus *always* cuts off everything above 20kHz. But since anything very far above 128kbps is probably indistinguishable from FLAC (for a human), it seems like very high bitrate streams (400kbps?!) should really encode all the way up to 24kHz (the fundamental limit for 48kHz input).
    
    September 13th, 2012 at 08:53
    1. Bob H
      
      My remembered sampling theory says that not filtering under half the sample rate introduces some distortion, I don’t know about the choice of the number 20, but I think there should be a filter below 24kHz and a formula should be applied for sample rates vs low pass filter.
      
      September 13th, 2012 at 09:18
      1. David Piepgrass
        
        You remember incorrectly. Not filtering *over* half the sample rate could introduce some distortion; for example I think a 32kHz signal sampled at 48kHz would come out as a 16kHz tone. A 22kHz tone is not distorted when played at 48kHz, assuming good equipment. Opus cuts off at 20kHz only because humans can’t hear above that.
        
        September 13th, 2012 at 10:57
    2. Ryan
      
      As in all things in software, every extra feature comes at the cost of extra complexity, and complexity makes things at best harder to optimize and at worst impossible to optimize.
      
      Opus is optimized to the real world (where it’s pretty rare to record dog whistles with lossy codecs). I’m sure you can deal with using FLAC if you want a few seconds of dog whistle recording. Or were you planning to do real-time chat with your dog? Or maybe you were going to record a folk music album targeted at the niche dog market and will get angry dog customers because you’ve forced them to choose between large file sizes or inaudible doggy whistles?
      
      September 15th, 2012 at 19:55
3. Bernd
  
  The fundamental idea behind every lossy audio format that does exploit psychoacoustics is to reduce bitrate by saving only audible sound features and “leaving out” things we can’t hear. Practically every lossy codec in use is designed for humans. Saving frequencies above 20 kHz goes against that fundamental idea. To date there is no scientific proof for the existence of humans that hear beyond 22 kHz. Use FLAC or develop a special dog codec to serve your dog.
  
  September 14th, 2012 at 07:43
Anthony “Airon” Oetzmann

The game DOTA 2 by Valve Software uses CELT, a subset of Opus for it’s voice communication system.

The game is in beta, but already has two international tournaments and over a million players.

September 12th, 2012 at 05:05
Anthony “Airon” Oetzmann

A note on the 48kHz limitation from a sound engineers perspective.

96kHz lossy media is not necessary.

Nobody is ever going to record to lossy 96kHz media and no professional sound person will ever want to use it for those applications that 96kHz or even 192 kHz sampling is used for, which is usually effects field recording and orchestral recording.

Recording in 96kHz to losslessly compressed formats is already a reality. My Sound Devices 722 can record to FLAC for example. And it can record to MP3 files as well, but nobody will do that with field recordings other than voice perhaps, and certainly not waste the bandwidth on 96kHz material if that was even possible.

Nobody uses lossy compression at anything higher than 48Khz. There’s just no application for it.

September 12th, 2012 at 05:13
Bob H

As with all new codecs I see: has anyone checked for the potential of hardware support? Will it optimise well for audio DSPs? Or is it just an x86 niche?

September 12th, 2012 at 05:23
1. Timothy B. Terriberry
  
  Many of its operations were written specifically in terms of things that are fast on DSPs (such as signed 16×16 fixed-point multiplies), and a substantial number of the fixed-point macros can be replaced by single ARM instructions. We aggressively reduced memory usage, of both scratch buffers and ROM, to enable it to run on extremely limited devices. The most expensive parts are things like the MDCT, and we specifically isolated that so it would be easy to swap out with a custom implementation for particular DSPs (which I know at least one person took advantage of when porting to the TI C55x DSPs). We care about a lot more than x86.
  
  September 12th, 2012 at 05:31
  1. Bob H
    
    Excellent!
    
    September 12th, 2012 at 06:39
Derrick Coetzee

I’m really excited about this development – the idea of a codec that can smoothly scale quality across bitrates opens up all sorts of novel applications (e.g. compressing a given set of audio files to just fit in a fixed amount of storage, or audio conferencing that adjusts quality in real time based on available bandwidth and the number of participants).

One question I have about measurement: many of the narrowband/wideband codecs are specifically optimized for speech, and so do substantially worse on quality with things like music, animal sounds, noises, etc. Does Opus exhibit lower quality on non-voice audio in this range too? Or does it compare even more favorably to speech codecs on non-speech audio?

September 12th, 2012 at 06:03
1. Jean-Marc Valin
  
  When you get to low bit-rate (<32 kb/s mono, <48 kb/s stereo), music quality starts to suffer and that's mostly unavoidable. That being said, I think Opus still handles low bitrate music better than other speech codecs. But at that point it doesn't matter all that much anyway because (at least IMO) the quality is just not what someone would consider acceptable (so "bad" vs "really bad" doesn't matter).
  
  September 12th, 2012 at 07:17
  1. Ryan
    
    Cellular comms is still bandwidth constrained and many service providers pay/charge rates directly for bandwidth consumption. Many people and even some entire countries often don’t have the needed bandwidth (per person) to reliably stream at 48kb/s.
    
    Case in point, when I make a call to SE Asia with Skype, the dynamic bitrate negotiation makes it smooth and usable, whereas Google Voice is almost useless.
    
    Performance characteristics change the entire game of how a technology can (or can’t) be used. Tinny, low-quality audio is far more “acceptable” than an unusable product. An internet cafe where 20 people can talk at the same time is far more “acceptable” than one where 2-3 people consume all the bandwidth.
    
    Your statement can be paraphrased as:
    
    “I am a sheltered western consumer with a gigabit broadband connection and an 8 core CPU – f*ck all that noise about embedded CPUs and third-world internet.”
    
    September 15th, 2012 at 20:19
    1. Jean-Marc Valin
      
      No, what I mean is that if all I have is 20 kb/s (which does happen on crowded networks in any western country), then I’d rather not listen to music than hear music that’s so badly mutilated that it sounds like noise. Unlike speech (which can be encoded at much lower bitrate anyway), music is rarely a necessity.
      
      September 15th, 2012 at 20:44
      1. dumb
        
        Any chance that a de-warbling post-filter for Opus decoder can be developed? I do feel that even 20 kbit/s will be acceptable with it.
        
        September 16th, 2012 at 01:27
      2. Jean-Marc Valin
        
        Any chance you can tell us how to implement a de-warbling post-filter? Seems like it should be able to achieve good quality at 1 kbit/s too.
        
        September 16th, 2012 at 10:22
      3. dumb
        
        Someone forgot to switch off commenting to this post. :) So I’ll reply.
        
        >Any chance you can tell us how to implement a de-warbling post-filter?
        Nope – that’s why I asked.
        >Seems like it should be able to achieve good quality at 1 kbit/s too.
        Er, wait, did you just use the time machine to change the Opus spec? Anyway, at that bitrate such a filter would probably turn signal into white noise. Still more pleasant than warbling, though!
        
        September 16th, 2012 at 11:32
Jonadab

> Using low bit rate Opus may yield a 3MB file
> for a song, were as FLAC may end up being
> 150MB for the same audio.

Yeah, let’s clarify that:

Using an extremely low bit rate that nobody would really ever consider using in the real world, Opus may yield a 3MB file for a song, but it will sound like a bunch of pots and pans going round and round in the dryer. Using a somewhat more reasonable bitrate, it may yield a 40MB file, which you can probably just about stand to listen to, if you’re not picky. If you’re listening to inherently noisy music (e.g., metal), you probably wouldn’t even be able to hear the compression artifacts. If the claims here are true, it would sound a bit better than an equivalent 40MB MP3 or Vorbis file.

FLAC may end up being 150MB for the same thirty-minute symphony (I’m not entirely comfortable calling anything that large a “song”), but it will sound *exactly* like the CD you ripped it from (assuming your player has enough processor cycles to decode it in real time, which on a modern system should not be a problem unless you’re trying to compile half the CPAN in the background while also raytracing a movie-poster-sized image with lots of reflective surfaces and atmospheric effects).

Opus is not a suitable replacement for FLAC. It *may* be a suitable replacement for MP3 and Vorbis, but frankly I don’t use either of those codecs, because lossy audio is for the birds. Storage space costs somewhere in the general vicinity of ten cents a gigabyte. In the nineties, I could have imagined possibly having some use for lossy compression. Today, I cannot.

To me, any new lossy audio codec is per se a solution in search of a problem. Even Flash-based portable music players these days can store more lossless content than their battery life will let you actually play before you have to plug it in again anyway to recharge. What, then, is the use case for a lossy format?

September 12th, 2012 at 13:39
1. Derrick Coetzee
  
  Besides the use cases involving transmission of audio (like streaming, teleconferencing, etc), I think lossy audio encoding still has a place for music playing – a lot of people like to keep their entire collection on their device so that they can select any song they like on demand. With a lossy format that collection can be 5 times bigger with little to no audible quality loss. Admittedly you can fit a sizable FLAC collection on a 64 GB SD card (and a cheap slow one suffices due to buffering), but the bigger the better.
  
  September 12th, 2012 at 14:26
2. David Piepgrass
  
  A 150 MB FLAC song is probably about 30 minutes long and a little over 300 MB uncompressed, assuming 48KHz stereo. So yeah, to achieve 3MB you’d need a bitrate of 100KB/minute or 13kbps, which can’t realistically be 48kbps or stereo to begin with. But if you go with 130kpbs instead (30 MB, 10:1 compression), most people wouldn’t be able to hear any difference between that and the 150 MB FLAC. And if the listening tests are any indication, with typical lousy hardware I expect many people wouldn’t know the difference between 65kbps (15 MB, 20:1) and FLAC.
  
  September 12th, 2012 at 14:46
3. Ryan
  
  Real-time communication, which is at least *usable* when bandwidth-constrained and good quality when not.
  
  Keeping mobile data charges down (both for single consumers and in aggregate for service providers). Some people don’t have the luxury of fast internet, some people rely on “mobile” internet even at home. Some providers have thin margins or limited bandwidth in certain areas.
  
  Archival storage of phone-calls, interviews, speech analysis corpora etc., which may range into Terabytes or more (possible many times over if mirrored and backed up). The difference between 1TB and 10,000TB is the difference between something you can pick up and carry and something that has a permanent address.
  
  Because cost matters, maintenance matters, bandwidth matters and applications that require mirroring and redundancy magnifies all of those.
  
  So you have a music collection and enjoy high quality audio. That’s absolutely fantastic for you. But are you really *that* sheltered and short-sighted that you can’t see the huge number of other use cases where quality is a secondary concern?
  
  September 15th, 2012 at 20:46
roger

Since it is billed as a “speex replacement” http://code.google.com/p/chromium/issues/detail?id=104241 does that mean…that it will have AGC/AEC/denoise-built-in too? :) Just wondering…

September 12th, 2012 at 14:40
1. Timothy B. Terriberry
  
  The AGC/AEC/jitter buffer, etc., were part of libspeexdsp, and not really tied to the Speex codec. They can still be used with Opus. The libopus encoder does include a high-pass filter (enabled when targeting VoiP applications) that helps remove breath noise, because it made sense to include it at that level, but we’re expecting most people will provide their own implementations of the rest of those tools (even if they just use the ones from libspeexdsp). For WebRTC, we’re using the code from http://www.webrtc.org/
  
  September 13th, 2012 at 04:40
Bill

What to say?
THANKS, thanks to everybody who made it possible.
It’s a great news.

September 13th, 2012 at 12:49
Teg

Someone mentioned that Opus was in the Debian repositories, but it is also going to be in the upcoming Ubuntu 12.10 (Quantal) release even if it is an older version:

http://packages.ubuntu.com/search?keywords=opus&searchon=names&suite=quantal&section=all

September 13th, 2012 at 17:32
1. Jean-Marc Valin
  
  From what I see, they’re shipping 0.9.14, which is exactly the same code as the RFC.
  
  September 13th, 2012 at 21:32
Omega X

Typo in the bitrates:

Bit-rates from 6 kb/s to 510 kb/s

Not 512.

September 14th, 2012 at 16:02
1. Gonewest
  
  Why support 510kbps if, as was asserted above, compression artifacts are “transparent” at 128kb/s?
  
  September 14th, 2012 at 17:15
  1. dumb
    
    Headroom, probably. It wasn’t known at that stage that 128kbps would be transparent on most samples.
    
    September 14th, 2012 at 22:52
  2. Jean-Marc Valin
    
    Well, the first thing to keep in mind is that to achieve “near transparency” at an *average* of 128 kb/s, Opus needs to be able to encode some short segments (e.g. transients) at up to 256 kb/s. From there to 512 kb/s, it’s just a bit of headroom when you want to make *really* sure to achieve transparency.
    
    September 15th, 2012 at 00:16
    1. spellchecker
      
      It’s really 510 not 512 though. Please fix the article.
      
      September 15th, 2012 at 10:52
      1. Greg Maxwell
        
        Technically the smaller frame durations can crank out much greater than 512kbit/sec. It won’t usefully use much more rate than that, but you can produce 1275 byte frames at any duration. Someone who wants to say 512 vs 510 isn’t inaccurate. The effective maximum depends on the content and is very close to either those numbers.
        
        September 15th, 2012 at 20:07
      2. spellchecker
        
        I can’t reply to Greg, there is no reply button.
        
        I understand what you guys mean and talking from the side of the “customer/user” I don’t care. http://www.opus-codec.org/ and http://tools.ietf.org/html/rfc6716 show from 6kbps to 510kbps and it’s not correct, accurate or coherent to enter anything different anywhere else. I and many other people want to see, especially from you because of your big contribution, a good and precise article, same as these two “standard” websites.
        
        Thank you.
        
        September 18th, 2012 at 20:03
Richard M Stallman

Three cheers for Opus!

To be a free standard, it needs to be more than just open — people
must be free to implement it. I am glad to hear that Opus appears
to be safe from patents.

When talking about patents, I urge people to shun the overbroad term
“IP”. That term lumps patent law together with a dozen or so
unrelated laws (including copyright, design patent, trade secret,
trademark, geographical product terms, publicity rights, IC mask
monopolies, plant variety monopolies, and drug experiment data
exclusivity). Why be gratuitously vague, when you can say “patents”
and be precise and clear?

See http://www.gnu.org/philosophy/not-ipr.html.

September 16th, 2012 at 11:50
Manu

Ok, it seems you have developed a marvelous codec, but please clarify: Is opus better than OGG with Aotuv for encoding music (especially art music, including contemporary music like Xenakis’ Berio’s, Scelsi’s, etc, with all those electronic parts, microtones, clusters, etc) at high bitrates (I usually encode at 256 kbps, q 8).

All that I read about Opus focuses on its use for Internet and low bitrates, but could it be the substitute for OGG?

Thanks and regards

November 29th, 2012 at 08:07
Derrick Coetzee

@Manu: Based on the quality curve Opus seems to beat Ogg Vorbis in listening tests across a wide range of bitrates, but the difference at high bitrates like 256 kbps would likely be very small, and perhaps entirely inaudible (it certainly wouldn’t be any worse). My advice is to go ahead and download the encoder, try it on some of the music you listen to most often, and see if you can hear a difference on your best equipment. While there might not be an audible quality difference, there might be a substantial file size difference, especially if you use VBR (Opus tends to compress better).

Current software support: playback is supported out-of-the-box in the latest version of VLC (2.0.4) and Firefox. If you install DC-Bass Source Mod on Windows (see http://forum.doom9.org/showthread.php?t=164200), you get an Opus DirectShow filter and can play them in Windows Media Player. Support from iTunes is unlikely ever, but OSS players like Banshee and Songbird are likely to get support soon.

November 29th, 2012 at 15:12
Derrick Coetzee

Adding a small note to the above: foobar2000 also supports Opus, and is currently the only app I could find for adding tags to them. It’s pretty simple to transfer tags from a set of FLACs to a set of Opus files in foobar2000 (see http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:How_to_transfer_tags_between_two_sets_of_tracks).

November 29th, 2012 at 15:37
Mick

Great work. I like when functions are unified like what Opus does. It’s probably not going to be popular to raise this suggestion, but to me a perfect audio codec would be one that handles everything: lossy like Opus, Lossless compression like FLAC, and uncompressed audio as well. One audio codec to rule them all…

March 12th, 2013 at 04:35

Comments are closed for this article.

Hacks

By Jean-Marc Valin, Timothy B. Terriberry

A highly flexible codec

Use cases

About Jean-Marc Valin

About Timothy B. Terriberry

89 comments

It's Opus, it rocks and now it's an audio codec standard!

By Jean-Marc Valin, Timothy B. Terriberry

A highly flexible codec

Use cases

About Jean-Marc Valin

About Timothy B. Terriberry

Discover great resources for web development

Thanks! Please check your inbox to confirm your subscription.