Hacker News new | comments | ask | show | jobs | submit login
Firefox Beta 15 supports the new Opus audio format (hacks.mozilla.org)
159 points by kinetik on July 20, 2012 | hide | past | web | favorite | 106 comments



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


Doesn't Apple's lame excuse of unknown patents apply to all technologies?


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


If 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-Dec...


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


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


I think Microsoft and Apple are more into known quantities and what is implemented in hardware.


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

Microsoft(and probably Apple too) pays more than what it gets from the pool, so that doesn't make sense.


It has nothing to do with that.

And everything to do with VP8/WebM being a proprietary, non standard at the time that the world consolidated on H.264. That and the fact that H.264 had hardware support when the iPods and Zunes were taking off.


You keep using this word "proprietary". I don't think it means what you think it means.

How is a codec I can download in complete source form and use in any way I like without licensing anything or answering to anybody "proprietary"?

The fact that we live in a world full of patent trolls that will sue you for tying your shoelaces doesn't make every codebase without explicit corporate patent indemnity "proprietary".


Proprietary: "something that is used, produced, or marketed under exclusive legal right of the inventor or maker."

The WebM trademarks and copyright are owned by Google.

Yes you have a license to use WebM as it is today. But Google can make the next version closed source and you wouldn't be able to do anything about it. And of course companies are going to use Google's 'official' WebM regardless if it is open or closed source leaving you screwed.


Wow you're really reaching here now, aren't you? The bitstream format and software are licensed under a Creative Commons Attribution License and the BSD license, respectively.

By your definition anything not in the public domain is proprietary.


Let's get another definition. This one is from wikipedia: Proprietary software is computer software licensed under exclusive legal right of the copyright holder. The licensee is given the right to use the software under certain conditions, while restricted from other uses, such as modification, further distribution, or reverse engineering.

As far as I am aware of, any user of WebM are NOT restricted from modification, further distribution, or reverse engineering. The beauty of the current licencing is that it can't be revoked; it is already free. Google can develop future versions and lock it down (suicidal move, though), but as it is the community has its hands on it.


So to be clear, you admit that WebM isn't proprietary, but future versions could be? That's true of every open source project on the planet, that's how copyright law works.


Microsoft actually helped with the development of Opus according to the article. :)


Not really. Opus incorporates the Skype codec, Microsoft has their name on it by virtue of being the new owner of Skype.


I remember when MS participated in MPEG-4 development and then fought MPEG-4 for years.


And now getting sued by Google over FRAND patents defined in the H.264 standard.


Only in the same way you could say Google helped "build" Skype, because Skype uses the VP8 codec.


Why exactly couldn't Apple use the very same lame excuse it used against WebM and pro-h.264?


Because it'll show that they aren't supportive of Web standards and they'll look like complete fools - bad PR for them. That's why they were sabotaging any attempts to make other open codecs (like VP8) an official standard for HTML5 video. It's much harder for them to explain why they oppose official Web standards, than just to say they aren't supporting one of the optional codecs.


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


Google has a big NIH conflict of interest since they bought GIPS. "On the audio side, we will initially support iSAC, iLBC, G.711, and DTMF, with iSAC being the default. It is a royalty free wideband codec optimized for speech, open sourced at webrtc.org." http://blog.chromium.org/2012/04/chromes-webrtc-roadmap.html It looks like somebody volunteered to add Opus to Chrome and was met with silence: https://groups.google.com/forum/?fromgroups#!topic/discuss-w...

Mozilla says "Audio codecs planned: G.711 & Opus. (Although royalty/license-free, we have no plans to support iLBC, iSAC and G.722)", so as it stands Firefox and Chrome could only interop with G.711 (aka uncompressed). https://wiki.mozilla.org/Platform/Features/WebRTC


Very interesting. That Google Group you link to is very busy with responses to almost all threads, but the one you link to, the May 9 offer to add Opus to Chrome, was met by the sound of crickets.

If IE, Firefox, Opera, and Chrome support it, there might be enough leverage on Apple to add it to Safari (Mac, iOS, maybe iPod), too. But without Chrome, Apple has the political cover to claim that "nobody uses it," so they can kill it.


So which is better, iSAC or Opus?


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 iLBC, not iSAC)

So it's likely that Opus is way better. It can certainly scale to much higher quality than iSAC can just by the format alone.

Qualitywise, Opus outperforms the state-of-the-art high-latency codec at music encoding while being a low latency music & speech codec itself. The only case where another codec outperforms Opus anywhere seems to be AMR, when encoding speech at very low bitrates (<= 6-12kbps). But AMR also has higher delay.

You can read the summary here: http://tools.ietf.org/html/draft-ietf-codec-results-01


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.


Do you have samples where AAC@256kbps outperforms Opus@256kbps? That'd be very interesting...


Well, I suspect they talked to their legal department which _might_ have reasoned like this (IANAL, btw):

"Opus is a hybrid codec that internally uses both, SILK and Celt.

