Opus Audio Codec – FAQ | Hacker News Reader

Opus Audio Codec – FAQ

wiki.xiph.org

111 points8bitsrule79 comments

I really wish Opus would make it into wireless speakers and headphones. From what I've read, it might not be the most power-efficient format, however, and those tiny earbuds need to be /really/ efficient.

But I also suspect that popular wireless codecs (i.e. Dolbly's AptX, MPEG's AAC, and Samsung's Scalable) are powered by marketing fluff. I'd love an informed opinion :D

ALAC (Apple Lossless) was specifically designed to be power efficient, hence its use in AirPlay.

Interestingly one of the most power efficient lossy codecs is still ATRAC, Sony's MiniDisc codec, specifically designed to sip lightly at your AA batteries.

Doesn't seem to be the case at least in Rockbox, ATRAC is less efficient than Vorbis or MP3: https://www.rockbox.org/wiki/CodecPerformanceComparison

Maybe ATRAC was designed for the purpose of being efficient when using dedicated hardware without making the hardware expensive to manufacture? It's from the minidisc era so I'm not sure it would have been common for them to use general-purpose CPUs to decode audio by then

Indeed. Sony made ATRAC ASICs, and I doubt there's one in anything Rockbox supports.

Opus decoding in earbuds is totally doable. I've been working on an Opus mode for Bluetooth A2DP, it is a bit of work getting two implementations going, but I don't think Opus on earbuds is any more unreasonable than AAC.

One big benefit to Opus on Bluetooth devices is that a lot of content, particularly Spotify, YouTube, and Netflix, is already in Opus; so presumably if one application is playing then it should be possible to just proxy the frames right over the wire without reencoding; switching to decoding and mixing when system sounds play is also pretty straightforward in that case.

AptX HD is probably the most reasonable Bluetooth codec deployed right now, but it is proprietary to Qualcomm. LDAC is by far the silliest codec, it is very Sony, and designed for audiophools, but at least it's free and deployed on every Android device.

As a point of reference, I'm designing some ear buds that have pretty big batteries (~300mAh Li-Ion) and at that power budget the idle current for the battery power controller chip is sufficient to drain the battery in about a month (or several hours of active use).

I don't know if that's good enough to satisfy someone who purchases them, but it is what it is... I think you're probably right about active current consumption though, especially if you're using a modern MCU.

When I connect my headset to my android phone I get some marketing fluff notification about the codec.. and I cant dismiss this notification! so much for it being my phone.

APT-x is very good, low latency codec. It's been around a long time and is not marketing fluff. Some AAC codecs are also very well made for specific purposes. Opus is too high latency for headphones.

The lowest number I can find for "low-latency Apt-X" is 32 ms end-to-end over Bluetooth. Opus frames default to 20 ms wide but can be configured as small as 2.5 ms, so I don't think it's going to slow things down very much.

Opus is specifically designed to be low latency. I'm not sure where you got the idea that latency would be a problem. Of all the lossy codecs, there isn't much that is faster.

The only point in lossy encoding is to save space / bandwidth. Opus excels at getting good sound quality at lower bitrates.

If there's a talk or lecture on Youtube that you're about to grab, try the 50kbps Opus version and save your limited space for more important things, but you might need to remux from webm to an ogg container for compatibility.

    e.g. youtube-dl -f249 $URL  --exec 'ffmpeg -i {} -vn -c:a copy {}.ogg'

You can replace the --exec 'ffmpeg ...' with just -x (or the long form --extract-audio).

Yes, but with opus, that only put's the audio in a .opus container, which isn't as widely compatible as the .ogg container.

It is literally the same bits. Feel free to change the extension if that helps (it does on some old Android versions, for sure).

Source: I am a co-author on RFC 6716 and RFC 7845.

Oh, good to know, thanks :)

If you have youtube-dl and ffmpeg installed together on linux or both executables in the same directory on windows, youtube-dl automatically remuxes "incompatible" formats into an mkv file.

Yes, that's great for videos, but many audio players don't support matroska containers. Putting the opus audio in an ogg container seems to be most effective to get a playable file for most people, so that's my default suggestion.

Isn’t opus the default companion for both H.265 and AV1 in an MP4 container?

So why wouldn’t opus audio only in an MP4 container be playable everywhere those things are as well?

I really think we need to stop overloading the .MP4 file extension and standardize “.av1opusmp4” or “.h265opusmp4” or similar even though it is still an MP4 container. Even .webm is now overloaded with two codec generations.

We don’t get a “codecs” HTML attribute in a file system (at least not portably).

