Opus — the Codec To End All Codecs

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."

Comments

Obligatory

[Anonymous Coward]

Obligatory.

Re:Obligatory

[plover]

That's the nice thing about standards. There are so many to choose from!

Re:Obligatory

[93 Escort Wagon]

Yup, that was my thought the moment I read this - and I bet it was the case for a large number of other Slashdotters as well.

As far as being "good or better than existing proprietary codecs" go... I'll wait and see what people less invested in Opus say. We heard the exact same things about WebM, and the various Oggs before that - and it turned out not to be the case, unless the "Free" status of a codec was given significant weight in the quality space.

Re:Obligatory

[jmv]

See the "listening tests" part of our comparison page. These are all tests that were performed by other folks, independently from us.

Re:Obligatory

[Anonymous Coward]

There are plenty of third party tests already, though I expect the one you'd be most interested in is: http://listening-tests.hydrogenaudio.org/igorc/results.html

Mozilla mentioned that XKCD comic in one of their own blog posts in fact!

Re:Obligatory

[Teancum]

What would make an audio codec something worth using that would make you switch?

I would assume that widespread support among major applications would be an issue. You could also throw in the ability to compact an audio stream better than alternatives might be useful in some applications. Simply having content in that codec would be very useful as well.

I would say being patent and license free (aka it can be incorporated into a GPL'd application) would be pretty far down the list, but not needing to pay a licensing fee might make the difference for some marginal applications or for start up groups needing some sort of audio playback where even a few extra dollars in royalties can end up costing more than it is worth (such as is the case for the current MP3 format).

Then again that is sort of what pushed the VHS format over Betamax in the video tape format wars.... small independent producers could mass produce VHS tapes cheaper than the Betamax tapes, and for marginal videos (*cough* porn movies *cough*) that made all of the difference.

The problem here is that audio codecs are pretty entrenched and as you've suggested that even free alternatives are available. Unless there is something substantially different being done by this codec that even a non-techie can notice and suggest that this new algorithm is substantially better, I really have a hard time seeing this being adopted widely. There might be some niche applications if the compression algorithm is even a few percentage points better, such as perhaps a transmission protocol for audio on the Iridium satellites. Something like that may even be useful to have an on the fly codec converter depending on how it is used.

Re:Obligatory

[Lumpy]

"What would make an audio codec something worth using that would make you switch?"

A car stereo that supports it, phones that support it, etc... There is a reason that mp3 is still the king, it can be played on 98,543,221.5 different brand sof devices and another 800 are created that support mp3 every 6 seconds.

Ogg? 5 devices.
Apple's codec? 5 devices.

mp3 will be around for another 10 years simply because I can buy a $0.25 chip and make the toaster my company is making play mp3's.

Re:Obligatory

[cpu6502]

>>>Ogg? 5 devices.
>>>Apple's codec? 5 devices.

What is Apple's codec? You mean that AppleLossless format? They don't even sell music in that format. :-( As for MP3 I look forward to the day it gets replaced with AACplusSBR as standard. That codec sounds so much better even in tight lowbit situations.

Re:Obligatory

[cpu6502]

>>>produce VHS tapes cheaper than the Betamax tapes, and for marginal videos (*cough* porn movies *cough*) that made all of the difference.

Not sure what you're talking about? There was porn on Betamax. The producers put it on both VHS and Beta, just as they made both Bluray and HD-DVD during the mid-2000s.

Re:Obligatory

[Smallpond]

Were they blind tests?

Re:Obligatory

[Anonymous Coward]

I think Ogg plays on my Android phone, did you count that? I think it does FLAC, too.

Re:Obligatory

[Anonymous Coward]

...and Opus sounds demonstrably better than AACplusSBR from both google's internal test and Hydrogenaudio.org's public double-blind listening tests at 64kbps. If its low latency and free license sees it implemented widely (and convergence of device functions will help drive that), I won't care so much about HE-AAC or HE-AACv2.

Re:Obligatory

[Anonymous Coward]

Ogg, yes. FLAC... depends on the Android device. Some support FLAC (almost all of them that have custom ROMs going, if you get the right ROM), but not all Android devices support FLAC. So, the FLAC might depend on which device you're specifically talking about there...

Re:Obligatory

[Anonymous Coward]

Actually at 64kbps beats the Apple HE-AAC encoder, aka AAC+.

http://www.opus-codec.org/comparison/

Re:Obligatory

[mug funky]

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

[jensend]

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.

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 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

[Anonymous Coward]

No, blind people can't hear very well -- that's why you need to raise your voice when talking to them.

Re:Obligatory

[ThatsMyNick]

Er, you dont need hardware support for FLAC, you just need an app that software decodes it for you (there are plenty, Winamp Pro is one that I believes run on all Android devices 2.2+, Ubermusic with FLAC package too I believe)

Re:Obligatory

[UnknowingFool]

By Apple's codec I think you mean AAC which isn't Apple's per se but part of the MPEG-4 specification. As for devices, lots and lots of devices support it.

Re:Obligatory

[jmv]

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

Re:Obligatory

[Anonymous Coward]

But if you wave your hands, you don't need to speak as loud.

Re:Obligatory

[hobarrera]

Actually, I belive this one might be the exception. So many mayor players major playes have participated and are standing behing Opus, I can easily see this becoming the dominant codec for loosy audio. It won't displace flac, as flac is looseless, but it will displace oga, mp3, and other major players given time.

I'm pretty sure it'll become the de facto standard in web as well, given the browser support, and HTML5's new <audio> tag.

(I know that XKCD comic is meant to be a joke, but it does actually prefectly reflect what happens with almost every new standard these days)

Re:Obligatory

[hobarrera]

There is no dominant format at the moment. Music is ogg, mp3, flac and probably a few others. Flac is loosless, so it won't dissapear, but the other two gradualy will.
The html5 <audio> tag hasn't been used much yet, and I'm betting <audio>+Opus will be the one to domainte over current flash-only players (since it seems it'll be the best supported format).

Movies in MKV files are actually container with video streams and audio streams. There's also a small variety of formats used for those audio streams, and maybe Opus catches on. I certainly hope it does.

But the market is fragmented, there's lots of different format being used in different areas. Opus has a lot of giants behind it, if they do their part, Opus support will be better than that of many other formats in the long run, hence users will tend to adopt it, in time.

Re:Obligatory

[hobarrera]

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

[Anonymous Coward]

Were they blind tests?

Yes. Hydrogen Audio always performs blind tests.

Re:Obligatory

[Anonymous Coward]

Using Vorbis as an example, it's actually commonly used in a number of applications (like video games) where they don't want to pay licensing fees for every copy sold. Unfortunately, this doesn't translate very well to consumer usage. People paying for music are getting it in AAC, and people downloading it are getting it in MP3. Transcoding the audio is essentially a loss no matter what.

If Windows, Mac, and Android all began including the codec automatically then you could potentially see quick uptake. That's unlikely to happen though, so it's going to be a long uphill battle. Of course, we're likely reaching the point of diminishing returns, so battle could go one for a decade or possibly even multiple decades gaining traction and eventually becoming the market leader. At the very least it will be used in the backend of applications.

If it fully succeeds, then we all benefit from better audio reproduction and no licensing costs. If it's success is limited, then we still benefit from better audio reproduction within application and lower licensing costs. Either way it's a win.

Re:Obligatory

[PhunkySchtuff]

What's it like at high bitrates? I notice the graph on the comparison page ends at 128kbs - personally I prefer my music in 256kbs AAC (iTunes Plus) or in LAME V0 MP3 which is a VBR at around 190-220kbs.

I'd be interested to see (hear?) if this codec is better than AAC or MP3 at high bitrates.

Re:Obligatory

[afidel]

wtf dude, itunes only outsells Amazon by 3.5x, there are many people buying mp3's. In fact I just bought a couple $5 albums last night =)

Re:Obligatory

[Midnight Thunder]

By Apple's codec I think you mean AAC which isn't Apple's per se but part of the MPEG-4 specification. As for devices, lots and lots of devices support it.

Yup. Its actually Dolby's codec.

Re:Obligatory

[Anonymous Coward]

We blinded each subject ourselves. Yes we take pride in our work.

Re:Obligatory

[davester666]

AAC & MP3
-already have widespread use
-multiple implementations in hardware producing acceptable quality output using minimal power [for example, there are no widespread complains about audio qualify from iPods by consumers]
-fixed, known licensing fee's [in the pennies per unit range]

Opus
-nobody uses it for anything
-must use a software decoder, much more expensive power-wise
-offered for free, but of course, it's unknown if it infringes on any patents

So, if you are a device manufacturer, why would you spend any effort on this, when the existing solution you have already works acceptably for 99% of your customers, you won't save any money anytime soon [as you can't drop MP3/AAC support, because everybody's music is in that format], you open yourself up to patent trolls?

Re:Obligatory

[walshy007]

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:Obligatory

[Anonymous Coward]

OGG vorbis is better than mp3

Re:Obligatory

[walshy007]

The point is to be able to use lower bitrates and get the same quality. This is especially useful for things like audio streaming over the internet, where less bandwidth used equals more space for listeners.

Re:Obligatory

[Anonymous Coward]

Many devices play OGG vorbis, even when they do not mention it in the package. Just try it.

Re:Obligatory

[Knuckles]

Short version for you: Microsoft - Skype. Can you figure it out now?

Re:Obligatory

[Anonymous Coward]

They aren't that comparable. MP3 is optimised for music, but not for voice. For spoken text only it doesn't compress nearly so well. Opus and well as many of the codecs on that page are meant for telephony. MP3 isn't used in VoIP telephony, except occasionally for playing music on hold. For VoIP other codecs compress far better because they are optimised for voice.

Re:Obligatory

[FireFury03]

I would say being patent and license free (aka it can be incorporated into a GPL'd application) would be pretty far down the list

Depends on your application. For an iPod-type device the licence is probably unimportant, but for wide spread support in web browsers, having to get a licence is a big problem.

Then again that is sort of what pushed the VHS format over Betamax in the video tape format wars.... small independent producers could mass produce VHS tapes cheaper than the Betamax tapes, and for marginal videos (*cough* porn movies *cough*) that made all of the difference.

Sony actually refused to grant porn producers a licence to sell Betamax tapes, which is why the porn producers used VHS. So it wasn't about VHS being cheaper, it came down to the fact that they were simply not allowed to use Betamax. Interestingly, when BluRay first appeared (also a Sony format), Sony again refused to licence it to porn producers. When they realised that this was actually giving HD-DVD a big edge over BluRay they backpeddled on that decision.

The problem here is that audio codecs are pretty entrenched and as you've suggested that even free alternatives are available.

There are a significant number of applications (mostly streaming) where both the encoder and decoder are under the control of the same person - i.e. some proprietary software is used to decode the stream, which is supplied by the company running the stream. In this case, the "entrenchedness" of existing standards is moot - the codec can be chosen based on what is best for the job rather than what is most widely supported.

Re:Obligatory

[FireFury03]

Ogg? 5 devices.

Is this actually true? I've not seen a non-Apple device that didn't support Vorbis...

Re:Obligatory

[Anonymous Coward]

OGG works on Android devices, so a lot more than 5. You could say "everything but Apple", really.

Re:Obligatory

[arth1]

The point is to be able to use lower bitrates and get the same quality. This is especially useful for things like audio streaming over the internet, where less bandwidth used equals more space for listeners.

For audio streaming over the Internet, it's even more important to gracefully deal with packet loss and packets arriving out of order. You don't want drop-outs and audible artefacts.
This generally means that a format that uses large decoding buffers will lose out.

ABX-testing in perfect listening conditions with zero packet loss and no out-of-order packets is useless if this were the purpose.

As for high-end and local streaming, well, FLAC and other lossless formats are always going to be better than any lossy format, no matter how good they are.
And with today's bandwidth and storage capacities, where 2 TB drives, GbE and 300 Mbps WiFi are standard, there's little point in using lossy compression for audio.

So again, I fail to see the importance of this, unless it is to sneak DRM into music again.

Re:Obligatory

[hufter]

PowerAmp plays practically everything. I wouldn't be surprised if it soon supported this Opus thing too.

Re:Obligatory

[moronoxyd]

I would say being patent and license free (aka it can be incorporated into a GPL'd application) would be pretty far down the list

You seem to miss the fact that licence costs are alse important for any commercial program that is suppost do encode data using the codec, as it is important for manufacturers of devices that are expected to use the codec.
If a company has to pay licence fees for each smartphone or tablet it builds a new format will not take off. If it is free adoption is only a matter of programming to include the codec in the own product.

Re:Obligatory

[sociocapitalist]

Might be interesting - http://www.bbc.co.uk/news/magazine-19524962

Re:Obligatory

[moronoxyd]

Actually, I belive this one might be the exception. So many mayor players major playes have participated and are standing behing Opus, I can easily see this becoming the dominant codec for loosy audio

Apple doesn't seem to be behind it.
So they will likely try to block Opus being used.

If they have some patents that cover Opus, on the other hand, they might be willing to start an OPUS-LA and cash in.

Re:Obligatory

[hazydave]

The point is what it's always been -- streaming audio over the internet. Sure, FLAC is fine for LAN use.

The good: this does (in theory) AAC quality compress, but with much lower latency. A use case: playing music live over the internet. You need high quality, but if the latency is over 1ms, every musician is compensating for the delay already, and if it's over about 10ms, you just can't play together. And since it's music, the quality does matter.

Another good thing, the XKCD cartoon not withstanding, is that it scales all the way from voice to music in the same standard. So you can think of scaling the bitrate to the audio source, without worrying much about falling off the end of where it works. Of course, in reality, it's using two different technologies (the CODEC formerly known as SILK at voice rates, the CODEC formerly known as CELT at music rates -- looking at that, it's not quite as cool as it might have seemed).

The bad thing: this is 2012, and the standard only goes to 48kHz.

Re:Obligatory

[squiggleslash]

I believe you're confusing it with AC-3. AAC is not the same thing, is in many ways a would-be competitor, and originated in an attempt to create a new "clean" codec during the MPEG 2 standardization. The MPEG Audio Layer 1/2/3 thing resulted in some good ideas, but Layer 3 in particular isn't exactly how you'd put together an audio standard if you started from scratch.

Re:Obligatory

[Skarecrow77]

That's fine with me, My last hearing test said my ears only go to about 18 and 20 kHz respectively.

Re:Obligatory

[Pope]

"They" who? I buy songs on Bandcamp in ALAC all the time.

Re:Obligatory

[Skarecrow77]

my 5g ipod with rockbox did between 10 and 11 hours playing -q4 (~128kbps) vorbis last time I tested it, which was really at least 3 years ago, probably better now. I know they've done improvements to the codec implimentation since then.

the same 5g ipod playing similar bitrate MP3, tested around the same time, was better by about 2 hours.

I'm not sure what qualifies as "guzzling", but I doubt I'm ever going to listen to my ipod for more than 11 hours without recharging it, especially considering I keep it plugged into a lighter socket in my car pretty much full time now.

Re:Obligatory

[Anonymous Coward]

Back in America, I bought a small Samsung digital audio player. It supported Ogg Vorbis. While in China, I bought a Chinese brand portable video player. It also supports Ogg Vorbis. Both Android phones I've had also support Ogg Vorbis. You don't really know what you're talking about.

Re:Obligatory

[cduffy]

-offered for free, but of course, it's unknown if it infringes on any patents

It isn't known whether there are undisclosed submarine patents for licensed codecs either.

If those licenses came with insurance against suits from non-parties to the licensing pool, then maybe it'd be worth something.

Re:Obligatory

[Knuckles]

Where can I download Skype with Opus support? Oh, that's right, I can't because it's not available.

The world I live in has something called future, and a notion of potential. Don't know about yours.

Re:Obligatory

[Anonymous Coward]

The world I live in has vapourware, where promises are made and not kept. I'll believe it when I see it and I'll remember you claiming that Opus was going to make it beyond just some niche codec that only a handful of people will ever use.

Re:Obligatory

[MikeTheGreat]

Ogg? 5 devices.

Is this actually true? All the non-Apple devices that I've seen do support Vorbis...

There, clarified that for you (At least, I'm pretty sure.....) :)

Re:Obligatory

[KermodeBear]

Just a note on portable music players...

I was looking to buy on about a year ago, and I didn't want an iPod. I find Apple's stuff to be too overpriced for me. I eventually settled on a Cowon J3 - it supports MP3, WMA, OGG, FLAC, WAV and APE (whatever APE is). There's also several other players out there that support a wider ranger of formats - it can just be hard to find them.

The fact that some players support Ogg and FLAC in particular lead me to believe that future Opus support is not out of the realm of possibility - especially if we vote with our wallets, and contact these companies to let them know that their support of various formats was a major selling point.

Re:Obligatory

[cpu6502]

I don't see AAC*plus* on that chart. I just see straight AAC which is not much better than MP3.

Re:Obligatory

[BancBoy]

I believe you're confusing it with AC-3. AAC is not the same thing

I don't think they were confusing it. I've heard Dolby mentioned as part of the collaboration of AAC going back to the early days.

http://en.wikipedia.org/wiki/Aac#History

Re:Obligatory

[squiggleslash]

Well, the OP described it as "Dolby's codec", which would be extremely dubious. Dolby was only a contributor, one of many, and there's no suggestion they actually steered the process or were the primary contributor.

In my experience, whenever I've heard someone describe AAC as a Dolby thing, they have, on further proding, mistaken it for AC-3 - there's a remarkable number of people out there who think they're the same thing.

Re:Obligatory

[Lennie]

You might want to watch, euh listen, to the demo:
https://www.youtube.com/watch?v=iaAD71h9gDU#t=28m03s

I thought it was pretty impressive.

There is a lot of detail in the talk about Opus if you want to know more about it.

Re:Obligatory

[Lennie]

That is because Opus is still very new and any browser which wants to support WebRTC will need to support Opus, because Opus is mandatory-to-implement (real time communication: think video-streaming and voice calls and lots of other applications. Also includes peer2peer connection support between browsers with NAT-traversal and encryption).

But did you know you can download Skype with one of the two codecs on which Opus is based on and that it also includes WebM video ?

Re:Obligatory

[Lennie]

Pretty much every browser will probably support Opus, because the IETF WebRTC working group (real time communication like video chat) has made Opus it mandatory to implement for their specification.

As every mobile device, tv and desktop in the near future probably includes a browser... I think many devices will support it.

Re:Obligatory

[Lennie]

In Firefox 15 (the current version) already added support for Opus.

Opus is one of the 2 audio codecs which are mandatory-to-implement if a browser wants to support WebRTC (real time communication: video chat, voip from the browser and all that jazz).

Telco's are following at WebRTC really closely, some see it as an oppertunity. Other probably not.

So your smartphone might be getting support for it soon.

So will your fancy TV in the near future include a browser ? And a webcam (some already do) ? And because of it also support WebRTC ?

Re:Obligatory

[jmv]

You mean this?

Re:Obligatory

[hobarrera]

Apple doesn't have any power in the browser market to kill Opus (what's safari's usage share??).
I also don't see how they could benefit by killing it in any way. Though I agree they may not use it internally for some of their own software (ie: voice chat).

Re:Obligatory

[Midnight Thunder]

In the past licensing documents for AAC were certainly taking you to Dolby's site, though now I can only seem to find references to decoders and encoders on their site. Here, I wasn't confusing AC-3, which is a different beast and not as globally supported on portable devices. Either way checking the referenced docs confirm Apple wasn't really a contributor to the format, instead they were simply the first mover when it came to mass meia players.

Re:Obligatory

[Bengie]

96kb vorbis is about as good as 192kb MP3. I don't think it would be hard to break past MP3 in quality.

Re:Obligatory

[Anonymous Coward]

The bad thing: this is 2012, and the standard only goes to 48kHz.

See the FAQ. The encoder will cheerfully accept any sampling rate, but will convert to 48K before transmitting. Any audio over 20 KHz will be lowpass-filtered anyway; they won't waste bits on encoding the really high-frequency stuff that many people can't even hear.

If you have a use case for 192 KHz audio streaming, I suggest you just do it in FLAC.

Re:Obligatory

[plover]

What would make an audio codec something worth using that would make you switch?

For the listener, there doesn't have to be a "switch", because it's not an "either-or" proposition. An audio playback system already has a library of codecs at its disposal, and chooses the correct one based on the encoding. Some players like Windows Media Player will dynamically download new decoders on demand as required. There is no burden on the consumer, as long as their devices support the new codec. And sure, other players (like iPods) may require some kind of user-initiated update, and those could mean a loss of audience if no update is available. There will always be those who are disenfranchised for a few years.

But the real cost of encoding is borne by the distributor of the audio. Those are the people who have money reasons to switch. Consider the guy running a web service who is pumping out music streams to thousands of listeners. Adding a new codec that's 10% more efficient at compressing audio means he can fit 10% more listeners in the same bandwidth, which gives him 10% more ad revenue. If only half the users have the new codec, well, he's still gaining 5% more capacity. If I'm making a greeting card playback chip, perhaps I can buy smaller (and therefore cheaper) ROM chips to hold the same amount of sound. If I'm building a telephony switch, perhaps I can increase the number of channels I support simultaneously. If I'm building a battery powered music player, a more efficient decoder can mean longer battery life, more song storage capacity, or could make more CPU available to other applications making it a faster overall device. And to anyone paying an annual license for their current encoding software, a truly free codec could mean lower costs.

Re:Obligatory

[hobarrera]

Howadays software-based audio-decoding is almost as efficient as hardware-based. There' almost no differente in energy consumption, and the cost of the additional isn't worth it.

Re:Obligatory

[walshy007]

For audio streaming over the Internet, it's even more important to gracefully deal with packet loss and packets arriving out of order.

what makes you think it doesn't do that? when packets are lost the audio degrades gracefully. These scenarios were tested also but people seem less interested in them.

And with today's bandwidth and storage capacities, where 2 TB drives, GbE and 300 Mbps WiFi are standard,

So.. do you download _all_ of your audio in flac? even podcasts for later playback? if not, then there is another use for this codec, better quality at smaller file size.

Likewise with games with large portions of audio content, they _could_ ship flac versions of all audio.. and bloat the game an extra few gigabytes for no reason.. or they could encode it with a tiny amount of loss.

FLAC is not a solution to all problems.

Re:Obligatory

[Teancum]

I would say being patent and license free (aka it can be incorporated into a GPL'd application) would be pretty far down the list

You seem to miss the fact that licence costs are alse important for any commercial program that is suppost do encode data using the codec, as it is important for manufacturers of devices that are expected to use the codec.
If a company has to pay licence fees for each smartphone or tablet it builds a new format will not take off. If it is free adoption is only a matter of programming to include the codec in the own product.

I've done plenty of software development for commercial development (including "all rights reserved" proprietary licenses) that I know this not to be true... in general. If the license cost is prohibitively high it becomes an issue, but to license something like the Dolby AC-3 or the MP3 codecs (to name a couple) it really is a trivial licensing cost for most software. Most of the reason you would use those codecs is because the boss (usually a clueless CEO who happened to attend a computer convention or saw a snazzy advertisement.... or because a competitor is using that codec) has told you that is the codec you will be using. Rarely have I seen even a technical evaluation of the quality of a codec, if that is audio or video, unless it becomes a very serious issue.

If the software is being developed on a shoestring budget, perhaps license costs are a bit more of an issue. Otherwise I have seen companies simply buy a fatter network pipe that carries more bandwidth rather than trying to become more efficient.

Low-end consumer electronics might be an issue for expensive licenses, but that isn't where you get market share either. I know it sounds weird, but it is the early adopters who get to set which codecs become popular. If there is a new technology or some other kind of gizmo that is just getting developed that has some "gee whiz" features (something like the original iPhone/iPad or really innovative like the Nintendo Wii), those are the devices that establish standards. DVD-Video made MPEG-2 a pervasive A/V codec and is the reason that codec has been used by HD-television in America.

The problem is that you really don't know ahead of time which of these kind of devices is going to be the hot consumer device. Companies like Apple and Microsoft are "safe bets" on mass consumer products, but even that isn't a guarantee.

No Loseless support?

[ThatsMyNick]

Seems to cover a wide range of range applications. I wonder why they left out loseless encoding. That would have made it the one true codec for everything.

Re:No Loseless support?

[Eponymous Hero]

loseless? your fat fingers are consistent at least.

Re:No Loseless support?

[Anonymous Coward]

FLAC mainly, same reason that is it not replacing codec2 either.

http://www.youtube.com/watch?v=iaAD71h9gDU

Re:No Loseless support?

[plover]

They also left out n-channel support. You get mono or stereo, but that's it. No 7.1 surround encoding. That would have made it the one true codec for everything. That and lossless encoding. The two true codecs for everything.

Oh, and support in the iPhone. That would have made three true codecs. Among the many true codecs... oh bugger, I'll start again.

Re:No Loseless support?

[Tablizer]

I wonder why they left out lossless encoding.

Because the specification was recorded on a lossy medium.

Re:No Loseless support?

[iluvcapra]

Seems to cover a wide range of range applications.

Except surround sound. Or any spatialized content aside from L-R. Or synchronization with video, or any other kind of stream.

Also their list of uses are all streaming/interactive, like teleconferencing; the standard does not specify a recommended container format. Vorbis, FLAC and MP3 all have prescribed at-rest file formats.

Re:No Loseless support?

[Intropy]

They mention FLAC about 7 minutes into that video for anyone looking for it. They don't say much other than that they aren't trying to replace codecs for lossless (FLAC) or very low bitrate (codec2).

Re:No Loseless support?

[Volanin]

Opus has support for up to 255 channels. Indeed, lossless was the most glaring omission, but considering the obsolescence of MP3HD, I think they must had good reasons to leave it out.

Re:No Loseless support?

[iluvcapra]

(comment withdrawn)

Re:No Loseless support?

[tlhIngan]

Seems to cover a wide range of range applications. I wonder why they left out loseless encoding. That would have made it the one true codec for everything.

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.

At least looking at the page - the summary mentions it's the "one codec to rule them all", but the page leads me to believe it's something you'd use for say, teleconferencing and VoIP more so than multichannel lossless high-definition audio.

Perhaps they intend it to work reasonably well in all cases, but it looks like testing was done only to low-bitrate encodings of 128kbps and lower. At which point it looks like yes, for that scenario, it's the best.

Re:No Loseless support?

[jensend]

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?

[Anonymous Coward]

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?

[Anonymous Coward]

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?

[jmv]

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 for more details.

Re:No Loseless support?

[Anonymous Coward]

How can one withdraw/edit a comment? Or is this a troll/fake?

Score: -1 (Retarded)

Re:No Loseless support?

[Requiem18th]

File a DMCA take down notice against your comment.

Re:No Loseless support?

[jmv]

the standard does not specify a recommended container format

See the Opus Ogg mapping for more details. Of course, if people want to use other containers, we're not a container police.

Re:No Loseless support?

[jensend]

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.

Re:No Loseless support?

[jmv]

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:No Loseless support?

[johnsnails]

Is that a new sig or do you change your sig based on what you happen to be commenting on at the time?

Re:No Loseless support?

[sconeu]

One Codec to rule them all
Once Codec to find them
Once Codec to bring them all
And in the RIAA's darkness bind them

Re:No Loseless support?

[Em Adespoton]

I noticed there were no hardware manufacturers of note on the supported list -- are you planning to get chip-based support for Opus (so that it'll be handled transparently by all the phones etc out there, including, say Apple)?

Re:No Loseless support?

[Kaz Kylheku]

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:No Loseless support?

[Kaz Kylheku]

Sync with video? What?

Raw waveform data can be synced with video.

Just say: one video frame = so many audio samples (at such and such a sample rate).

Re:No Loseless support?

[ZorinLynx]

For the love of ghod, let's not start encouraging the creation of MKV files with new audio codecs that won't be supported on existing embedded devices that play MKV.

Re:No Loseless support?

[ZorinLynx]

Actually generic data compression algorithms don't work very well on audio files. Lossless audio codecs like ALAC and FLAC do waveform analysis and "know more" about the nature of audio files so that they can be compressed more than your typical compression algorithm like gzip would do.

Re:No Loseless support?

[socceroos]

jmv and I both work for Mozilla and are on the Opus team.

Re:No Loseless support?

[cheater512]

You need more than 255 channels?

And Ogg is a recommended container format with Matroska support coming.

Re:No Loseless support?

[jmv]

I don't think silicon support for audio codecs is really useful anymore. Audio codecs have such a low complexity compared to video that modern smartphones can run them really easily.I haven't measured exactly, but I'd say you can probably decode an Opus stream with about 2% CPU on the latest Android phone. Not worth paying for extra silicon.

Re:No Loseless support?

[jensend]

Gack, should have previewed. Of course the link is supposed to be "you'll get generation loss."

Re:No Loseless support?

[sglewis100]

And I'm sure they would simply love to re-encode the iToons library to support the new codec.

I'm guessing that this codec fails simply because Apple didn't write it and will, therefore, refuse to support it.

Have you met MP3 and AAC? The two main formats covering 99% of all music on iDevices, neither of which Apple invented? I'm sure the real reason is they control so much of the market, and most of those users, myself included, really don't care what's more space efficient, unencumbered by patents, royalty free, higher quality sounding, or easily incorporated into Windows Phone 8. Yawn!

Re:No Loseless support?

[Anonymous Coward]

nothing "plays" MKV. They're able to read the MKV to "play" the streams inside of MKV. The entire purpose of MKV was to allow pretty much anything to be thrown into it; so of course no 1 device will forever be able to play ALL codecs that MKV can hold.

Re:No Loseless support?

[mug funky]

the net's already awash with 10-bit x264 encodes in mkv.

unfortunately the developer said there was an efficiency boost at 10-bit, so all the l33t types out there who would encode with --placebo (and apparently ignore the meaning of that word) went ahead and started pirating in 10-bit because they could.

Re:No Loseless support?

[mug funky]

yeah, there's some FUD floating round in here. strange. i'm trying to figure out who could be threatened by this codec that isn't among the developers of it.

Re:No Loseless support?

[mug funky]

it does wonderfully on images.

Re:No Loseless support?

[sjames]

To get more than 2 channels you use multiple instances of the codec.

The at rest format of MP3 is the raw stream written to a file, just like Opus.

At least that's what a cursory read suggests.

Re:No Loseless support?

[ThatsMyNick]

Apple is part of the MPEG LA patent pool. I wouldnt be surprised if they retained their music in formats that support the group than switch to free alternatives.

Re:No Loseless support?

[arose]

Particularly after rockbox optimizes the playback code.

Re:No Loseless support?

[Anonymous Coward]

Is it little enough processing that a device could decode them with some kind of general purpose microcontroller and have the power requirements be dominated by amplification (for headphones)? Because there are mp3 players around with no display/phone attached and they have a niche.

Re:No Loseless support?

[Tough Love]

I'm guessing that this codec fails simply because Apple didn't write it and will, therefore, refuse to support it.

I'm guessing this codec takes off like a rocket because high quality + low latency = voip.

Re:No Loseless support?

[Midnight Thunder]

Time will tell, but being portable device friendly in terms of decode implementation is an important factor. Apple will probably continue supporting AAC, because they already support it and Opus will probably need to prove itself before they take a risk. Heck, Microsoft wasn't much better when it was exploring alternatives to WMA. The difference here is that WMA is Microsoft's format, kept to themselves, while AAC is Dolby's. Though it should probably be mentioned the MPEG4 container was based on the Quicktime container.

Re:No Loseless support?

[ignavus]

One Codec to rule them all
Once Codec to find them
Once Codec to bring them all
And in the RIAA's darkness bind them

In the land of Hollywood, where the money lies.

Re:No Loseless support?

[electrosoccertux]

GZIP, RAR, etc all do waveform analysis as well.
There was one time I zipped the WAVs and it turned out right around the same as the FLACs.

Re:No Loseless support?

[hobarrera]

Flac is already the de-facto standard, and it's free, open, and royalty-free. There's really no real need for Opus (or anyone else) to replace it in any way.

Re:No Loseless support?

[jrumney]

Time will tell, but being portable device friendly in terms of decode implementation is an important factor.

Note the exclusive use of integer and fixed point math in the reference implementation of the Opus codec. This was designed for embedded use (probably in VoIP handsets, which are even lower powered than media players).

Re:No Loseless support?

[johnsnails]

Nice!!!

Re:No Loseless support?

[johnsnails]

And Australian in the case of you by the looks of it. Cool.

Re:No Loseless support?

[Metabolife]

Wh_ re-lly n_eds lo_sl_ss en_od-ng? Yo_ ca_'t ev_n no_ic_ t_e mi_s_ng d_tai_s!

Re:No Loseless support?

[Spaseboy]

Not only the patent pool but the entire container format is based on QuickTime.

Re:No Loseless support?

[jmv]

Even then, I suspect a heavily power-optimized ARM core might be better than some custom hardware that's designed just for Opus. Keep in mind that any hardware you design will still have a fully programmable core in it, so in the end what you gain by doing more stuff in hardware you lose by not having your chip nearly as optimized as a more general-purpose CPU.

Re:No Loseless support?

[jmv]

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:No Loseless support?

[SuricouRaven]

There's a little more to it than that, because you need to make sure the sync stays if the video decoder has to skip a frame or a lost packet occurs when streaming. Syncing is something the container format handles. Except for AVI, which sucks at it.

Re:No Loseless support?

[MrEdofCourse]

"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. " "Opus - the Codec To End All Codecs"

Those two statements seem at odds. If I encode all my music at >128kbps, what advantage does Opus have for me that I'd consider switching?

It seems, based on the graph that Opus would have a niche for things like VoIP or mobile streaming radio, but really not so much as Yet Another Codec for music libraries and other uses where the codecs are entrenched and likely to be over 128kbps.

Re:No Loseless support?

[91degrees]

Doesn't lossless generally require a fairly different design philosophy though? With lossy compression, presumably you're looking for the trade-off between compression ratio and quality. With lossless you're only interested in maximum compression.

Re:No Loseless support?

[SnowZero]

Here's an example where you can really tell the difference when compared to the earlier lower-bitrate sample.

Re:No Loseless support?

[Carewolf]

If it isn't built in from the start, multi-channel will never work well.

1. Formats that hasn't been planned for it, will lack stuff like declaring WHAT the channels are. AC3 for instance can have 4-channel left-center-right-back, or 4-channel left-right-leftback-leftright. So just knowing you have 4 channels is USELESS.
2. It will lack optimizations similar to joined-stereo, so you achieve good bit-rates by not encoding the similarities between all the channels over and over again.

Re:No Loseless support?

[moronoxyd]

MP3 was around and widely used before the iPod came about, so Apple HAD to support it.
And where you're wrong in regards to AAC others wrote already.

Re:No Loseless support?

[squiggleslash]

OK, I have two instances, each having two channels. Which of the following is a valid assumption?

- The audio is diamond quadraphonic (f/b/l/r)
- The audio is square qudraphonic (fl, fr, bl, br)
- The audio is stereo, with a rear speaker, and a center speaker (fl, fc, fr, b)

- Other

(And what about an SW?)

To support more than two channels, you need to do more than simply increase the number of audio streams. It's important to include the appropriate metadata, and that metadata should be associated with the audio itself.

I'd say Opus missing this is as big a mistake as it was for MPEG 1 Layer1/2/3 audio back in 1991 and it effectly rules out using Opus for at least one popular audio task, especially in an environment in which we're less than a decade from the most popular surround sound codec (AC-3) going into the public domain.

Re:No Loseless support?

[squiggleslash]

I can't speak for RAR, but really, honestly, GZIP doesn't do waveform analysis. It just looks for repeating strings. If you managed to zip up a WAV and it ended up about the same size as a FLAC, then you were either very luckly, or had a WAV that was dominated by, say, zeroes.

Re:No Loseless support?

[jelle]

"Keep in mind that any hardware you design will still have a fully programmable core in it,"

Say what?

Re:No Loseless support?

[SiChemist]

You could encode your music at 128kbps or less and use less space with the same (or better) audio quality than your >128kbps encodings.

Re:No Loseless support?

[sjames]

That will depend on how you encoded it. You should include that metadata in the container. Opus is a CODEC, not a container.

Containers are a dime a dozen. Any reasonably thoughtful student programmer can come up with a passable container. The codec is the hard part, especially WRT the patent minefield.

Opus outperforms AC3 in ABX testing and it is royalty free right now. Why would I want to wait 10 years for a lesser codec?

Re:No Loseless support?

[Baloroth]

If Opus at 128kbps is comparable to another codec at 192kpbs (as an example), you can save disk space by using Opus instead. But regardless, Opus is primarily intended for the real-time streaming field, rather than at-rest files. It excels in that field: the fact it can also be used for everything else just means you can use 1 codec for everything, even if there isn't necessarily a compelling reason for people with only at-rest files to switch.

Re:No Loseless support?

[squiggleslash]

That will depend on how you encoded it. You should include that metadata in the container. Opus is a CODEC, not a container.

OK, that kind of phrasing annoys the hell out of me. Opus is a codec, but that has nothing to do with the issue at hand, and stating it like that implies that the person you're talking to is unaware that Opus is a codec.

Leaving that aside, no, the correct place for data that explains why there are four channels is in the codec. You wouldn't rely on a container to have information about which channel is left, and which is right, for basic two channel stereo. And that metadata is required information if a decoder is going to play the audio correctly. I have four channels of audio. My player has two speakers. How should it combine the streams? Are you expecting that to be done by the container demuxer? Why?

Bear in mind this isn't something normally done by a container demuxer either. AC-3 and DTS both get considerable savings within the codecs themselves by combining the channels. If AC-3 and DTS both, for reasons unknown, decided that they should only support two channels per stream (why two?) and so anything that used them needed three independently encoded streams, with the demuxer post-processing the audio and sending it to the right speakers, then they'd become considerably less efficient.

This is a bad idea. If it were a good idea, then nobody would have standardized on AC-3 and DTS to begin with, because MPEG 1 already supported the ability to have multiple audio streams per container.

Re:No Loseless support?

[Twinbee]

Have you considered making your own container, or combining it into the file somehow? MP3 is popular I think not just because it got there first, but everybody recognizes the extension. It would be lovely to have an ".ops", ".opus", extension or similar.

Re:No Loseless support?

[TeknoHog]

On the other hand, audio codecs are designed for streaming, so they cannot take advantage of long-time correlations. Then again, many generic compressors do the same, I guess for memory and I/O reasons, though some like rzip and lzma can use huge buffers.

Re:No Loseless support?

[plover]

Do you find there is still demand for mid/side stereo encoding? I'm not in the audio business, but it seems to be a holdover from ancient technologies like FM stereo. Since virtually everything is digitally processed these days, do people really need the pre-combined streams? When does it provide a realistic advantage?

I know that a mid-channel track can be processed on its own and played back as a mono source. You don't have to burn the energy to decode a second track. But that's its only advantage. And it is an advantage only in a very limited energy environment, where the tiny draw of a chip processing a second audio track would cost you battery life. But when I look at modern uses of audio, there are no cases where mono playback intersects with tightly limited energy:

• 
  Stereo: personal music (headphones); car audio; home entertainment systems; commercial television; video playback.
• 
  Pure mono source: telephone; web videos.
• 
  Mid-channel mono only: public address; ambient background music.

For all cases of stereo, you have to decode two streams anyway. There is no saving in having a mid/side encoding, as you have the mid channel in one track and the side channel in another. Two tracks == twice the energy, regardless of encoding technology.

For all cases of pure mono, you don't need mid/side encoding, as you have only one channel of input. Energy saved automatically.

For the cases where you would downconvert a stereo mid/side channel encoding to a mono playback system, the typical environments are fixed installations, where wall power is readily available, and the tiny energy consumption of the second track is not an issue.

So from my limited point of view, I don't see any rational reason to continue to support such an arcane format. What rationale did you have for including it?

Re:No Loseless support?

[sjames]

OK, that kind of phrasing annoys the hell out of me. Opus is a codec, but that has nothing to do with the issue at hand, and stating it like that implies that the person you're talking to is unaware that Opus is a codec.

The topic is a codec and you were claiming it was deficient due to container related issues, what was I to think?

Actually, if you encode left and right channels separately rather than as joint stereo, you WOULD need the container to tell you. Joint stereo is a special case where the codec gains additional compression by stripping some of the redundant channel seperation information.

In the case of multiple channels, I would expect your demuxer to pass the metadata about the channels to post-processing. After all, only your gear knows how you have the speakers laid out, my encoder has no idea. The decompressor's only job is to convert the compressed stream to uncopmpressed. It is not responsible for figuring out how to map N channels to <N speakers in your room.

DTS is a proprietary combination of container and codec specifications (with an added synchronization protocol in the theater version). A logical equivalent would be something like ogg/opus or mkv/opus.

Likewise, AC-3 includes container information conflated with the compressed streams. Technically, it is far less flexible since it can only handle pre-defined layouts, but in practice those layouts are almost always used so it rarely comes up as a problem.

In the case of video, those audio containers are muxed into another container to add the video stream(s)

Re:No Loseless support?

[dinfinity]

Lossless audio codecs like ALAC and FLAC do waveform analysis and "know more" about the nature of audio files so that they can be compressed more than your typical compression algorithm like gzip would do

I remember seeing this claim a while ago and having a hard time believing it (it's supposed to make a 20% difference or some number like that). I was always under the impression that modern compression algorithms are pretty close to what is mathematically possible, so I tried to find some proof for the claims for an hour. Could not find it.

It could be my lacking Google Fu in combination with my lacking expertise in this area, so my honest question is: really? Why not add FLAC-like analysis and encoding to generic compression algorithms? A potential improvement of 20% seems worth going for.

Re:No Loseless support?

[jmv]

The idea of mid-side encoding is purely for quality and compression efficiency. The idea is that human perception is (partially) mid-side and because left and right are often correlated, we can remove some redundancy to save bits. In fact, the way we do it, mid-side doesn't even make downmixing easier (like for FM), so it's purely for efficiency.

Re:No Loseless support?

[jmv]

We tend to use .opus for file extension, although people can use what they like. Using Ogg doesn't mean you're forced to use the .ogg extension you know.

Re:No Loseless support?

[jmv]

Yes, any hardware you design to implement something as complex as an Opus decoder will have a programmable core. Otherwise it's insane.

Re:No Loseless support?

[Twinbee]

Please consider promoting the 'opus' extension, even if you don't enforce it. In one way, I love your attitude of letting others decide, but it would be great to see an opus file, and think, "that's an opus file" and that REALLY helps advertise the name (it needs to stick in people's memory for both consumers and developers).

Also, maybe it'd be a shame to wrap it up in Ogg, as that's associated with a music format which doesn't quite match up to yours in specification (and it's good to differentiate the two by filetype I think in principle).

Re:No Loseless support?

[Bengie]

MKV is a generic container format that was designed to be codec neutral. Why not start complaining about how HTTP should be the only application layer protocol to use TCP because it's the most popular.

Re:No Loseless support?

[olau]

The difference is that you're embedding some stuff in the coding, that's why you can do better with a specialized algorithm. For instance, consider the trivial case of an algorithm for compressing the Bible. If you embed the Bible in the decoder, you only need to transmit one bit, is this the Bible or not (if not, you of course have to transfer everything). This would be really, really efficient for transfering the bible, a generic algorithm would never be able to do that, but it would obviously be worse for everything else.

Each time you specialize a compression algorithm, you make it worse for something else because in one way or another you're reserving bits for your specialization.

Re:No Loseless support?

[Trogre]

Wait, so FLAC isn't a codec? Not sure I follow...

Opus?!?

[ackthpt]

What's wrong with Bill the Cat?

Re:Opus?!?

[jfengel]

Transmission reliability problems. Even when a packet got lost, it would still ACK.

Re:Opus?!?

[Ken_g6]

What's wrong with Bill the Cat?

Maybe that's what they'll name the video codec they just started working on?

Re:Opus?!?

[White Flame]

Not only that, but there are ambiguities regarding the Cathy codec's ACK.

Patents

[K. S. Kyosuke]

Cue MPEG-LA calling for a patent portfolio to be created and licensed for hard cash, under their gracious auspices, of course.

Re:Patents

[ackthpt]

Cue MPEG-LA calling for a patent portfolio to be created and licensed for hard cash, under their gracious auspices, of course.

File patent-troll suits proactively, a-la-The Minority Report, "Our mutants predict you will be violating our property rights in 5 years, so you can start paying now."

Re:Patents

[fustakrakich]

It's a trap! A prenup and a restraining order have more teeth.

Re:Patents

[Anonymous Coward]

Cue MPEG-LA calling for a patent portfolio to be created and licensed for hard cash, under their gracious auspices, of course.

Without patents, how long would the status quo have been "good enough" before people invested the time and money into something better as they have done here?

Re:Patents

[mug funky]

that's actually a very good point.

however, how are we to stop the status quo for suing over something they didn't invent or implement?

there's always MS on the good side here though, and they hold a fair bit of sway with MPEG-LA. just nobody tell Sony anything.

Re:Patents

[sjames]

I imagine about 5 minutes. The only reason it took this long to get here is that Opus had to be careful not to step on a landmine.

Yay!

[Anonymous Coward]

Can't wait to try this on my portable music player!

Re:Yay!

[Anonymous Coward]

Same here... mine's Android based, so I hope codecs will appear pretty soon.

Sorry, nope.

[Guspaz]

be as good or better than existing proprietary codecs over this whole space

Except upon clicking on that link, their own graph is showing that it's not as good for anything under ~12 kbps or so, when compared to AMR-WB and AMR-NB. Furthermore, they have no data on HE-AAC below 64 Kbps, when in fact HE-AAC only really starts to shine at substantially lower bitrates like 16-32 Kbps. Bitrates in the 4-16 range are particularly relevant since you see a lot of voice communication down there.

Re:Sorry, nope.

[jmv]

Bitrates below 16 kb/s are irrelevant on the Internet. Just the overhead (IP+UDP+RTP headers) of sending packets every 20 ms is 16 kb/s. At that point, you might as well transmit some real quality.

Re:Sorry, nope.

[twocows]

Then why are they including data on it?

Re:Sorry, nope.

[femto]

For low bit rate voice (down to 1400bit/s) you can use codec2.

Re:Sorry, nope.

[Anonymous Coward]

In the interest of full disclosure.

Re:Sorry, nope.

[Guspaz]

There are many cases where lower bitrates can be quite useful, not all of which involve sending the data over a network, or over RTP. Two-way radio and embedded storage are some examples. That said, my statement was more about objecting to your claim in the summary that Opus (which, bizarrely, is the name of my city's bus passes) was "as good or better than" when clicking the very link of that text shows data which immediately contradicts that. Opus does seem to be an impressive codec, but not for low bitrate uses. For example, there are codecs specifically targeted at very low bitrates, such as Codec2, that Opus isn't competitive with.

It's awesome

[LSD-OBS]

About 9 months ago, I implemented Opus in our VoIP products, replacing G722 and Speex. It kicks a whole lot of ass. Compared to speex, It's far better coded, uses far fewer CPU cycles, and sounds vastly better (even to me, and I have shitty hearing). Similarly, we replaced all our old audio DSP pipeline, based on the Speex library (thanks Xiph.org, etc) with the low-level components from WebRTC (thanks Google!) and things have never sounded better.

Re:It's awesome

[LSD-OBS]

/* Not sure if trolling, or just not good at reading */

Re:It's awesome

[Twinbee]

He means he cant easily discriminate between the two, not that his ears distort things (or undistort them as the case may be).

Re:It's awesome

[LSD-OBS]

The key word is "even". "even to me". Implying (but obviously too subtely for some) that my opinion of the sound quality is in agreement with the opinions of others. In this case, several dozen others. Unanimously.

Furthermore, I never said how shitty my hearing was. My version of shitty is having a hard time discerning between 160kbps and 192kbps mp3s, which several of my more keenly perceptive friends are able to do.

Re:It's awesome

[Kaz Kylheku]

Umm, no. The more subtle the difference, the better hearing you need to be able to resolve an AXB comparison. (Is sample X equivalent to A, or equivalent to B).

If you can hear a difference with poor hearing, then it must be substantial.

Re:It's awesome

[LSD-OBS]

(And in case that hasn't cleared things up enough, let me say that the difference between Speex on highest quality and Opus, even on its lower quality settings, is like night and day)

Re:It's awesome

[Anonymous Coward]

HIgh Def audio ie G722 on VoIP calls can be subjectively good or horrific. I have repeatedly fielded "audio quality" issues on VoIP calls that thurned out to be someone not used to conversing on a G722 call. Have you ever listened to someone chewing food on a phone call with G722 codec? It's nauseating. The audio quality is that good and clear, but also amplifies unwanted ambient noise (specifically heavy-breathers and noisy eaters).

Re:It's awesome

[cyclomedia]

Actually, if he has shitty hearing and it sounds "vastly better" then that suggests to me that someone with good hearing would experience an order of magnitude more "better", think about it in terms of resolution.

Many people missing the point: HTML5, VOIP, etc

[jensend]

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:Many people missing the point: HTML5, VOIP, etc

[Anonymous Coward]

Don't be surprised if they are the first ones making a mass usage of it, streams, cams.

Re:Many people missing the point: HTML5, VOIP, etc

[Wraithlyn]

Opus is a very low-latency codec [...] to allow interactive speech and music over the Web.

Very good post, but I think you have your terms backwards? The web is a HIGH latency medium. Local storage on an MP3 player would be LOW (damn near zero) latency.

Latency = delay, not speed.

Re:Many people missing the point: HTML5, VOIP, etc

[stor]

> This codec will change the face of the Web.

Maybe not the whole face, but hopefully it will change the mouth :)

Re:Many people missing the point: HTML5, VOIP, etc

[bananaquackmoo]

No he is using RELATIVE measurements. This codec would be lower latency than other codecs when used on the internet.

Re:Many people missing the point: HTML5, VOIP, etc

[gnoshi]

No, the terms are right: it is low latency in that it doesn't *add* much latency, which is a critical feature in bidirectional real-time communications (like Skype). Having a low-latency codec is even more important for the Internet, because of the existing latency you have pointed out which is cumulative with any delays introduced by the codec.

Re:Many people missing the point: HTML5, VOIP, etc

[jensend]

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:Many people missing the point: HTML5, VOIP, etc

[pavon]

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:Many people missing the point: HTML5, VOIP, etc

[Teancum]

This codec will change the face of the Web.

MP3 seems to be working just fine for 99% of the applications on the web. MP3 players are ubiquitous, including on a web page. For those that don't work (like Wikipedia), they seem to be using Ogg Vorbis. That quite a bit of Ogg Vorbis seems to be in Opus is true, it is still a different standard.

I fail to see how this is going to be making a change, unless Fraunhofer (or somebody else from out of the blue) decides to do something stupid like Unisys did with the LZW algorithm and the GIF image format. I think that boat has sailed too and unlikely to happen.

I'm not saying that there will be some advantages to using Opus, but "changing the face of the web" seems very unlikely. The web just isn't a killer app any more for stuff like this.

Re:Many people missing the point: HTML5, VOIP, etc

[complete loony]

Music playback doesn't require low latency; it doesn't matter if the music player has to process 500ms of audio before you hear the music.

FTFY, a fast CPU won't necessarily take 500ms to decode the first 500ms of audio, but since it already has all of the audio data it can take as long as it needs to. I know that's almost uselessly pedantic. The best kind of pedantic.

Re:Many people missing the point: HTML5, VOIP, etc

[Tough Love]

Great but if there are no ASICs to decode it it will never be used in music players.

Did you forget that a "music player" these days is actually a phone with four processors running at 1Ghz+ ?

Re:Many people missing the point: HTML5, VOIP, etc

[jones_supa]

MP3 seems to be working just fine for 99% of the applications on the web.

I've been thinking...to write neat language, people should use something like "pretty much all" instead of "99%", unless you know that the percentage is actually exactly that.

Re:Many people missing the point: HTML5, VOIP, etc

[drakaan]

This has already been repeated ad nauseum, but to reiterate, the main reason that this codec is attractive is that it facilitates live audio transmission. The fact that it competes favorably in non-streaming (high latency) applications is just a bonus. Supplanting MP3 is not part of the idea that it would change the face of the web.

Re:Many people missing the point: HTML5, VOIP, etc

[TeknoHog]

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.

It does if you're the sound guy in a theatre. This is why old tech like CD players are still used there, because you can keep the disc spinning while paused, to be played instantly when needed. A lot of music player software is also OK, because they can pre-buffer things, but portable gadgets without such optimizations are useless.

Re:Many people missing the point: HTML5, VOIP, etc

[Teancum]

MPEG audio codecs (including MP3) are also used for live streaming as well. That is what is being used when I turn on my television and watch the "digitial television" broadcasts from the various television studios now. That is about as "live" as you can get.

Please don't think I'm complaining that because other solutions exist that creating a new standard is an effort in futility, just that it is going to be an uphill climb in terms of widespread acceptance. Making such a standard available without a license is going to make a difference.

Perhaps live stream internet radio broadcasts could be happening again if people could set one up without paying horrible fees that simply prohibit a small start-up from even trying at the moment.

Re:Many people missing the point: HTML5, VOIP, etc

[drakaan]

Right. But streaming (broadcast) doesn't require low latency...there's no way to perceive lag as there is in a conversation. This codec does good streaming (as does MP3), but it's also low latency, which is why everyone who's excited is excited. It makes live *bi-directional* connections possible without a noticeable delay in the conversation. Could be used online, in cell phones, etc, etc. Acceptance is a function of utility and need, so widespread adoption depends on somebody making software that uses it to a distinct advantage. If I can make software that's better than yours, and I don't have to pay licensing fees, then I have an advantage, which is why Microsoft, Google, etc, are all in on developing it. Actually, those two companies alone are enough to potentially ensure that it gets adopted.

Re:Oh boy!

[Russ1642]

Audiophiles? Really? The only format they care about is original wax drums rubbed with a diamond and amplified by analog equipment connected by gold cables soaked in unicorn tears. They want nothing to do with digital audio codecs.

Re:We already have that: FLAC

[bgat]

It's 2012, we have the bandwidth and storage to go to lossless.

Not in wireless spectrum, especially if you are not the only radio. Far from it, actually.

Getting it right the second time!

[bill_mcgonigle]

Kudos to the folks working on this. We were all rooting for ogg/vorbis/xiph, but they had some lessons to learn. Positives that I see for Opus:

• libopus is available now
• it has an integer-only compile flag
• it's BSD licensed
• patent grants from big industry players
• doxygen API docs
• big open source projects already support it
• orchestrated PR

still could use some love:

• apparently it's CPU/power efficient but that's not bragged about (and many would suspect otherwise).
• some of the documentation is just a link to slide decks from conferences
• there is test code, but I didn't see sample code explicitly. Yeah, you can grab ffmpeg source or whatever, but purposeful sample code is written to be as explanatory as possible. Maybe it's in the tarball, but if it is, say so on the download page.

Still, an order of magnitude better than the last attempt at gaining industry acceptance of free codecs. This one might just work out!

Re:Getting it right the second time!

[WrecklessSandwich]

• apparently it's CPU/power efficient but that's not bragged about (and many would suspect otherwise).

My understanding was that this was a pretty big issue with OGG compared to MP3. I had one of the few MP3 players at the time (~2006 or so) that supported OGG and OGG playback drained the battery noticeably faster than MP3 playback. Here's to hoping they got that part right this time.

Re:Getting it right the second time!

[jmv]

there is test code, but I didn't see sample code explicitly.

Well, we have code snippets for the encoder and the decoder. 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.

Re:Getting it right the second time!

[bill_mcgonigle]

OGG playback drained the battery noticeably faster than MP3 playback

there were a few of those that did MP3 on an ASIC and OGG on the CPU (which can't ever compete)

Re:Getting it right the second time!

[jones_supa]

Actually, when the developers show up in an article's comments, it's awesome.

Re:Getting it right the second time!

[sjames]

I used both Vorbis and MP3 codecs in CPU on embedded hardware and Vorbis was definitely more demanding.

Re:Getting it right the second time!

[sjames]

Vorbis is also a bigger pain to stream. Unlike Opus or MP3, it requires several setup packets at the start of the stream. You can not just start decoding mid stream, you at least need those 3 header packets first.

One Codec

[Saija]

One Codec to Rule Them All.

Re:We already have that: FLAC

[Desler]

You realize this is for low-latency, real-time applications, right? FLAC would be terrible in that arena.

Nice

[puddingebola]

A nice way to honor Opus the penguin.

No no no

[lytles]

"one codec to *stream* them all"

Some indications that it's not "Fully Free" ...yet

[smoothnorman]

none other than Bruce Perens (Open Source champion) points us to these: https://datatracker.ietf.org/ipr/1520/ https://datatracker.ietf.org/ipr/1741/ wherein we learn that Opus is "possible royalty/fee". this is not consistent with "Fully Free" to any patent troll waiting for broad adoption before jumping.

It fills a needed niche

[pavon]

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.

...and it switches modes seamlessly

[Anonymous Coward]

http://www.opus-codec.org/

Another great feature for streaming and Real Time Comms use is that it can seamlessly switch modes, channel count, bitrates, frame sizes and turn forward error correction on or off while it's playing, without glitches and without any out-of-band signalling. So if your link quality changes due to network traffic or other conditions, you can adjust to make the best of what you have. This could also be awesome for podcasts and radio shows with various types of content - e.g. super-wideband mono speech and high quality stereo music themes, stings and clips can all be part of the same stream or .opus file.

Sounds amazing to me at 64 kbps, confirmed by hydrogenaudio double-blind public listening tests (this mode was called CELT, not OPUS at the time) and google's formal testing. No wonder it's been voted for Mandatory To Implement status in WebRTC.

Re:What about APT-X

[jmv]

Last I checked, APT-X was not lossless (you can't be lossless and guarantee a compression ratio). Also, the only time I saw a comparison between APT-X and Opus, Opus was actually winning hands down. APT-X claims compression ratios of 4:1 (so 384 kb/s for 48 kHz stereo). Opus is already transparent long before that. I've never had anyone telling us he could hear any kind of artefact whatsoever above 200 kb/s VBR). Usually, 128 kb/s (12:1) is transparent for the vast majority of content and listeners (yes, there are a few exceptions at that rate).

Re:We already have that: FLAC

[fa2k]

Sorry, didn't look at the graph. This looks like a great development indeed, for things like VoIP and video streaming.

Re:And in other news

[epyT-R]

You mean MP3 is about as standard as it gets (for lossy anyway).

Re:Oh boy!

[epyT-R]

AAC is not lossless nor is it a video codec.

Re:Some indications that it's not "Fully Free" ...

[Anonymous Coward]

Those patents are openly declared as freely licensed and open-source compatible. See http://www.opus-codec.org/license/

Codec latency, not network latency

[cbhacking]

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.

Fantastic

[PopeRatzo]

OSS is wonderful.

Re:Oh boy!

[Lumpy]

Pffft, you say ordinary diamonds. real audiophiles only listen to BLUE diamonds that were polished on the thighs of virgins.

What??

[jensend]

"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 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:What??

[Anonymous Coward]

"Shine" is a really funny word for what HE-AAC sounds like at 16-24kbps. You can't polish a turd.

Actually the Mythbusters just busted this one. You can, in fact, polish a turd.

Re:What??

[GuruBuckaroo]

You can't polish a turd.

You obviously don't watch Mythbusters.

Re:What??

[russotto]

Actually the Mythbusters just busted this one. You can, in fact, polish a turd.

I didn't need Mythbusters to know about coprolites.

Re:We already have that: FLAC

[Lumpy]

"It's 2012, we have the bandwidth and storage to go to lossless."

maybe in your fancy country there in europe and its 100Mbps to the home. But the united states is a 3rd world country when internet bandwidth is concerned.. Most americans are lucky to get 5mbps with low latency.

Re:Some indications that it's not "Fully Free" ...

[smoothnorman]

Did Qualcomm Inc and Huawei Technologies Co.,Ltd (the putative patent holders) sign off on that statement?

Not Opus for that

[Bruce Perens]

Use Codec2 for that. It just got a quality upgrade recently, so if you have tried it before, check the latest source out of git and try again.

Re:Not Opus for that

[Guspaz]

Indeed, it's quite impressive. Useful and completely intelligible speech at 1200 bits per second is amazing. That's rapidly approaching the point where the language content of the data is approaching the storage density of text. You can probably say "The quick brown fox jumped over the lazy dog." in two seconds or so. That's 45 bytes, while codec2 would require only about 300 bytes to record my voice reading the sentence. The fact that that's well under an under of magnitude blows my mind.

Re:Not Opus for that

[Bruce Perens]

You can encode a few words in a tweet on twitter. More if you do UTF-8 tricks.

Re:Oh boy!

[mug funky]

suck it up, deafie!

you can put subtitles in the ogg container too, you know :)

Re:Some indications that it's not "Fully Free" ...

[Bruce Perens]

The developers are adamant that the patents claimed by Qualcom and Huawei don't apply to their code. But at the moment, those two companies are claiming their patents could apply, and are asking for RAND terms with possible royalties.

I asked Qualcom if they'd consider changing their declaration to royalty-free. I don't know anyone at Huawei.

Re:Some indications that it's not "Fully Free" ...

[smoothnorman]

Thank you for being such a good watchman. We really don't need another "gif" situation. Can you provide a dumbed-down explanation of what "RAND terms" are? (i'm -guessing- they aren't intrinsically random ;)

Re:Some indications that it's not "Fully Free" ...

[ThatsMyNick]

Mod UP! This deserves discussion.

Re:Only one real question

[ThatsMyNick]

How can it be real question when you already know the answer? No. But would it benefit them if they switched? Absolutely.

Gah. No thats wrong!

[Anonymous Coward]

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:Gah. No thats wrong!

[plover]

So I was trying to figure out if SILK would permit tying streams together, or if it provides any kind of synchronization with an external time source. All I can really find is a section on clock drift, and using tools like OPUS_GET_PITCH() to figure out how far the drift is. And there's a section on stuffing multiple frames (up to 48) into a CBR Code 3 packet. But it doesn't indicate anything about how those frames would be related.

Which is too bad, because it really does limit the applications. Without sync, how could Opus streams be used for the audio tracks on a video?

All I can think is that I'm really missing something fundamental here. They had to have considered these other applications, didn't they?

Re:Some indications that it's not "Fully Free" ...

[terpri]

RAND = reasonable and non-discriminatory

Re:Some indications that it's not "Fully Free" ...

[Bruce Perens]

That means potentially including royalties, and there is no real definition of what is "reasonable" and "non-discriminatory". In general the presence of royalties discriminates against Open Source completely.

Re:We already have that: FLAC

[Gaygirlie]

It's 2012, we have the bandwidth and storage to go to lossless.

Do tell us when you come back to the real world where storage ain't infinite and 256kbps bandwidth is still common.

Useless

[Anonymous Coward]

Flac is loosless, so it won't dissapear

If Flac won't disapear(sic), then it is loseless, not loosless.

(Ba-dump!)

FLAC, as in storage space is cheap, why degrade??

[anomaly65]

Ok, until the current generation of "bud earphone users" have gone deaf before age 40 (or at least significantly damaged hearing), there's a HUGE difference in lossless formats over ANY compression. And being able to reconstitute a duplicate of the original medium is a nice side bonus and makes for an easy to use backup solution for a large "legacy" collection of those smallish shiny discs, particularly if you've copied a damaged original with a temporary scratch filler (i.e. furniture polish, lemon fresh even!)

I was lucky enough to hunt down a [JVC] car audio head unit that reads (there's no real "decode" other than deflate and D-to-A) FLAC and everyone is amazed at the difference. Side by side, no comparison, even with my own self ripped high bit rate titles.

Spanish Inquisition

[loshwomp]

No one expected the Spanish Inquisition to have a hand in this.

From TFA:

Amongst its weaponry are such diverse elements as:

        Fearfully low latency: Frame sizes from 2.5 ms to 60 ms
        Surprising voice and music quality (it beats all other comers across its operating range, including Vorbis and AAC)
        Ruthless bitrate efficiency from 6 kb/s to 512 kb/s

ugh not another one

[Osgeld]

my phone doesn't like certain MP3's, ogg's existence is non, I don't want to be tied in to a media player like windows or apple, and here's another option that's promising me the universe, but has no support

in the year 2012 I hear there's going to be terabytes of storage for less than 100 bucks, cheap internet can download a ISO in a jiffy, and my 386 can play a wav file ... whats the point again? oh that's right, you want the entire history of recorded music on a 1x1 inch square cause anything else would make you choose.

Re:What about APT-X

[midgetpoker]

APT-X lossless does what it says on the tin (http://www.csr.com/products/61/aptx-lossless)

Re:We already have that: FLAC

[SRChiP]

maybe in your fancy country there in europe and its 100Mbps to the home. But the united states is a 3rd world country when internet bandwidth is concerned.. Most americans are lucky to get 5mbps with low latency.

5mbps is 3rd world? Then maybe I'm living in 4th (or 5th) world country. (Where 1mbps is 4th world)

Re

[kurkosdr]

Wait, wait... An audio codec? For audio, the only format that matters is MP3. The hardware support is massive, open source tools exist, and despite some vague mumbling from the FSF about "submarine patents", nobody has ever paid any royalties to use MP3 (because the patents have expired) or has been patent trolled in any way. Sure, it's not as efficient as AAC or this new Opus thing, but it's "good enough". IMO it may be too late even for a new video codec. MKV and MP4 (these two use the same mpeg4 avc codec) are spreading fast, and WebM barely has time to crack itself in.

Re:Oh boy!

[guyniraxn]

This should be modded funny, if anything. It is a description of hipsters calling themselves audiophiles. Real audiophiles embrace digital technology but are also skeptical of $100 stereo cables and other fancy sounding junk. Check out the Hydrogen Audio forums and The Audio Critic

lost in the noise floor

[epine]

Lost in the noise floor here is that Opus pretty much destroys the premise that good audio compression requires a psycho-acoustic model. These are hard to develop and limit participation.

In my own tests with Opus with my own voice dictation, I was pretty happy with Opus at its highest compression ratio.

It's pretty ridiculous to think that Opus should also have tackled lossless and extreme voice compression (codec2 territory). You people, please turn in your bignum libraries on the way out (or would you rather ditch your IEEE 754?)

Lossless is a different game and extreme voice compression is still a work in progress (I predict this can go a lot further yet, ending up as almost a MIDI file for the human larynx with a compression layer on top that models typical speech production--this may or may not be language neutral).

Opus covers everything?!?

[morgauxo]

"Opus covers basically the entire audio-coding application space"

Maybe I didn't look hard enough but I didn't see anything about how well it handles getting some of it's data corrupted. I only see comparisons of how it works at different bitrates. This is important for radio applications as there will always be interference and some percentage of the received bits will be wrong. That is why for example we don't see Amateur Radio operators using Speex. If this truly covers everything then we don't need codec2 http://codec2.org/ but from what I see it just sounds like a new ogg vorbis which is useful through a wider range of bitrates.