SILK was created by Skype (now Microsoft) and its patent license includes this gem: '5.1 Skype may terminate this License Agreement and any rights granted hereunder in the event that you or any of your Affiliates (i) materially breaches any of the terms and conditions of this Agreement; or (ii) asserts any patent or patent rights against Skype, its Affiliates, or its or their successors or assigns.'

So lets assume Motorola (owned by Google) tries to (counter)sue MS over some Android stuff: Suddenly the patent grant given by Skype becomes invalid and Google might have to remove Opus from Chrome. If it's popular by that time, this is a serious competitive disadvantage.

So better not help making it popular in the first place. "


Skype/MS should just make it fully open source then, for the betterment of the web, instead of using it for potential silly legal fights in the future.


Google apparently participated in the listening tests and concluded Opus outperformed the GIPS codecs they had just bought for 68 million USD, sometimes by wide margins.

I guess they're still hurting over that? :)


Exactly that Apple Island with their industry standard H.264 and AAC files.

And Google with their proprietary WebM.


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


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


Is there any open-source, royalty-free technology you can think of that comes with a legal indemnity against patent lawsuits?


Many providers of Linux and Java products indemnify their users e.g. RedHat, Novell.


s/users/customers/ ?


WebM is not proprietary. It's open source. You can find it here:

http://www.webmproject.org/


It IS proprietary.

Google owns WebM and unilaterally makes the decisions about the direction of the format. H.264 is a standard and driven by a standards committee and process comprising numerous companies.


> It IS proprietary.

Also, war is peace, freedom is slavery, and innocence is strength!


The code may be open source but the format/spec is 100% controlled by Google. Forking the code won't help you change the direction of format development. If anyone besides Google wants to make changes, they'd have to fork the entire spec under a different standards body.


As you would with any standard. If h.264 were open source you couldn't fork it and have it work with existing h.264 devices. It would be a new standard.


Also we should point out that Google should NEVER be trusted.

Their disgraceful behaviour in blackmailing Microsoft over H.264 FRAND patents is of huge concern to anyone who cares about standards. Companies should be encouraged to get together and define industry standards with fair royalty rates. When that happens we ALL win. Clearly the ITC/EU agree.

Hopefully Google will see the error of its ways and change course.


Seriously? Google has owned Motorola Mobility for fewer than two months[0]. And in any case, though it seldom matters to people insistent on seeing the Android manufacturers in a bad light, Microsoft started this war by demanding licensing fees for ridiculous patents, like this one, for "Generating meeting requests and group scheduling from a mobile device"[1].

If you want to talk about bad guys in this mess, it's the companies who ended the détente by suing their competitors. That would be Microsoft and Apple. Asking companies like Motorola, HTC and Samsung to tie their hands behind their backs while Apple and Microsoft shake them down (or try to ban their products) is lunacy.

We need patent sanity in this country. But in the mean time, companies who are attacked have every right to defend themselves by any legal means they have available.

[0] http://en.wikipedia.org/wiki/Motorola_Mobility [1] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sec...


I fail to see how it matters how long Google has owned Motorola. They are the ones making the decisions.

And this isn't just about Motorola and Microsoft. This is about the principle of ALL contributors to a standard licensing their patents in a fair way. Regardless of whether they are being sued or not or how 'nice' the counter party is.

Do you not understand that if Motorola gets away with this then it will set in a place a precedent for all H.264 patent holders to go after any licensees ? You may not understand the implication but the ITC/EU clearly do.


Google did not own Motorola Mobility when the FRAND stuff went down (in February). If you can't see how that's relevant then I guess you probably can't see much at all.


Propaganda is always easier if you fail to mention all the facts.

Like the fact that it was Motorola that used their patents to negotiate with Microsoft long before it was acquired by Google. Or the fact that Motorola did it only after Microsoft blackmailed Motorola, using your rhetoric, with their patent portfolio in order to destroy Android not by making better products but by patent bullying.


It is ludicrous for one patent holder of the H.264 patent pool to demand patent royalty rates far beyond the license rate for the entire pool.

It was NEVER a negotiation.


Certainly good reason to hop onto a free standard.


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


Ogg is a container format. The Opus support in Firefox is Opus inside the Ogg container. You probably mean "why isn't Vorbis good enough". Even the article has this error when it says that Opus compression is better than Ogg. They mean Vorbis there presumably.


Unfortunately, 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.


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


Here are the terms of the license, I think: 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.


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 regarding the Java and C# licenses, which also have similar clauses for similar reasons. The motivation for them is reasonable, but the details can be tricky.

