7 ms·
Firefox Beta 15 supports the new Opus audio format
- simonster 14y agoThose listening test results are impressive. I wonder how it performs at higher bitrates.
- te_chris 14y agoIt said in the article that it was "percptually lossless" or similar. I'm very, very intrigued.
- marquis 14y agoThere are examples here which worked out-of-the-box for me in Chrome: http://www.octasic.com/en/tech/opus_audio_codec.php http://www.octasic.com/en/tech/opus_audio_codec.php In my listening opinion with very good isolated headphones: the music is very good but you can hear the drop-off of the highs in the vocal examples. It's good but not good enough for 'professional' use at the lower bitrates.
- gcp 14y agoIt's good but not good enough for 'professional' use at the lower bitrates. I have no idea what that is supposed to mean.
- marquis 14y agoAudio 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.
- gcp 14y agoMPEG2 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).
- marquis 14y agoThanks, that was what I was referencing. How well do you think Opus will compare to AAC?
- gcp 14y agoI already posted tests results elsewhere in this topic. It outperforms it at low bitrates. I suspect also at higher ones but once both codecs get imperceptible for most listeners (which is the case for AAC and Opus >128kbps) it's very hard to get statistically significant results.
- polshaw 14y agoThey 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.
- nullc 14y agoMeasuring the point where something becomes perceptually lossless is quite difficult because, by definition, you're measuring at the bounds of perceptibility. In terms of simple objective measures (e.g. the masking weighed SNR, http://people.xiph.org/~greg/celt/NMR.v.c.l.png 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.
- cageface 14y agoLossy audio compression over about 160kbits is a boring subject these days because for the vast majority of users and samples it's more than good enough. I'd imagine this would have to be at least competitive with mp3/aac/ogg at those rates.
- shmerl 14y agoLuckily it's going to be W3C standard, and Apple and MS won't be able to use their lame excuses to avoid implementing it in their browsers, like they did for Vorbis, VP8 and etc.
- wmf 14y agoDoesn't Apple's lame excuse of unknown patents apply to all technologies?
- ajasmin 14y agoPotentially yes. But Microsoft and Apple not supporting VP8 & WebM probably has more to do with these companies being part of MPEG LA (a firm which sell licenses for H.264 related patents).
- wmf 14y agoIf Apple was opposed to Vorbis, I imagine they would be equally opposed to any new audio codec. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-December/013154.html http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2007-Dec...
- alayne 14y agoThat seems like a leap. Ogg codecs were always questionable to me because they are owned by xiph.org, rather than some other more widely accepted standards body.
- metajack 14y agoWe tried to get IETF and W3C interested. They barely talked to us. The most we could do was a Vorbis over RTP draft that I wrote. The next best option was to incorporate as a 501c3 and run our own standards body, similar to the XSF in the XMPP world. The times have changed though, and the IETF is now receptive to this type of work (although it didn't happen without a political battle). Note that many of the Opus contributors are Xiph.org contributors as well.
- tobylane 14y agoI went into the article thinking why isn't OGG good enough, and the xkcd joke about 15 different standards. I left pleased about this new standard (from an advert, any downsides?) but need some patent assurances. If Mozilla are happy will everyone be?
- slowpoke 14y agoUnfortunately, according to Wikipedia, Skype holds software patents on parts of the algorithm. Even though they said they'd make them avaiable royalty-free, this still means it isn't completely free.
- stcredzero 14y agofree_enough + available > completely_free
- slowpoke 14y agoI vehemently disagree. This is supposed to become an open standard. Open standards must, in my opinion, be completely free. No compromises. No exceptions. No footnotes. No patent bullshit.
- azakai 14y agoIn what way is using a technology not free, if you are given a royalty-free license to use the patents on it? (Honest question, I don't know what you mean here.)
- teraflop 14y agoHere are the terms of the license, I think: http://datatracker.ietf.org/ipr/1602/ http://datatracker.ietf.org/ipr/1602/ Notice that permission is only given for implementations that comply with the specification. (And if Skype ever infringes any of your patents, you can't sue them without losing the rights to Opus.) Whether or not you agree with Skype's moral right to its patents, this is clearly a limitation of developers' freedom. Imagine if HTTP were covered by this kind of patent: anyone could implement a client or server, but developing a backward-incompatible extension like SPDY would be off-limits. If you were to take the license terms literally, even releasing a buggy implementation that doesn't precisely follow all of the requirements of the spec would make you liable.
- mappu 14y ago(2010) Some discussion about CELT / Opus from the author of x264: http://pbox.ca/16cbg http://pbox.ca/16cbg
- soperj 14y agoJust checking, CELT & Opus are the same thing? Seems like they're saying that Opus is a merge of CELT & SILK
- skoob 14y agoYes, Opus is basically a merge of CELT and SILK. SILK is a speech codec developed by Skype whereas CELT is a general purpose audio codec developed by Xiph.org. Opus can use either of them (to encode speech or e.g. music, respectively) or it can use both codecs simultaneously for high-quality speech.
- ksec 14y agoAnd Holy Fxxk that is some awesome Hardcore Video and Audio hacker discussion. Great Stuff!!!!
- makmanalp 14y agoWhen they say perceptually lossless, by whose perception do they mean? Some definition of the average human?
- polshaw 14y agoMy somewhat educated take on that is that 'perceptually lossless' refers to quality at which the source cannot be reliably picked from the source/encode in any sort of test that would pass as scientific, possibly outside of a few very rare edge cases (sound samples, not people). This happens at lower bitrates than many people might imagine, IIRC v2 lame (~192kbps) has not been reliably identified, nor vorbis v6 (~160kbps). So their claim of 'perceptually lossless' at 256kbps is neither surprising or impressive. (it may be competitive/better at those high bitrates and they are just being conservative with the claims).
- makmanalp 14y agoSo if I'm getting this correctly, a computer test (not a person) has to look at two clips of audio and tell which is the source and which is encoded? I'm surprised that 192k is actually indistinguishable. I thought some humans could tell the difference there.
- pgeorgi 14y agoUsually it's double blinded ABX testing: A computer program gives you: Encoding A, encoding B, unknown encoding A or B. You have to choose if X is A, or X is B. One of the encodings will be "uncompressed" when testing if the format in question is perceptually lossless. Repeat that a couple hundred times with many different listeners using standardized samples and programs (doom9, an audiophile forum, does such runs every now and then), and you get a rather good idea on what's going on. As for the 192kbps: It also depends on the algorithms used. bladeenc or 8Hz-mp3 back then created 320kbps files where you can easily hear the difference. Current lame builds at 192kbps? not so much.
- cageface 14y agoNo a computer can trivially tell the difference. But most people can't distinguish a properly encoded mp3 from the original at 192kbits and often much lower than that.
- SiVal 14y agoWhere is Google in all this? They must surely be aware of all such IETF projects. I can understand why Apple wasn't mentioned (Apple Island is a world unto itself to the maximum extent possible), but Google has usually pursued the opposite strategy. This seems like the sort of thing they would get behind unless there is some issue I'm unaware of, and it seems as though Mozilla would mention Google in this infomercial if they were backing it.
- taligent 14y agoExactly that Apple Island with their industry standard H.264 and AAC files. And Google with their proprietary WebM.
- kkowalczyk 14y agoYes, a completely open-sourced, royalty free and patent-free WebM is "proprietary". Patent-laden format for which you have to pay multi-million royalties is "industry standard".
- taligent 14y agoIt is not "patent-free". If it was I am sure Google would indemnify users from patent infringement lawsuits. Fact is that at least 12 organisations have already said that WebM infringes on their patents.
- haberman 14y agoVery exciting if it can deliver on all of its claims, but noticeably absent is anything whatsoever about the patent status of the format.
- wmf 14y agohttps://datatracker.ietf.org/ipr/search/?option=document_search&document_search=draft-ietf-codec-opus https://datatracker.ietf.org/ipr/search/?option=document_sea...
- nullc 14y agoThe IETF datatracker link is pretty useless. Pretty much anyone can make any claim they want there and there is no way to remove it. Its just a statement collector, not a review. Most of the results returned are against old versions of the specification, too.
- mtgx 14y agoSo is Mozilla going to use VP8 combined with Opus in Firefox 15, instead of Vorbis, for "free" videos?
- metajack 14y agoOpus is a (usually) lower bitrate codec for very low latency applications. In other words, a completely different sweet spot than Vorbis, AAC, etc.
- gcp 14y agoIt outperforms Vorbis and AAC even at their (high-latency) forte, though.
- shmerl 14y agoWhy not. They might propose using VP8 combined with Opus (not sure how it'll be called) for video. The problem however is in the same lack of support, since VP8 is still boycotted by Apple and MS so far.
- armitage 14y agoDamn it Firefox, you broke my pentadactyl!!
- 4ad 14y agoGreat, when are they going to support FLAC instead of these formats nobody will ever use?
- BHSPitMonkey 14y agoIt may not be provided by the browser, but it is possible: http://labs.official.fm/codecs/flac/ http://labs.official.fm/codecs/flac/
- 4ad 14y agoI'm curious how that works. It decodes the FLAC in JavaScript, but it still has to expose it in some format understood by the browser. To my limited knowledge there's no lossless encoding scheme supported by browsers, not even WAV PCM. /edit: spoken too soon WAV PCM is supported by WebKit, Gecko and Presto: http://en.wikipedia.org/wiki/HTML5_Audio#.3CAudio.3E_element http://en.wikipedia.org/wiki/HTML5_Audio#.3CAudio.3E_element
- sp332 14y agoI 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 http://pbox.ca/16cbg
- nullc 14y agoThats a conversation from two years ago... But whats scary about it?
- sp332 14y agoSpecifically, this: 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; is incomprehensible and basically unmaintainable. The variables are named badly and the control flow is not obvious.
- nullc 14y agoWhat maintenance are you looking to perform on it? Thats code from the inner loop of the algebraic codebook decoder. Its operation is explained by a 117 line long comment in the source, and by a page long description of a simplified algorithm in the spec. Beyond replacing it with an alternative implementation which would naturally have nothing in common there isn't much to maintain in it (and that code itself has been proven correct through exhaustive testing as well as the partially-exhaustive unit tests for it included with the codec). Most of the codec doesn't look like that. Though it's not all easy to read— e.g. a lot of the signal processing stuff is intermediated by macros so that it works for both fixed point and floating point. And if you don't like it then, by all means, write your own. Having more interoperable implementations would be great. Most formats don't give you a BSD licensed reference implementation. ::shrugs::