101–110 of 111 posts
So is Mozilla going to use VP8 combined with Opus in Firefox 15, instead of Vorbis, for "free" videos?
Earlier quoted context omitted.
It's good but not good enough for 'professional' use at the lower bitrates. I have no idea what that is supposed to mean.
Audio compression is generally not used for production audio (film sound, television etc), but on occasion they'll use MPEG2 for remote transmission. This is a lossy codec but sounds better than the example provided, albeit at 128kbps so I'd need to hear the Opus codec at 128kbps to compare.
Opus outperforms that greatly, but it's not going to outperform MPEG1 Layer 2 at 256kbps while only outputting 64kbps itself. (Will likely need >= 96kbps for that).
Earlier quoted context omitted.
Skype used the SILK part of Opus to replace iSAC quite a while ago. (SILK is in fact their second iteration of their own codec to improve upon/replace it) I couldn't find any direct comparison, it looks like the IETF standardization work didn't even consider it worthwhile comparing to iSAC as it was judged outdated and "being phased out". (For example, Google participated in the tests, but they only tested against iL…
Opus, A lot better, it is a rather strange beast that it nearly manage to outperform in every category. With a bit more tuning work for a year or two it could properly be on the same level with AAC @ 256Kbps.
Earlier quoted context omitted.
Audio compression is generally not used for production audio (film sound, television etc), but on occasion they'll use MPEG2 for remote transmission. This is a lossy codec but sounds better than the example provided, albeit at 128kbps so I'd need to hear the Opus codec at 128kbps to compare.
MPEG2 isn't an audio codec, it's a suite of standards. But based on my experience writing hardware encoders for this use case, you're talking about MPEG1 Layer 2 audio. Opus outperforms that greatly, but it's not going to outperform MPEG1 Layer 2 at 256kbps while only outputting 64kbps itself. (Will likely need >= 96kbps for that).
Earlier quoted context omitted.
It said in the article that it was "percptually lossless" or similar. I'm very, very intrigued.
They mention 256kbps in regards to that, at which point all of vorbis, aac and mp3 (lame) are 'perceptually lossless', so it wouldn't be much new. While it is hard to tell (because tests at higher bitrates don't really work out/ produce winners), it seems that any sonic advantage held is at the lower bitrate end.
In terms of simple objective measures (e.g. the masking weighed SNR, http://people.xiph.org/~greg/celt/NMR.v.c.l.png) Opus does better than Vorbis (and AAC) at high rates too. Between that and the overall better time domain performance, my _expectation_ is that Opus can become perceptually lossless at lower rates, but this is hard to validate.
Getting the lowest possible average perceptual lossless rate is also a product of the encoder having a good psymodel, and released opus encoders have pretty much no explicit psymodel at all (but still manage to be competitive). So this reduces the interest in doing a bunch of very difficulty listening tests to determine the exact perceptually-lossless points, since they'll likely go down with near term encoder improvements.
Very exciting if it can deliver on all of its claims, but noticeably absent is anything whatsoever about the patent status of the format.
https://datatracker.ietf.org/ipr/search/?option=document_sea...
Most of the results returned are against old versions of the specification, too.
Earlier quoted context omitted.
Thanks for the link. > Notice that permission is only given for implementations that comply with the specification. That's typical - otherwise, you could implement some almost arbitrary protocol but say it was this one (and use a small amount of it) and claim that you were shielded from Skype's patents. The patent license is just for this particular codec. Of course there are issues with this, it's been debated a lot…
>That's typical - otherwise, you could implement some almost arbitrary protocol but say it was this one (and use a small amount of it) and claim that you were shielded from Skype's patents. No, that's what standard bodies are for. No need for stupid patent licenses. Besides, this is exactly why this isn't free. Could I make a format based on Opus, but not conforming to the spec? Maybe because I had an idea for better…
Speaking as one of the authors of the spec here, this is very much not the intention. I personally believe a patent license should never be used to enforce standards compliance, and that's not the purpose of that term. Keep in mind, I don't think anyone involved in this standard wants to go around suing people, particularly those interested in implementing and deploying it! In addition to being a gigantic waste of time and money, it would kill the standard dead.
But we specifically included a conformance test to make it easy to know if you met the legal requirements, so you didn't have to trust us. At the request of the working group, this test was made so lax that we worried you could start deleting random lines of code (as an "optimization") and still manage to pass it (to combat this the test also displays a "quality" parameter which drops long before you get to the failure point, so implementors can start marketing that number if their competitors try this tactic, instead of being stuck in a race to the bottom).
Earlier quoted context omitted.
MPEG2 isn't an audio codec, it's a suite of standards. But based on my experience writing hardware encoders for this use case, you're talking about MPEG1 Layer 2 audio. Opus outperforms that greatly, but it's not going to outperform MPEG1 Layer 2 at 256kbps while only outputting 64kbps itself. (Will likely need >= 96kbps for that).
Thanks, that was what I was referencing. How well do you think Opus will compare to AAC?
I understand they were trying to finalize the spec and weren't worried too much about the individual encoder decisions, but check out some of the code at the bottom of this convo, it's scary http://pbox.ca/16cbg
I understand they were trying to finalize the spec and weren't worried too much about the individual encoder decisions, but check out some of the code at the bottom of this convo, it's scary http://pbox.ca/16cbg
Thats a conversation from two years ago... But whats scary about it?
p=_u[_k+1];
s=-(_i>=p);
_i-=p&s;
yj=_k;
p=_u[_k];
while(p>_i)p=_u[--_k];
_i-=p;
yj-=_k;