> (And if Skype ever infringes any of your patents, you can't sue them without losing the rights to Opus.)

Personally I think that's fine. If you want to engage in a full-on patent war, you should not benefit from a patent license like this.

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

If a single bug makes you liable, obviously it is unfair, etc, but that's exactly where the details of the license come into play - I am not a lawyer, so I have no idea if the terms here are reasonable or not.


>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 algorithms in some parts? No. I cannot take the parts of Opus which fall under Skype/Microsofts patents and use them in derivatives. This means that both the implementation as well as the standard are free and open on paper only. In reality, I am denied freedom number 3 - the right to distribute modified implementations.

Take note that you could just solve this with a trademark on Opus (which probably already exists). Many large FLOSS projects do that. Firefox, for example - derivatives are not allowed to call themselves "Firefox" (which I think is one of the very few valid uses of trademarks).

If Skype/Microsoft would be actually interested in a free and open standard, they would have pledged to let go of these patents. I don't know if you can just say "this patent is now invalid", but if not, they could hand them over to the standard body, which could then assure that everybody is allowed to use these patents until they expire.

>Personally I think that's fine. If you want to engage in a full-on patent war, you should not benefit from a patent license like this.

I find it quite funny that people already implictly assume that if someone starts a patent infringement lawsuit, they are in for patent war. Please tell me again why we haven't got rid of patents yet?


>If a single bug makes you liable, obviously it is unfair, etc, but that's exactly where the details of the license come into play - I am not a lawyer, so I have no idea if the terms here are reasonable or not.

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


You make a good point, I agree that even with royalty-free licenses like these the use of the technology is not completely free.


in some ways, a perpetual unrestricted license is better than an unpatented algorithm. The big excuse for not adopting webm was "uncertainty" about the patent situation. If skype has the patents and is giving free licenses, there isn't any uncertainty here, you know that microsoft has no basis to ever sue.


This is true and is one reason that free things these days are given "licenses" instead of simply being declared by their makers to be in the public domain. The public domain isn't what it used to be.


It's impossible to declare a work under the public domain in the USA. A creative work reaches the public domain only when its copyright expires, or if it's a government work.

Read up on the rationale behind the CC0 license for more information:

https://creativecommons.org/about/cc0


To some (significant) degree, but you never know that no one else has patents on a technology. That's exactly what is so messed up with software patents.


On any specific technology, you absolutely can know that no one else has patents on it. That is the responsibility of the patent office: to grant exclusive rights to an 'invention'. you cannot be held liable for infringement of anything you have a license for.

In this case though, Microsoft only has patents on part of the algorithm, so it is theoretically possible that other parts of the algorithm are covered by other patents.


It's rare, but I remember reading that USPTO has mistakenly issued conflicting patents. Legally, any publication is enough to bar others' patents, they're just not good at finding anything in the software literature, so having your own patent sort of rubs examiners' noses in it.


But the point is that if the USTPO issues conflicting patents, it is them that is liable instead of you. If you have a license, you're golden.


> On any specific technology, you absolutely can know that no one else has patents on it. That is the responsibility of the patent office: to grant exclusive rights to an 'invention'.

The problem though is that anything complex like a video or audio codec can constitute many "inventions" from the USPTO's point of view. H.264 has many patents on it, for example. Again, this is one of the big problems with the current patent system.

So in practical terms you can never use a codec with the knowledge that no one else has patents on it.


And in certain situations it's better not to know, because knowingly infringing patents can result in significantly higher monetary penalties than unknowingly infringing them.


There is also the question of whether the statements from Skype about patents are still true given their purchase by Microsoft.


free_enough + available > completely_free


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


(2010) Some discussion about CELT / Opus from the author of x264: http://pbox.ca/16cbg


Just checking, CELT & Opus are the same thing? Seems like they're saying that Opus is a merge of CELT & SILK


Yes, 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.


And Holy Fxxk that is some awesome Hardcore Video and Audio hacker discussion. Great Stuff!!!!


When they say perceptually lossless, by whose perception do they mean? Some definition of the average human?


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


Not a scientific test by any means, but for a quick and dirty take on the matter, here's the Great MP3 Bitrate Experiment courtesy of Coding Horror: http://www.codinghorror.com/blog/2012/06/concluding-the-grea...


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


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


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


Worth noting it is 'v2', which is a specific setting with a specific encoder (lame) that creates a variable bitrate file which averages around 192kbps.

That is very different to just setting itunes to 192 and expecting 'perceptually lossless'.


Those listening test results are impressive. I wonder how it performs at higher bitrates.


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.


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


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


There are examples here which worked out-of-the-box for me in Chrome:

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.


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.


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


Great, when are they going to support FLAC instead of these formats nobody will ever use?


It may not be provided by the browser, but it is possible:

http://labs.official.fm/codecs/flac/


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


Very exciting if it can deliver on all of its claims, but noticeably absent is anything whatsoever about the patent status of the format.



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


So is Mozilla going to use VP8 combined with Opus in Firefox 15, instead of Vorbis, for "free" videos?


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


Opus is a (usually) lower bitrate codec for very low latency applications. In other words, a completely different sweet spot than Vorbis, AAC, etc.


It outperforms Vorbis and AAC even at their (high-latency) forte, though.


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?


Specifically, 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.


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




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: