Forgot your password?
typodupeerror
Software News Technology

Opus — the Codec To End All Codecs 327

Posted by Soulskill
from the sounds-like-work dept.
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."
This discussion has been archived. No new comments can be posted.

Opus — the Codec To End All Codecs

Comments Filter:
  • Obligatory (Score:4, Funny)

    by Anonymous Coward on Tuesday September 11, 2012 @05:07PM (#41306161)

    Obligatory. [xkcd.com]

    • by plover (150551) * on Tuesday September 11, 2012 @05:09PM (#41306193) Homepage Journal

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

    • Re: (Score:3, Insightful)

      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 (Score:5, Informative)

        by jmv (93421) on Tuesday September 11, 2012 @06:26PM (#41306925) Homepage

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

        • by Smallpond (221300)

          Were they blind tests?

        • 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 (Score:4, Informative)

            by walshy007 (906710) on Wednesday September 12, 2012 @12:28AM (#41309357)

            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.

          • by Bengie (1121981)
            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 (Score:5, Interesting)

        by Teancum (67324) <robert_horning@n ... minus physicist> on Tuesday September 11, 2012 @06:36PM (#41307009) Homepage Journal

        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 (Score:5, Insightful)

          by Lumpy (12016) on Tuesday September 11, 2012 @06:53PM (#41307157) Homepage

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

          • By Apple's codec I think you mean AAC [wikipedia.org] 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 (Score:4, Informative)

            by hobarrera (2008506) on Tuesday September 11, 2012 @09:36PM (#41308237) Homepage

            I can play ogg on any of the music-playing devices I have access to. My main music library is ogg. What are you talking about "5 devices"!?

          • Re:Obligatory (Score:4, Informative)

            by FireFury03 (653718) <`slashdot' `at' `nexusuk.org'> on Wednesday September 12, 2012 @03:05AM (#41310045) Homepage

            Ogg? 5 devices.

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

        • by cpu6502 (1960974)

          >>>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 (Score:4, Interesting)

          by hobarrera (2008506) on Tuesday September 11, 2012 @09:35PM (#41308229) Homepage

          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.

          • by Lennie (16154)

            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

        • Re: (Score:3, Insightful)

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

        • 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

    • Re:Obligatory (Score:4, Interesting)

      by hobarrera (2008506) on Tuesday September 11, 2012 @09:29PM (#41308181) Homepage

      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)

  • by ThatsMyNick (2004126) on Tuesday September 11, 2012 @05:07PM (#41306167)

    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.

    • by Eponymous Hero (2090636) on Tuesday September 11, 2012 @05:10PM (#41306203)
      loseless? your fat fingers are consistent at least.
    • Re: (Score:2, Interesting)

      by Anonymous Coward

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

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

      • by Intropy (2009018)

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

    • by plover (150551) * on Tuesday September 11, 2012 @05:25PM (#41306341) Homepage Journal

      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.

      • by Volanin (935080) on Tuesday September 11, 2012 @05:32PM (#41306429)

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

        • by Anonymous Coward on Tuesday September 11, 2012 @06:02PM (#41306713)

          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: (Score:2, Informative)

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

          • by jmv (93421) on Tuesday September 11, 2012 @06:15PM (#41306815) Homepage

            Support for more than 2 channels is done at the container level, although the Opus format already has the framing planned. See http://tools.ietf.org/html/draft-terriberry-oggopus [ietf.org] for more details.

            • Gah. No thats wrong! (Score:3, Informative)

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

        • by Metabolife (961249) on Tuesday September 11, 2012 @11:52PM (#41309173)

          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: (Score:3, Interesting)

          by Carewolf (581105)

          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.

    • by Tablizer (95088)

      I wonder why they left out lossless encoding.

      Because the specification was recorded on a lossy medium.

    • by iluvcapra (782887)

      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: (Score:3, Informative)

        by iluvcapra (782887)

        (comment withdrawn)

      • by jensend (71114) on Tuesday September 11, 2012 @06:02PM (#41306709)

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

      • by jmv (93421) on Tuesday September 11, 2012 @06:19PM (#41306851) Homepage

        the standard does not specify a recommended container format

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

      • by sjames (1099)

        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.

    • by tlhIngan (30335)

      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 somethi

      • by jensend (71114) on Tuesday September 11, 2012 @06:20PM (#41306863)

        Testing that things work has been done for all kinds of bitrates (512kbps per stream * multiple streams in a surround encoding). It's just that Opus is transparent to most listeners on most samples before you hit 128kbps for stereo. It's extremely hard to do a worthwhile listening test when only a few listeners can tell even a few of the samples from the original.

        Some people at hydrogenaudio.org have reported problem samples which they were able to ABX from the original at up to 160kbps. I haven't personally found any stereo samples I can reliably ABX from the original at above 80kbps.

        Of course lossless has its place. You don't want to be doing a lot of decoding lossy files, editing them, and then re-encoding, since you'll get . For similar reasons, rather than transcoding from one lossy format to another it makes sense to keep a lossless master and encode to lossy formats from that. But for listening purposes, Opus is quite capable of being perceptually transparent. [wikipedia.org]

      • by jmv (93421) on Tuesday September 11, 2012 @06:23PM (#41306891) Homepage

        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: (Score:3, Interesting)

          by Em Adespoton (792954)

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

          • by jmv (93421) on Tuesday September 11, 2012 @07:21PM (#41307383) Homepage

            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.

    • by sconeu (64226) on Tuesday September 11, 2012 @06:34PM (#41306997) Homepage Journal

      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: (Score:3, Funny)

        by ignavus (213578)

        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: (Score:3, Informative)

      by Kaz Kylheku (1484)

      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.

      • by ZorinLynx (31751) on Tuesday September 11, 2012 @07:06PM (#41307249) Homepage

        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.

  • Opus?!? (Score:5, Funny)

    by ackthpt (218170) on Tuesday September 11, 2012 @05:15PM (#41306269) Homepage Journal

    What's wrong with Bill the Cat?

  • Patents (Score:5, Insightful)

    by K. S. Kyosuke (729550) on Tuesday September 11, 2012 @05:20PM (#41306305)
    Cue MPEG-LA calling for a patent portfolio to be created and licensed for hard cash, under their gracious auspices, of course.
    • by ackthpt (218170)

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

    • It's a trap! [opus-codec.org] A prenup and a restraining order have more teeth.

  • by Guspaz (556486) on Tuesday September 11, 2012 @05:30PM (#41306405)

    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. (Score:5, Interesting)

      by jmv (93421) on Tuesday September 11, 2012 @06:13PM (#41306791) Homepage

      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. (Score:4, Informative)

      by femto (459605) on Tuesday September 11, 2012 @06:37PM (#41307017) Homepage
      For low bit rate voice (down to 1400bit/s) you can use codec2 [codec2.org].
    • What?? (Score:4, Informative)

      by jensend (71114) on Tuesday September 11, 2012 @06:56PM (#41307187)

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

      As far as AMR-WB/NB, you have to get down to 8kbps before AMR-WB sounds measurably better, and you have to get down to 6kbps before AMR-NB sounds better. Opus is tied with AMR-WB at 12kbps and better at 16kbps, and it's tied with AMR-NB at 8kbps and significantly better at 12 or above. Look at the studies linked from the comparison page [opus-codec.org] if you want more details, keeping in mind that the Opus encoder has continued to improve in the year since those studies were done.

  • It's awesome (Score:5, Interesting)

    by LSD-OBS (183415) on Tuesday September 11, 2012 @05:33PM (#41306433)

    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.

  • by jensend (71114) on Tuesday September 11, 2012 @05:37PM (#41306481)

    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.

  • by bill_mcgonigle (4333) * on Tuesday September 11, 2012 @06:02PM (#41306707) Homepage Journal

    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 [slashdot.org] 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!

    • by pavon (30274) on Tuesday September 11, 2012 @06:28PM (#41306941)

      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.

      • apparently it's CPU/power efficient [slashdot.org] 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.

    • by jmv (93421) on Tuesday September 11, 2012 @06:49PM (#41307125) Homepage

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

      Well, we have code snippets for the encoder [xiph.org] and the decoder [xiph.org]. Otherwise, there's always the code for opus_demo.c and opusenc.c/opusdec.c. Let me know what you think is missing and we can try improving that.

  • One Codec to Rule Them All.
  • A nice way to honor Opus the penguin.
  • by smoothnorman (1670542) on Tuesday September 11, 2012 @06:28PM (#41306937)
    none other than Bruce Perens (Open Source champion) points us to these: https://datatracker.ietf.org/ipr/1520/ [ietf.org] https://datatracker.ietf.org/ipr/1741/ [ietf.org] 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.
  • by morgauxo (974071) on Wednesday September 12, 2012 @12:51PM (#41314389)
    "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/ [codec2.org] but from what I see it just sounds like a new ogg vorbis which is useful through a wider range of bitrates.

Hackers of the world, unite!

Working...