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.
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
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.
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.
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.
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.
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).
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.
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.
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!
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.
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.
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.
>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:
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.
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 :-)
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.
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.
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.
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
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!
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