> e.g. youtube-dl -f249 $URL --exec 'ffmpeg -i {} -vn -c:a copy {}.ogg'

Why not just `youtube-dl -x` ?

See my reply above.

You can DL and listen to a longish YT track without the video - in far less time and with (usually) better audio - by specifying format 251 (usually available).

For example, an hour-long performance video mp4 at 1280x720 gets you 96k audio and 280MB. 'youtube-dl -f 251 url' will get you a 160K Opus in 54 MB.

To my ears Opus sounds sweeter and fuller than mp3. At 64K and lower bit-rates, it's near the top.

I love youtube-dl, but I usually just download the lowest bitrate Opus stream with two taps on my phone using NewPipe[1].

[1] https://newpipe.schabi.org/

Opus is weird because it can use fewer bits to encode complex sounds, and more bits on simple sounds. MP3/Vorbis/AAC all do the opposite. I’ve read it is because it has relatively poor frequency precision, for which it gains excellent time precision. So, on purer sounds it has to use more bits to maintain accuracy. But it’s so counterintuitive, that when I also consider it can’t do a 44.1k sample rate, I stick with vorbis for high-bitrate CD rips, just so I don’t have to wonder if artifacts are hiding somewhere. I think most of the testing by far has been on the low-bitrate encoding where it really excels.

Edit to add: I had my whole collection encoded with Opus at one point, and could never discern it from the FLACs in a few ABX tests I ran. It’s only theoretical problems that were nagging at me that made me switch back, nothing I actually heard.

> that when I also consider it can’t do a 44.1k sample rate

Why is that an issue? I don't think you'll hear any difference if the Opus encoding is resampled to 48khz.

I didn’t hear a difference, and some even claim it’s a benefit since a lot of cheap hardware only speaks 48k, so it’s better to encode for it in advance than resample during playback. But, what can I say? It nagged at me in a totally unscientific way that I can encode without a resample to vorbis, but opus makes me resample.

You're probably noticing that the two numbers are not multiples of one another and time samples are discrete so the only way to convert sample rates between 44.1kHz and 48kHz is by interpolating. Going from 96kHz to 48kHz is easier, you just drop half the samples.

Obviously with low pass filtering for artifacts due to the nyquist frequency. But you are correct that it won't be a one-to-one correspondence between the audio samples like you'd get if it divided evenly.

If you had 24kHz encoded music would it bother you if it got upsampled to 48kHz? What if it was 26kHz? I think the prior would bother me less because I know the samples are synchronous in the two time bases.

Yeah the forced interpolation nags me, even though it shouldn't, but also: if I'm going to encode 128 kilobits per second, I can either use those bits to produce 44k samples or I can use them to produce 48k samples. That's 9% more samples per second that need to come out of the same number of compressed bits. I'm sure there are reasons (like the high correlation between adjacent samples) why that doesn't matter. But, would you resize a 4400px image to 4800px before compressing it to a jpeg? No way, because if you target the same file size either way, you'd encode more bits per pixel from the 4400px original.

I haven't read the code but it sounded like they encode in frequency space so if they're already putting all the bits into encoding below 20kHz it seems like it would not change the size (as 44.1kHz to 48kHz already have no bits allocated to it).

Since the MDCT is discrete, I assume it operates on power-of-2-sized batches of samples. So (like you, without looking at the code) I would have assumed that more samples/s mean you need more transform blocks, which means you have to allocate fewer output bits per output block to hit your target rate.

You are probably right. I forgot about the whole power of two thing for ffts. That would definitely irritate the same part of my brain that would be put off by interpolating discrete samples even if they're inaudible. Same vein as how 7 is more random than 6.

If you worry about artifacts introduced by sample rate conversion, you shouldn't use a lossy format in the first place. The sample rate converter used by Opus (i.e., the speex resampler used in the opus-tools library) is completely transparent and does not introduce any audible artifacts. As per [1], the distortion caused by any lossy codec even at the highest bitrates is larger than that caused by re-sampling.

As for playback, most likely your sound card is already running at 48kHz; 44.1kHz may actually not be supported properly by your DAC (I guess since it requires a higher quality anti-aliasing filter). As [1] continues to explain, Opus is essentially shifting the burden of resampling to the encoding rather than the decoding side of things.

That being said, Opus technically supports odd sample rates such as 44.1kHz, but this has to be signalled in a side-channel. See [1] downwards.

[1] https://wiki.xiph.org/OpusFAQ#What_is_Opus_Custom.3F

edit: clarity

