Earlier quoted context omitted.
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.
Opus Audio Codec – FAQ
71–80 of 81 posts
Re: Opus Audio Codec – FAQ
#7220 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 stre…
>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.
Re: Opus Audio Codec – FAQ
#73Earlier quoted context omitted.
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…
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,…
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).
Re: Opus Audio Codec – FAQ
#74Earlier quoted context omitted.
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,…
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.
Re: Opus Audio Codec – FAQ
#75Earlier quoted context omitted.
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.
Re: Opus Audio Codec – FAQ
#7620 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 stre…
>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:
Re: Opus Audio Codec – FAQ
#77Opus 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
Thanks for your work on this awesome codec!
Re: Opus Audio Codec – FAQ
#78Earlier quoted context omitted.
>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?
Most browsers can play them, except for Internet Explorer and Safari for the mode you usually want to use (webm or ogg container).
Re: Opus Audio Codec – FAQ
#79I'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!
Re: Opus Audio Codec – FAQ
#80Earlier quoted context omitted.
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).