Now that the patents for the popular MP3 audio codec have expired, it’s unlikely that the format is going anywhere, despite many reports that misinterpreted what the end of the format’s licensing program would mean.

MP3 was the de facto standard for folks who wanted to rip music from CDs in the late 90s and early ’00s, as well as for those who shared music via Napster and other peer-to-peer networks. It’s still the most popular format for distributing podcasts.

But it’s not necessarily the most efficient way to compress audio. AAC offers better quality at lower file sizes. FLAC offers lossless audio at larger file sizes (that are still smaller than uncompressed audio). And Ogg Vorbis is an open source (but not as popular) alternative.

A few years ago a new player hit the scene: Opus is a free and open source audio codec that’s available royalty-free. Like AAC, it’s more efficient than MP3. And as of last week, it sounds way better at much smaller bit rates than it used to.

Opus 1.2 is the latest version of the audio codec, and it includes improved speech quality for recordings that use as little as 12-20 kb/s and improved music encoding for files that use 32-48 kb/s. It also includes improvements to variable bitrate encoding, bug fixes, and other enhancements.

In practical terms, here’s what’s that means. You can now encode stereo music at 32 kilobits per second, rather than just using that setting for mono files. And they sound good.

You can listen to the samples on the Opus 1.2 demo page, and to my ear, some audio encoded at 32 kb/s with the Opus 1.2 codec sounds better than 64 kb/s MP3 audio. The differences are harder to hear at higher bit rates though.

Improved audio quality at low bit rates means you could save space on your phone, computer, or MP3 player… although odds are if you’re using local storage you’d still be better offer going for a higher bit-rate which will sound better still. But it also means that you can stream audio at higher quality without using more bandwidth. Or you could stream audio at the same quality as before while using less bandwidth.

Opus is a relatively young audio codec, so support may not be built into as many hardware or software-based audio players. But as Mozilla’s Jean-Marc Valin notes, it’s the default audio codec for WebRTC, which means that if you’re using a web-based voice or video chat application to communicate with someone over the internet, there’s a decent chance you’ll either notice improved audio quality, reduced bandwidth use, or both.

Support Liliputing

Liliputing's primary sources of revenue are advertising and affiliate links (if you click the "Shop" button at the top of the page and buy something on Amazon, for example, we'll get a small commission).

But there are several ways you can support the site directly even if you're using an ad blocker* and hate online shopping.

Contribute to our Patreon campaign

or...

Contribute via PayPal

* If you are using an ad blocker like uBlock Origin and seeing a pop-up message at the bottom of the screen, we have a guide that may help you disable it.

Subscribe to Liliputing via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 9,547 other subscribers

12 replies on “Opus 1.2 audio codec brings better sound at low bit rates (free and open source)”

  1. Opus doesn’t really compete with the likes of MP3 or AAC. Those codecs are not suitable for real-time two-way communication because they break the audio up into large chunks that impose a ver large delay. Opus has an almost imperceptible delay, and provides support for high quality two-way communication. Check out the Wikipedia article about Opus to find out more. https://en.m.wikipedia.org/wiki/Opus_(audio_format)

    1. My understanding is that Opus is comparable/competing with mp2/AAC
      in
      addition
      to
      being used for voice.

      It’s basically at least two use cases or codecs in one and it’s royalty free!

      Bound to take over in time. Best formats *always* win out 🙂 LOL

    1. Well, if you add AAC to that player, it’s going to be a $2.50 player due to patent royalties 😉 OTOH, I can see Opus being added easily….

  2. Software decoding on phones is not good for battery life. This effectively kills Vorbis, flac and similar formats on phones.

    1. I’ve been using FLAC (CD quality and HD) on my Xperia Z2 and Mi Pad for several months now and I haven’t noticed significant changes in battery consumption vs 192k-ish MP3s. I’ve have not tried FLAC with older phones ot tablets.

    2. This release of Opus 1.2 has a ton of ARM Neon optimizations to improve decoding performance on mobile devices.

    3. I’m having a lot of trouble finding out what exactly a phone can decode in hardware only. The only codecs mentioned are video ones, the actual codec chips take a decoded input signal… is it possible everything including MP3 is in software making your point moot?

    4. Hardware decoders on phones are only for video codecs. Audio is decoded in software. Opus CPU requirements are more than MP3, but comparable to AAC… and about half of what HE-AAC requires. But in all cases, your phone will probably draw more power powering your headphones than performing software decoding.

          1. Even assuming that the 50% figure is true, it’s totally irrelevant for an audio codec because the CPU cost is already close enough to zero. These days, a smartphone CPU will use about 3W when running all cores at full speed. Opus requires less than 1% of the CPU to decode in real-time, which means less than 30 mW. Considering a 10 Wh battery, it means you could be decoding audio 24/7 for two weeks if that’s all your phone was doing. Of course, your actual battery life is much lower because decoding audio is just a tiny fraction of what a phone does — even when idle. Now, if you’re streaming the music over Wifi (or worse LTE), then the extra bitrate MP3 requires over Opus will actually cost you a lot more battery life than the extra CPU you’ll spend decoding Opus. Even for video codecs, powering the screen tends to take more power than performing the actual decode in software.

Comments are closed.