Yep, I've read all that before. I didn't mean to focus the discussion on the resampling--what I was trying to get across is, this codec acts differently than codecs that have been extensively tested and ABXed at high bitrates for years. I didn't even mention other factors like how it injects noise into bands on purpose (where you can also find references claiming that's a benefit and not a downside, of course). It was about a year ago, but beyond my own ABX testing I looked around quite a bit, and didn't see many high-bitrate tests out there. All the focus seemed to be on the 64kbit range.

This should not matter to me personally, as I have proven to myself that pretty low bitrates are transparent to me, regardless of the codec. But... I have the same psychosis that a lot of people have, where I think I can hear differences when I know which is which.

If space were an issue I'd use 90kbit/s opus (that was the threshold for me in my testing). It's actually pretty amazing, but since I have the storage space, I archive FLAC and carry around 256kbit/s vorbis, and don't even question the quality. It's easier to use more space than to fix my faulty perception!

That actually does make some sense to me, the same thing is done for video encoding, sort of.

If there's a static scene it encodes it at super high quality (but makes up for it by saying "don't change" for a while).

But if there's a fast scene a lot of details can get smudged without anyone noticing. I think people only tend to notice block artifacts with steps in luminosity during dark scenes, but I think you have to have a really bad encoding for that to be an issue in 2020.

https://github.com/erikd/libsndfile/blob/master/NEWS#L2 "Version 1.0.29 (2020-08-15) * Add support for Opus files."

Given that the patents on MP3 have expired, maybe libsndfile will finally support it...

That's https://github.com/erikd/libsndfile/issues/258

20 years ago we all wanted 128Kbps MP3 Quality at half the bitrate, AAC-LC ( Yes they somehow market it that way ), MP3 Pro, HE-AAC etc. And yet 20+ years later no single Codec can produce MP3 128Kbps quality at 64Kbps.

It was hard to imagine then, but not only do we now have cheap enough storage to store more music that you will ever listen, bandwidth and Internet speed has becomes so cheap we can now afford to stream it.

So in an interesting turn of event, the major usage is now 128Kbps and above. So often I see lots of 1-2Mbps Video Files having 256Kbps AAC within it. ( Normally you would put 128Kbps Audio and save those bitrate for Video ) And bandwidth and Data are only going to be cheaper in the coming 10 years.

In terms of Standard 128Kbps bitrate and above, AAC-LC in on par with Opus. And AAC-LC is officially patent free, as all patent has expired. HE-AAC v1 will be patent free as well in 3 years time.

Unless you are doing anything that focus on sub 64Kbps, you have an Audio Codec that is not just royalty free with patent grant, but free of patents, and it is extremely good.

I hope one day we would have a decent patent free video codec too.

> So in an interesting turn of event, the major usage is now 128Kbps and above.

Do you have any statistics to underpin this weird claim?

Opus is the obvious choice for a wide range of applications that don't want transparent music reproduction and couldn't afford 128kbps if they wanted to.

Down below 6kbps where Opus can't go there's Codec 2 (down to a few hundred bits per second) but I don't see that on the Internet.

Youtube has tons of videos with 50-70kbps Opus.

>And yet 20+ years later no single Codec can produce MP3 128Kbps quality at 64Kbps

I don't have any hard data on this, but I'm pretty sure that Opus produces better quality audio at 64 kbps than a 2000 MP3 encoder does at 128 kbps. A current version of LAME will probably be as much better than some old Fraunhofer encoder as Libopus is better than LAME.

As always with lossy audio, different codecs have different "killer samples", but here are a couple of results from experienced testers that support the assertion that Opus at 64kbps is suitable as a modern replacement for 128kbps LAME MP3:

https://hydrogenaud.io/index.php?topic=117489

https://hydrogenaud.io/index.php?topic=119424

Opus uses a neural network to determine which codec to use: https://jmvalin.ca/opus/opus-1.3/

Site has been hugged.

On another point, is Opus a popular format, given that alot of people now stream stuff mostly? IIRC, some of the Quake engines support it.

I have never seen an Opus file in the wild.

MP3 and FLAC are by far still dominant. Ogg is still popular I. It’s niche (eg game sounds, and I think Spotify uses it too)

>I have never seen an Opus file in the wild.

You have likely heard one. For instance, if you are a Youtube user.

On the website? Can browsers natively play them?

> On the website?

Yes, it's one of youtube's standard audio formats.

> Can browsers natively play them?

Yes.

Most browsers can play them, except for Internet Explorer and Safari for the mode you usually want to use (webm or ogg container).

https://caniuse.com/#feat=opus

Is there a reason why mp3 is still around? AAC has better compression ratios, and support is a non-issue. Maybe mp3 has better brand recognition? Most people know what a mp3 is, but probably wouldn't know what AAC or a .m4a is.

The roll-out of AAC (which was designed to address the problems with MP3, but was not backwards compatible) was slowed a bit by expensive licensing fees for hardware manufacturers and the lack of a good free encoder (though there were some very poor implementations)...

By the time this was sorted MP3 had gained massive popularity on "teh scene" and was soon followed by napster etc - the rest is history, so yes it's all about the "brand recognition" now sadly.

Most people could have a better sounding music collection in about half the size required for MP3 safely... still at least disk space is cheap these days.

The unfixable problem of MP3s "shortest allowable blocksize" causing audible smearing on transients will be with us until the format is abandoned, but I won't hold my breath.

These days for the best quality lossy audio you want AAC-LC encoded with either Apples encoder or the open source FDK-AAC by Fraunhofer (developed for Android) but fully cross platform... or Opus for a completely free and open codec , but still not yet as widely compatible.

> massive popularity on "teh scene"

More than that - scene releases required MP3 (LAME V2 IIRC) to be used.

MP3 has been around so long that it works with damn near everything, and the last patents expired in 2017, so it's now a completely free and open standard.

If you don't care too much about file size (LAME -V0 is ~256 kbps), it's a decent option for many purposes.

There are no quality open source AAC encoders like there are for MP3.

Whatsapp audio messages are encoded in opus.

Opus files are often enclosed in the Ogg container format, so some of your .ogg files might actually contain an opus stream instead of a vorbis stream. Files with an .opus extension usually use Ogg as container format as well.

I was originally thinking of Ogg Vorbis....

Opus is used by basically every company with an integrated product that they control, who doesn't own patents for inferior formats. That includes basically ~all VoIP software, games, YouTube on Chrome and other supporting browsers, messaging apps with audio features, etc. Basically anyone whose main business isn't audio. Because it's the best codec and it's free. It's be dumb not to use it. And if you control your entire product, you can just add support and use it without worrying about compatibility.

Unfortunately, the companies whose business is audio invariably have some sort of relationship with patented, shittier formats like AAC or even more obscure stuff that only exists to collect royalties like aptX, so they aren't going to market Opus to you as a consumer of audio formats or a feature in audio related products, nor promote support and compatibility across devices. And so you pay more, and get an inferior product :-)

Along with YouTube audio, it's used by Discord for voice chat.

And all WebRTC based messaging: Hangouts, Teams, Signal, WhatsApp, Messenger, Skype, etc.

Skype default codec is SILk

Sorry, yes - Opus combines SILK with CELT was the source of my confusion.

It's supported by video container formats and widely used. You've probably heard a ton of it watching videos online.

Virtually every video chat system uses it. Hangouts, Zoom, WhatsApp, etc

Opus is the standard audio codec in WebM, alongside VP9 or AV1 video.

AV1 does not appear to have been added yet

... as far as this source is concerned at least: https://www.webmproject.org/docs/container/#video-codec

It's one of the WebM audio codecs; Vorbis was first.

Thinking about it, I got confused and was thinking about Vorbis. D'oh!

My experience of using youtube-dl is that the best audio format to download from Youtube and Youtube Music seems to be opus usually. So, even if people don't consciously choose opus, they probably listened to opus files quite often.

On virtually every platform where trademarks and patent trolling isn't the norm. So you won't see it being advertised because Dolby/Apple/Samsung isn't making money off of it.

I had good times with Opus.

We have been capturing then encoding audio using Opus from a low-power chip (nRF52840) then sent encoded data through BLE.

Worked liked a charm! Encoding used 50% of the CPU time.

Opus is great. I encode all my music in Opus for playback (after buying it in FLAC).

Are all browsers supporting it now? I remember in the past Apple staunchly refused to support Opus and Ogg container. Is it better now after they joined Alliance for Open Media?

All major browsers now implement WebRTC, including Opus support. Also, most browsers now support Opus playback in HTML5, though AFAIK Safari only supports it in the CAF container. See https://caniuse.com/#search=opus

> FAIK Safari only supports it in the CAF container

Apple being Apple. While they "support" it, looks like they can't even do it properly.

Thanks for your work on this awesome codec!

https://caniuse.com/#feat=opus Safari (both desktop and mobile) is still problematic

Yeah, too bad. Apple just can never do the right thing.

I've been using libopus as the main codec for my audio streaming library. It has all I need: good compression/quality ratio, low latency and multichannel support. Also, the API is quite simple and well designed!

Opus is awesome. Up to 255 audio channels supported!

Reply on news.ycombinator.com