Opus: a new, free, open audio codec that outperforms everything else

The IETF has finished its standardization effort for Opus, a new free/open audio codec that reportedly outperforms all other codecs on all axes. The codec was jointly created by IETF, Mozilla, Microsoft (through Skype), Xiph.Org (maintainers of Ogg), Octasic, Broadcom, and Google and Mozilla promises that a comparable video codec will come next.

One of the pernicious areas for free codecs is patents. The Opus FAQ says, "Opus is also covered by some patents, for which royalty-free usage rights are granted, under conditions that the authors believe are compatible with most (all?) open source licenses, including the GPL (v2 and v3)."

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.

It’s Opus, it rocks and now it’s an audio codec standard! (via /.)



  1. I can’t wait for half of the companies in this consortium to not implement it in their most important applications.

    1. Or if it actually is implemented in a financially significantly way, it’s quite possible (as Cory suggested above: “One of the pernicious areas for ‘free’ codecs is patents”) that lawyers from one or two companies (Huawei Technologies Inc or Qualcomm Inc), who claim to hold patents for Opus, will leap out of the bushes.   Bruce Perens (bless his heart) is looking into this issue for the Open Source community.

  2. To cut the graph off at 128 kb/s is misleading, is it not?  I had the impression that no one encodes MP3s at such a low bitrate anymore – and 128 kb/s is, oddly enough, the point at which AAC, Vorbis, and MP3 all converge with Opus.

    1. Quite the opposite. HydrogenAudio listening tests have for the most part stopped testing bitrates higher than 128 as mature implementations of all the major players are transparent outside known problem samples.

      EDIT: To be clear – when I say “bitrates higher than 128″ I’m speaking of the average bitrate of VBR files.

      1. By “known problem samples” do you mean “complex music in a relatively quiet room”?

        HydrogenAudio’s suggested encoding settings for regular listening are -V 2 and higher:  http://wiki.hydrogenaudio.org/index.php?title=LAME#Recommended_encoder_settings

        What I would be worried about in -V 3 or lower is the -Y switch.

        But maybe you’re talking about something else. I haven’t done any ABX testing of my own in years, but 128 ABR sounds a bit low. But even if it isn’t, the settings at which an encoding is transparent varies with the rest of the hardware you’re using anyway, so a longer chart would still be useful. Even from a marketing perspective it would be great, since people who don’t know any better would think “Wow! The line is twice as long!”

        1. But even if it isn’t, the settings at which an encoding is transparent varies with the rest of the hardware you’re using anyway

          That simply is not true. 

          The setting at which an encoding is transparent has far more to do with listener training for the specific types of artifacts caused by encoders than it does with hardware.  And when there is a correlation with hardware it most often has to to with poor hardware – not transducers with decent response.

          This has been demonstrated time and time again, both through HA.org listening tests and by tests of the major companies.

          By “known problem samples” do you mean “complex music in a relatively quiet room”?

          Far from it. Unless you mean “transient response” when you say “complex music” there is little corelation between the musical complexity of a work and its difficulty in being encoded.

    1. 320 is overkill for MP3 – unless you’re fighting against hardware which can’t handle VBR files.

      LAME V0 actually performs better on problem samples involving transients as it is able to use the bit reservoir in a more efficient manner (while creating smaller file sizes) but even that doesn’t cure MP3’s problems.  Infact freeform MP3 @ 640 kbps still shows most of the problems that a 320 kbps MP3 does, throwing bits at it doesn’t help.

      The great thing about OPUS, though, isn’t the fact it performs well as a transparent musical encoder, it is that it (unlike MP3, AAC, Musepack, Vorbis, etc) is a low latency codec – perfect for realtime use.  The fact it does so well >= 96 kbps was a welcome surprise.


      And another great thing about OPUS is it does this with a believed clean patent plate. MP3 and AAC are both known burdened, and there is some suspicion about Vorbis.

      And yet another thing is performance vs encoder maturity. MP3 only performs as well as it does because of the availability of very mature encoders. The format is weak and problematic, yet it still approaches the bit efficiency of much more flexible and modern formats like AAC. This is almost entirely due to thousands and thousands of hours of listening tests and encoder tweaks. OPUS is performing well right out of the gate.

    2. you might note that the range of bitrates covers a swath of applications including voice encoding for limited bandwidth (think: skype, flv, &c.).

      i think what’s really notable is that developers can just use one piece of mostly-unencumbered free software for a lot of different app types, rather than supporting or choosing between different codecs. assuming that the computational burden is uniformly low enough, this is (in principle) a universal solution to a lot of audio compression domains.

      in short, you’re not going to notice it. it’s mostly going to be on the back-end of apps you (may or may not) use.

  3. You say “all axes”, but it quite clearly does not outperform several other codecs at extremely low bit-rates.

    1. Okay, maybe if you have a 4kb/s design spec, Opus is not your bag. But bitrates don’t typically hang around thaaaat low these days. And Opus isn’t perfect, just impressive.

    2. Note that Opus was explicitly designed for optimal performance on switched packet networks, especially TCP/IP.  At 6kbps, your encapsulation headers are already twice as big as the data payload itself.  6-8kbps is already silly-low for any Internet use.

  4. My big concern is, if it’s as good as it claims to be, is there a very high processing overhead? How do computational demands balance between compression/decompression phases?

    1.  That is my concern too.  Does it require a bunch of floating point math that will make it impractical for embedded devices (cellphones!)?  Does it just need a whole lot of computation to do its job?  Sounding slightly better won’t be of much help if your battery dies in 1/4 of the time. 

      1. i’m not a real programmer or computer scientist, but my cursory research is positive. OPUS runs as a mixture of two previous codecs, CELT and SILK. apparently CELT handles the higher frequencies with a small-windowed DCT and vector quantization, while SILK uses linear predictive coding to handle the low frequencies. afaik, integer DCT has been hyper-optimized by now, while LPC is inherently floating-point but very simple to implement.

        i don’t know the codec space well, but there’s nothing radically new in OPUS; it just unifies what already exists (this is a very good thing). i don’t see any problems.

        1. There are a few things that are new, or at least hadn’t been applied this way before.  For example, the spherical PVQ entropy coder that Jean-Marc (edit: ARGH! I suck. The PVQ was was Tim’s) invented turned out to have been invented before, which was useful because it also meant the IP landscape around it had also been researched carefully) but I’m unaware of other codecs that have deployed it.

          (PVQ is the mechanism by which Opus avoids needing large codebook headers like Vorbis).

      2. Dunno. Unless you’re rocking some 90s phone still, your phone is likely to pack a perfectly functioning FPU.

    2. Exactly my thoughts. It becomes really interesting when (if?) we start to see hardware OPUS decoders. As OPUS covers such a large range of applications, it may be attractive for manufacturers to put a hardware decoder into their microcontrollers. But I guess they’ll wait and see if it gains any traction first let’s hope it does.

      1.  Don’t expect hardware [accelerated] decoding, it won’t be needed.  This isn’t video.

        All the other lossy audio codecs decode with less than 30Mhz worth of ARM9.  Even if OPUS proves to need twice as much it will still be negligible.

  5. Generally, on any device that can’t play FLAC, the nature of the device will cause more quality loss than the codec. My FLAC collection (ripped by me from my own CDs) is 140GB or so, the LAME transcodes of that take up about 40GB or so.  I don’t think I’ll hear the difference on the bus.

    1. is there any music player which can transparently maintain shadow copies of lower-quality files for this purpose (i.e. it plays the FLAC, but copies the MP3 to your phone)? most of the linux players can transcode down during the transfer process, but they don’t keep a copy of the resulting file, and i don’t feel like maxing out my processor for hours every time i change music.

      i like the idea of keeping perfect copies around, and storage space is cheap, but the UI limitations make it impractical for my purposes.

      1.  I don’t know, to be honest,  but I just copy all the FLAC to a  separate folder, drag it into foobar2000 and convert. Then I delete the surplus FLAC after that. 

        Foobar2000 can transcode from anything it can play to anything it can play, and you can control codec EXEs with command line instructions in the preferences section. My Rockboxed Sansa Clip+MP3 player can play most things, but my lossy codec of choice is LAME VBR as it’s very widely supported.

      2. At one point I made a BASH script to do this to put every flac album on my system into a V0 album in its own folder at once, just for this reason.

        Actually abcde might even have that capability already, if it doesn’t, I’m pretty sure it can encode to BOTH if you wanted.

        1. what i really want is an actual player/playlist manager that can seamlessly play the high-quality stuff on the computer but copy the lower-quality stuff to my phone.

          but, since i usually just do random tracks, i guess i could just script it.

  6. The only way to hear music is to hire musicians to play for you, wherever you go. All other forms are inadequate to the discerning ear.

    Of course, if you can get away with not paying the musicians – even after a successful kickstarter campaign, that’s even better.

  7. I don’t have great ears (too close to the Marshall stack at one too many concerts, probably) so this probably isn’t super-important to me but I do wonder if Microsoft will make some support for this as a firmware update for those of us who gave them money for a Zune.   I fear not, but one can  hope.

  8. Now if they can just do this for video, so I don’t have to do codec vodoo balancing act to get various formats to all play nice togther.

  9. That graph is super-unfriendly to the colorblind (red/green, that is). I can barely tell the difference between the red and green lines.

    I mean, it’s not that difficult to use yellow and red, or black, or grey, or any number of colours that aren’t red and green, but nobody ever does.

  10. Opus just doesn’t have the warmth and depth of MP3. You get so much more of a musical experience with a good MP3 file.

    Of course, today’s kids (damn them all to Hell!) won’t care with all their iPods and DooDads sticking out of their ears playing that damn Dubby Steps music.

  11. Does it play in my car stereo?  No?  MP3s it is!

    Seriously, all these codexs are great, but if it’s not supported by my devices, I can’t use them.  MP3 works in my car, on my phone, on my computer, at work, through the Xbox and any other device that is capable of playing music that I can think of.  Unless something becomes as ubiquitous as MP3, I can’t see myself using it.

Comments are closed.