Opus — the Codec To End All Codecs 327
New submitter jmv writes "It's official. The Opus audio codec is now standardized by the IETF as RFC 6716. Opus is the first state-of-the-art, fully Free and Open audio codec ratified by a major standards organization. Better, Opus covers basically the entire audio-coding application space and manages to be as good or better than existing proprietary codecs over this whole space. Opus is the result of a collaboration between Xiph.Org, Mozilla, Microsoft (yes!), Broadcom, Octasic, and Google. See the Mozilla announcement and the Xiph.Org press release for more details."
Many people missing the point: HTML5, VOIP, etc (Score:5, Informative)
It's true that Opus does better than AAC and Vorbis at CD-quality bitrates and thus would be an improvement for music players etc.
But the improvements there are fairly small- in fact, Opus wasn't originally targeted at that kind of use at all, and the authors were quite surprised that it outdid those kinds of high-latency codecs. Opus is a very low-latency codec, and it combines Skype's speech compression technology and more music-oriented technologies (those introduced in CELT) to allow interactive speech and music over the Web.
Gaining marketshare in the high-bitrate stored music market against dominant formats like MP3 and AAC is hard, even when you outperform them substantially. But there's not really any established players in low-latency Internet audio. Opus blows all the other low-latency and/or low-bitrate codecs out of the water when competing in those other codecs' bitrate-latency "sweet spots", is the only codec which can compete across that kind of a range, is now a standard, is royalty-free, and is already implemented in Firefox.
Those who are saying "meh, only audiophiles will care" or "this won't get marketshare against AAC" are missing the point. This codec will change the face of the Web.
Re:No Loseless support? (Score:3, Informative)
(comment withdrawn)
Re:No Loseless support? (Score:5, Informative)
It can support up to 255 channels. The two-channel maximum is per stream. Multiple streams can be packed into single frames, but for >2 channels the mapping and coupling has to be signaled at the container level.
The standard tools available at opus-codec.org use Ogg as a container for "at-rest files," and Firefox, foobar2000, and gstreamer-supporting apps (like Opera on Linux) all play Opus-in-Ogg files. VLC and Rockbox will soon release versions with playback support for these too. Though RTP etc is a primary focus, the "at-rest file" support is ahead of the interactive support at this stage of the game.
A Matroska mapping is still in progress. Most likely, for the time being, Opus files will be predominantly Ogg, while the Matroska mapping will be more important for using Opus with video streams (esp. vp8, improving on the webm vp8+vorbis+matroska combination).
Re:No Loseless support? (Score:4, Informative)
Despite what the wiki page says, the RFC page states mono or stereo, and indeed the reference source code checks for channels equal to 1 or 2.
if((Fs!=48000&&Fs!=24000&&Fs!=16000&&Fs!=12000&&Fs!=8000)||(channels!=1&&channels!=2)||
(application != OPUS_APPLICATION_VOIP && application != OPUS_APPLICATION_AUDIO
&& application != OPUS_APPLICATION_RESTRICTED_LOWDELAY))
{
if (error)
*error = OPUS_BAD_ARG;
return NULL;
}
I think the 255 reference was probably a left over from the Vorbis definition. It's too bad that multi-channel isn't naively supported, as multiplexing multiple mono or stereo streams will be a bit of a pain.
Re:No Loseless support? (Score:2, Informative)
At least it looks like they thought of that and provided some helper code in the reference source. See opus_multistream.c / .h.
Re:No Loseless support? (Score:4, Informative)
Support for more than 2 channels is done at the container level, although the Opus format already has the framing planned. See http://tools.ietf.org/html/draft-terriberry-oggopus [ietf.org] for more details.
Re:No Loseless support? (Score:5, Informative)
the standard does not specify a recommended container format
See the Opus Ogg mapping [ietf.org] for more details. Of course, if people want to use other containers, we're not a container police.
Re:No Loseless support? (Score:4, Informative)
Testing that things work has been done for all kinds of bitrates (512kbps per stream * multiple streams in a surround encoding). It's just that Opus is transparent to most listeners on most samples before you hit 128kbps for stereo. It's extremely hard to do a worthwhile listening test when only a few listeners can tell even a few of the samples from the original.
Some people at hydrogenaudio.org have reported problem samples which they were able to ABX from the original at up to 160kbps. I haven't personally found any stereo samples I can reliably ABX from the original at above 80kbps.
Of course lossless has its place. You don't want to be doing a lot of decoding lossy files, editing them, and then re-encoding, since you'll get . For similar reasons, rather than transcoding from one lossy format to another it makes sense to keep a lossless master and encode to lossy formats from that. But for listening purposes, Opus is quite capable of being perceptually transparent. [wikipedia.org]
Re:No Loseless support? (Score:5, Informative)
A quick look at the graph shows that they stop at 128kbps, which would mean it's a great codec for high-quality real-time audio telephony rather than as a codec to span the spectrum of low end real time to lossless audio.
The reason the graph stops at 128 kb/s is that things become uninteresting at that point -- because nobody's able to actually tell the difference. With VBR, we've never had anyone report audio not being transparent above 200 kb/s. There's a reason people don't want to organize listening tests at 128 kb/s and (especially) above. It's indeed the case that we don't support lossless. That one is already covered very well by FLAC and there was no point adding completely different algorithms to handle that. Otherwise, Opus can replace MP3/AAC/Vorbis at rates above 128 kb/s too.
Re:Obligatory (Score:5, Informative)
See the "listening tests" part of our comparison page [opus-codec.org]. These are all tests that were performed by other folks, independently from us.
Some indications that it's not "Fully Free" ...yet (Score:5, Informative)
It fills a needed niche (Score:5, Informative)
To me the biggest difference is that Vorbis was competing head on with a strongly entrenched codec (MP3) and it's official successor (AAC). Opus on the other-hand fills niche in the audio encoding world that doesn't have an established winner; that is high-quality low-latency codecs. This area has largely been driven by cellphone market, and has focused on encoding voice signals at toll-quality, that is as good as an analog long-distance signal (8kHz mono). There really hasn't been much focus on creating a low-latency codec that can encode full-band (music signals), and Opus does that incredibly well. It also sounds much better encoding speech at the bitrates that are used for VoIP (rather than the lower ones used by cellphones).
The internet community has never really been happy with the performance of ITU specified codecs that have been primarily used for SIP and other VoIP applications in the past, and there is no good reason from them not to support Opus. The patent grants are there, the vender support is there, and there is no real competitor codec worth mentioning. I'm convinced this will make much deeper inroads than Vorbis did.
Re:Many people missing the point: HTML5, VOIP, etc (Score:5, Informative)
No. You're confusing transmission latency with algorithmic latency. If you're encoding music to store on an mp3 player, the format can use larger transform windows (usually MDCT) and other methods which mean the encoder looks at a larger number of samples before sending any output and the decoder has to read a larger amount of data before outputting any audio.
For codecs like mp3, AAC, etc, even if you had an infinitely fast computer and infinitely fast transmission, adding an encoder and decoder between the recording and the playback adds ~200ms of latency. That's fine for storing files on an mp3 player but totally unacceptable for real-time communication. Opus, by default, has 20ms of algorithmic latency, and it can be configured to go as low as 2.5ms.
Re:Sorry, nope. (Score:4, Informative)
Re:Many people missing the point: HTML5, VOIP, etc (Score:4, Informative)
No, he is using them correctly, referring to the application, not the medium.
Music playback doesn't require low latency; it doesn't matter if there is a 500ms delay between when you press the play button and you hear the music. Because of this data is encoded in (relatively) large blocks to allow for as much compression as possible.
VoIP on the otherhand does require low latency (100ms max). Otherwise it is very difficult to carry on a conversation because otherwise if you were to speak during a silence, it may not still be silent when the signal gets to when the other person, so you constantly talk over one another. The other potential application, live interactive music, requires even lower latency for musicians to keep in sync with each other. For this reason Opus is designed to encode in small blocks of data to obtain better latency.
Re:Some indications that it's not "Fully Free" ... (Score:1, Informative)
Those patents are openly declared as freely licensed and open-source compatible. See http://www.opus-codec.org/license/
Re:No Loseless support? (Score:3, Informative)
Lossless isn't audio encoding; it's data compression like Lempel-Ziv 77 and so on.
Support for such a thing would mean that Opus is not a codec, but a container/stream format which multiplexes completely different compression algorithms.
Those, we probably don't need any more of.
Re:Getting it right the second time! (Score:5, Informative)
there is test code, but I didn't see sample code explicitly.
Well, we have code snippets for the encoder [xiph.org] and the decoder [xiph.org]. Otherwise, there's always the code for opus_demo.c and opusenc.c/opusdec.c. Let me know what you think is missing and we can try improving that.
Codec latency, not network latency (Score:5, Informative)
When applied to a codec, "latency" (obviously) refers to stream latency, not network latency (the latter has nothing to do with a codec, obviously). The problem with codecs like MP3 for streaming purposes is that they encode fairly large "frames" of audio, and these frames must be recorded before they can be encoded, encoded before they can be transmitted, received before they can be decoded, and quite possibly also decoded (fully) before they can be played. It may be possible to begin playing before the decoding is complete, which would help a lot, but it also might not - it depends on the codec.
Suppose you've got a "high latency" codec (such as MP3) that uses a 250ms frame and requires full decoding (this is an example; I don't know the actual numbers for MP3). Then suppose you have a low-latency codec (like Opus) with a 15ms frame size. In both cases, your network latency is going to be the same (let's say 100ms). You want to stream audio over this connection. It's pretty high bandwidth and you've got a decent audio processor, so any codec can be encoded, transmitted, and decoded in 10ms or less.
At t=0, begin recording an audio (such as voice) segment.
Codec1 (high-latency):
At t=250ms, you've filled the frame and can begin compression.
At t=360ms, the frame has been encoded, transmitted, received, and decoded.
Total latency before playback can begin: almost 3/8 of a second after recording began.
Codec2 (low-latency):
At t=15ms, you've filled an audio frame and can begin compression.
At t=125ms, the frame has been recieved and decoded by the other end, and playback can begin.
Total latency: 1/8 of a second over the same network connection.
1/8 of a second can be perceived, but barely, and almost all of that is simply an inherent cost of the network transmission. 360ms is not only easy to perceive, it's quite enough to be annoying (think intercontinental call via satellite). There's tons of demand for low-latency codecs.
What?? (Score:4, Informative)
"Shine" is a really funny word for what HE-AAC sounds like at 16-24kbps. You can't polish a turd.
As far as AMR-WB/NB, you have to get down to 8kbps before AMR-WB sounds measurably better, and you have to get down to 6kbps before AMR-NB sounds better. Opus is tied with AMR-WB at 12kbps and better at 16kbps, and it's tied with AMR-NB at 8kbps and significantly better at 12 or above. Look at the studies linked from the comparison page [opus-codec.org] if you want more details, keeping in mind that the Opus encoder has continued to improve in the year since those studies were done.
Re:No Loseless support? (Score:5, Informative)
Re:Obligatory (Score:2, Informative)
I think Ogg plays on my Android phone, did you count that? I think it does FLAC, too.
Re:Obligatory (Score:2, Informative)
Actually at 64kbps beats the Apple HE-AAC encoder, aka AAC+.
http://www.opus-codec.org/comparison/ [opus-codec.org]
Re:Obligatory (Score:5, Informative)
what's with the FUD, dude? pre-release Opus was included in the hydrogenaudio listening tests months ago alongside all the relevant (not shit) implementations of HE-AAC. just because it doesn't say "plus" doesn't mean it doesn't include SBR (or PS or any of the other bells and whistles).
SBR is good for perceptual "niceness", but as far as _sounding like the original_ goes, it's often quite harmful. all these things are accounted for with the hydrogenaudio listening tests - they're an extremely anal community and wouldn't dare let prejudice through without a long and protracted flamewar. they're actually very trustworthy.
Re:Obligatory (Score:5, Informative)
aacplus was just the early CT-proprietary version of HE-AAC. They did test against the two best publicly available HE-AAC encoders, which have improved quite a bit since the aacplus days. Opus was better, by a statistically significant margin. [xiph.org]
Opus has band folding, which is in some ways similar to SBR but considerably superior. Halfway down Monty's two-year-old CELT demo page [xiph.org] there's some explanation and a visual of what this looks like on a spectrogram in low-bitrate situations. (Opus used technology from CELT but is considerably improved.)
If you really think HE-AAC type codecs sound like CD at 32kbps and so forth you are extremely insensitive to coding artifacts. Unless you meant mono for all of those.
Re:Obligatory (Score:4, Informative)
Actually, the "AAC" curve in the graph is meant to represent the best of AAC-LC and HE-AAC at a given rate. I agree that wasn't obviousl
Gah. No thats wrong! (Score:3, Informative)
This is why you shouldn't let the DSP engineers comment in public. Opus only couples two channels at a time, but the multichannel support is at the internal codec framing level. Not the container level. Container level would be a disaster, as basically nothing would be able to support it without a redesign (apps not designed for sample accurate sync between separate streams), and there wouldn't be ways to signal the use or mapping in most containers.
Re:Some indications that it's not "Fully Free" ... (Score:3, Informative)
Re:Obligatory (Score:4, Informative)
I can play ogg on any of the music-playing devices I have access to. My main music library is ogg. What are you talking about "5 devices"!?
Re:Obligatory (Score:2, Informative)
Were they blind tests?
Yes. Hydrogen Audio always performs blind tests.
Re:Obligatory (Score:4, Informative)
It is quite decent at high bitrates, however that kind of defeats the point mostly, the point is to be able to get music of similar quality to your 256k aac in less than that, say 192 or less.
With lossy after a point the bitrate stops mattering after it is good enough, otherwise we'd all just encode lossless.
Re:No Loseless support? (Score:5, Informative)
What Monty mostly regretted were some decisions that caused a large increase in the amount of *RAM* required. We were actually careful about that. Another improvement compared to Vorbis is that we don't have these codebooks that you need to carry in the headers. This means you can join an ongoing Opus stream with no signalling whatsoever.
Re:Obligatory (Score:4, Informative)
Ogg? 5 devices.
Is this actually true? I've not seen a non-Apple device that didn't support Vorbis...