Slashdot Mirror
The Future of Ogg Vorbis
Brett writes "The author of MAD, the fixed point MP3 decoder comments on what is wrong with Ogg Vorbis, with a response from jack, one of the founders of the format.
"Ogg Vorbis may be the holy grail of patent-free audio compression, but there are some serious issues blocking its path to widespread acceptance. Unfortunately most of us are powerless to correct the situation; the problems must be addressed by Vorbis' creators. "
The rest of the of the story is currently running on K5." And Jack's response is enlightening as well.
As a consumer, it's more important that the standard that are adopted for me don't interfer with my daily life. Using Mp3 or OV or just plain WAV isn't going to be my decisions anyway. I can only vote with my dollars, but I won't be paying for any of these system regardless. This is one decision the slashdot crowd should not make. Do some consumer or gallop polls.
I really hate Dan Patrick.
Fixed point MP3 decoder? Is that like Fractint on the PC, which was much faster than anything else because it used integer operations?
What is the fastest MP3 decoder (assuming output quality is moderately important, but not everything)?
-- Ed Avis ed@membled.com
From the Vorbis guy's response it's clear what the problem is: The idea is great, the plan is good, but the deliverables just take time to materialize. Nothing bad about that, it's true for practically every piece of software (or related, like the Ogg Vorbis specification.)
Regardless of whether the author of the K5 piece is right about the points he discusses, the Ogg Vorbis creators should take his criticism to heart instead of dismissing it. It's not about whether all those points are valid, so trying to prove that they are not doesn't accomplish anything. They should understand that apparantly they have a problem communicating their plans to their possible supporters from the development community and that what they are doing apparantly makes a strange impression.
They should be glad someone took the time to actually write this down and complain instead of just forgetting about their project and doing something else.
I can see one main way for Ogg to gain widespread acceptance quickly - as the sound track of your run-of-the-mill, MPAA-angering DiVX. MP3 soundtracks only allow for 2 channels, whereas Ogg will allow for n. The main thing that pisses me off about DiVX is the lack of 5.1.
Imagine how widespread Ogg would be if it was the favored soundtrack of the DiVX generation.
Actually, I got the impression that the author was very frustrated at trying to do an independent 'from-spec' implementation of Ogg... which is impossible since there's no spec.
Code defines an implementation, not a specification, and using code as a spec leads to 'bug compatible' further implementations (ie. Yeah, that's feature's done really poorly, but it has to in order to be compatible with the bug(s) in the original)
This is ungood.
--Z
Sorry to say it, but I cannot use it on my iPod and with iTunes. I ripped my 125+ audio-cds to MP3 as when I got my iPod.
I hate it when people comes up with this kind of reasons for not switching to a free format and making the world a better place... but now I do it myself. It is a pity. It is a shame.
But maybe I am wrong? Has anyone installed Ogg in iTunes, and is there any chans to hack the iPod?
I thought they both had valid points. What really struck me (it's all about me :-) was that Xiph guy responded to his points. Compare and contrast with the guy from ... oh crap it's early ... Redmond Linux? the one who didn't have source for his Linux distro in the beta CDs. He ducked all attempts
at answering the points that were raised against him, and just whined about the Linux community "eating its young" or some such. That left a bad taste in my mouth -- side step the questions, throw mud around -- whereas
with this I came out w/respect for both people and both points of view.
Of course, I could be wrong. I remember the last time it happened. It was a Monday...
Carousel is a lie!
license fees don't matter in commercial software
They don't? I would assume the fees do matter because they raise the price of commercial software. I don't know any more than the average person about the commercial software industry, so please explain. I'm not trolling, I'm genuinely curious.
Developers: We can use your help.
Its not arrogance. We all want Ogg to be in wider use and to appear in portable players. From this discussion it is very clear that Ogg Vorbis is still very much in development and needs to be much more stable before anyone starts making software and hardware Ogg players. An incomplete specification and a reference implementation is not sufficient.
I use madplay and I'd like to see a version for Ogg, but at this stage it doesn't seem like Xiph are ready for developers. As they say, wait for 1.0 final and the promised complete documentation.
No, I did not read the f***ing article!
What kind of embedded system would have an Ogg player? How about a car stereo? Like, say.. an empeg? Which doesn't have a much in the way of CPU, including the fine lack of a floating point processor?
Vintage computer games and RPG books available. Email me if you're interested.
..because I could correct the idiot who moderated this Interesting. Is there a "Misinformative" rating?
Anyway, not to interrupt a fun GPL thread, but Ogg Vorbis is BSD-licensed precisely to encourage adoption.
Daniel
Hurry up and jump on the individualist bandwagon!
Near the very end of Jack's reply, he says something to the effect of, "If you'd like us to get the spec done sooner, here's where you can send money."
I'm not too sure how throwing money at the problem will solve it, as it seems to me that time is the real issue. Of course everyone says that time==money, but perhaps in this case not for all reasonable values of "time"?
-Peter
As open source Ogg Vorbis is released under the GPL/LGPL. However doesn't this prevent companies to integrate the sources into their software ?
Except... Ogg Vorbis isn't released under the GPL/LGPL. The license is basically BSD in form, but different wording.
To quote Jack, which wouldn't be necessary if you had read the linked message:
It's actually Free-er than most Free Software in some ways, siince we chose to prioritize adoption rather than require everyone buy into the LGPL. In essence by giving up a few freedoms with the more lax license, we are preserving freedom because the world will adopt Ogg, the only audio codec right now of it's kind that can be freely implemented.
Any sufficiently advanced technology is indistinguishable from a rigged demo.
Not really, divx only specifies the video format. You can plug in any sound codec you want to, including AC3. Here's a nice guide
As open source Ogg Vorbis is released under the GPL/LGPL. However doesn't this prevent companies to integrate the sources into their software ?
This is wrong.
The spec is public domain-- it's not well documented, evidently, but the format itself is public domain.
The utilities are GPLed, so you have to distribute the source to anything that encompases them.
The libraries themselves, however, are under BSD.
See The Ogg Vorbis FAQ.
-Rob
Honestly...what kind of embedded system would have an Ogg player in it? Your microwave? A candy dispenser?
Seems silly now, but what if someone makes a talking microwave, or a talking candy dispenser. Compressing the audio files, even if it is just a voice, would save space.
I'll have something intelligent to add one of these days...
Where did you hear that Ogg Vorbis [by which I assume you mean the reference implementation libraries] was released under the GPL/LGPL?
The sample tools are GPL - but the libraries are under a license similar to the 3-clause [ie old] BSD. This is specifically to encourage widespread adoption of the standard. Think about it: if you want to add Ogg Vorbis support to your application or embedded box, you won't be borrowing the command-line tools, just the libraries.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
For example, I am not aware of any flash portable pocket player that has an FPU. That's because it's entirely possible to do MP3/WMA in integer. Nobody is going to fit an expensive and battery draining processor into their product just to support an extreme minority codec.
By using floating point for the algorithms, libvorbis is ruled out from nearly all embedded devices. At the moment it pretty much only runs (in real time) on PC/Mac systems.
What's your point? I copy and pasts in Galeon all the time.
Dinivin
The entire point in this statement/response is setting expectations. The programmers expects to recieve the same support about the format that he got when he was developing MAD... the format developers, not being commercially funded, spend their time working on the tangible aspects of the application (bugs, libs, etc) and not the supplemental portions (specs). They expect that people would rather have the software to use over some dry RFC...
Is the problem that some people are too stupid to figure out how to copy and paste in X?
Dinivin
For embedded, you want as cheap as possible while still able to do the job. The CPUs commonly used in embedded designs often don't have floating point capabilities - too much silicon, too little need. Complexity means not only unit cost but power usage and cooling requirements.
Sure, you can ship a machine with a 486DX instead of an ARM, but the optimal solution is to figure out how to use fixed point. Software-emulated floating point won't cut it either - too inefficient. In the embedded world, "inefficient" doesn't mean "oh well, just so long as the CPU is fast enough to handle it", it means "unit cost is higher than necessary since we should have been able to get away with a slower CPU".
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Shameless plug... For some who might be interested in compression voice for VoIP, there's also the Speex voice codec. For voice (not music) it provides good quality at lower bit-stream than Vorbis.
Opus: the Swiss army knife of audio codec
The problem with OV is that it doesn't make enough of a jump in compression from its predecessor, the MP3 format.
MP3s will continue to rein supreme, Iron Chef style, until someone releases a new compression algorythm that saves at least 10x more space. It is too much work to convince MOST people to use other forms of music compression when there is negligable savings (in quality and size) for the average user.
------
Today's Top Deals
And what does 'Audio Decompression Hardware' mean to you? You rezlize that any such hardware would be format-specific, right? You realize that only very large corps can really afford to get ASICs fab'd, right? And you realize that it's likely much more cost effective, as well as much more *flexible*, to shove the latest-generation embedded CPU (which is probably $20 in quantity) into the machine, and do your audio decomp in software? Well, obviously you don't realize one of those or you wouldn't have asked the question...
--Z
Sorry if I sound like I'm trolling. I'm not. I'm just being honest.
Co-founder and designer at Music Nearby: http://musicnearby.com
The Ogg reply says that the only two standards bodies they know about are IETF and W3C. Well, what about IEEE? What about SMPTE? Those are technical bodies that deal with these kinds of standards all the time.
...phil
"For a list of the ways which technology has failed to improve our quality of life, press 3."
Personally I thought the news that Ogg Vorbis is now shipped with Winamp 2.80 was the news of they day. Any guess as to how many times over this will double the installed base of computers capable of playing Vorbis-files?
Belief is the currency of delusion.
If they dropped the Ogg part it sounds OK. Vorbis for the long name, and .VRB for the file name. 'Vee are bee' doesn't sound too bad. Or maybe .VBS (hmmm... I'm sure if seen that somewhere before, maybe skip that one).
This is somewhat besides the point, but in case noone had noticed, the latest Winamp 2.80 ships with Vorbis support by default.
:)
This is very nice because:
a) no more explaining how to install plugins to less-literate users
b) it seems that the legal team of AOL considers Vorbis to be patent-safe (they looked into the matter, which is why this lasted so long)
c) some of the WinAmp developers have become Vorbis freaks
--
GCP
Well, he's definitely right about the importance of a spec.
There's a world of difference between something that's defined by its implementation and something that is defined by a specification.
Open source efforts suffer from the tendency to primarily have an implementation and secondarily, maybe, a specification. Depending on what the thing is, this may make it less useful. There are several open source languages that have this problem, but this is a lesser problem than for a codec. If you want perl you know where to get it. No sane person would want to reimplement it.
But having a single implementation makes things worse, even for programming languages. People will tend to rely on the exact way things just happen to work in that implementation, and quirks can become features. Too often, end up requiring a specific version of the implementation. Proper languages change far less frequently.
I totally agree. As the hardware developer on a portable mp3 player I can tell you that unless you want to use a hardware decoder (the MAS... chip) and get locked into a particular format (MP3) you're need an software implementation sans floating point. While it is possible to get embedded proc's with floating point capability, the price is simply not worth it in most cases. For instance an EP7312 with no floating point costs about $20, an EP9312 with floating point costs more like $50. Which is why small companies with a low budget like mine choose the cheaper proc's. We are totally open to supporting Ogg, but our first release will support MP3 only because we do have a free library that runs on our proc and runs on it well (well we pay 25 cents per player to Fraunhoffer, but I think that's entirely reasonable)
They are decent processors - you can do MP3/WMA/Whatever without an FPU. Hell, you can play Quake on them at a reasonable speed. Same goes for Vorbis - it "just" needs an integer implementation, which is rather a large task that nobody in the public domain wants to take on, and no business wants to spend development time on.
if you dont have people that get money for their work on the product the quality decreases
Hmmm, I have to disagree. Most people who don't get money for their work, and do it anyway
are doing it for the joy of it, usually as a labor of love. The end product is usually BETTER than the work they get paid for, since it's generally not something they care about. Nor do they feel compelled to go above and beyond what they're required to do.
Money, while a necessary evil (well sort of), degrades a product's quality. One needs only to look to MS for a real world example.
I'm the big fish in the big pond bitch.
It would also help to lobby people like Winamp, LimeWire, WinMX etc. to include Ogg as a recognized format by default making it easier to locate and play music.
What I'm going to say is what software engineers already know.
The specifications for software are much, much more important than your implementation. If the specifications are written completely and well, the design of said software project will "fall" from the specifications, and the implementation will "fall" from the design. "Specification" isn't something you can do after-the-fact; at best, you will have an incomplete specs document (because of developers who incompletely document their own code), and at worst you will have WRONG specs (because a developer makes an innocent typo that doesn't get caught).
Sure, the ogg stream format and the vorbis audio format have been frozen for a year; however, code is not self-documenting. One of my wisest professors said that the only man he has known that writes self-documenting code is Knuth, and you might be a good hacker, but you are NOT Knuth. Every mortal man needs specifications and design documents to be able to make ANYTHING out of ANY piece of code; hell, I have some relatively simple Java apps I hacked together six months ago that would read like Greek if I didn't have my specs and my design documents.
How can anyone expect to reasonably use an undocumented format?
Either way, it's generally a good idea to have spec done prior to completing your product. I know the hackers out there will balk at this simple minded engineer, but some people out there think that writing down what you're going to do before you do it, might be a decent way to get it done. But let's face it, writing specs isn't always the sexiest work.
I love ogg vorbis, it sounds great, and it being free makes it even better. I will be sooo happy when I can flash upgrade my iRiver Slim X and my wifes iPod to play them, but that may be awhile. The one aspect of Ogg that seems to be the killer app for me is the automatic bitrate reduction. I rip all of my stuff at 320 mp3 for use on my desktop machine, but when I'm jogging, the Slim X has a tendency to skip when playing files of that bitrate. I long for the day when I can downsample the file automatically to 128 for skip protection. Its part of the implementation of ogg vorbis from the beginning, but noone has made an app to do that. For me that would be Ogg Vorbis's killer app, and something that would get me to re rip my cd's into ogg.
"My head hurts, My feet stink, and I dont love Jesus." -Jimmy Buffett
Still, it's a nice step in the right direction...
Actually, I think the goal is to have version 1 of the spec and version 1 of the implementation released at the same time. Trying to finalize the spec first is all well and good, but creating a reference implementation can help point out the problems you didn't think of when writing the spec. It's always a good idea to know where you're going before you try to get there, but trying to completely freeze a specification before letting your hands get dirty can lead to disaster.
Design comes first when you have a clearly defined tasks for which it is easy to develop a working system once you have comprehensive requirements.
For something where the implementation method isn't well understood, that is going to fail miserably.
I was looking at doing some audio hacks with a compressed format. I was trying hard to find an Ogg Vorbis specification but couldn't find any. Eventually, I gave up and used MP3. Even if I had reverse-engineered the Ogg Vorbis en/decoder, without an official specification, there would have been no guarantee that things would have remained compatible or that I wouldn't have missed some important subtlety.
I had a discussion on /. with Emmett Plant from xiph.org about the fixed point decoder a couple of weeks ago, thought it might be relevant, you can find it here. He makes some interesting, but sometimes short-sighted points about the fixed point decoder.
"Karma can only be portioned out by the cosmos." -Homer Simpson
Hey, at my school they just built a new dorm last year that has apartment-like rooms in it. When I moved in I was suprised to find my microwave telling me I had a message. I thought WTF? Why is my microwave telling me I have a message? So I hit the message button like it told me to, and I got to hear half a conversation about hardware that the guy who was installing it must have been having.
Anyway, talking microwaves exist now. Why? I have no idea.
"Specification" isn't something you can do after-the-fact;
But it happens all the time in real life. C, C++, Fortran and Pascal were all specified after the fact.
Part of the advantage is that when those were being specified, it wasn't just a specification in search of users, they knew that people would use it. Do the implementation first to attract user, and then specify, and there's less of chance you're wasting time.
Secondly, Algol 60 was specified first, then implemented. Algol 60 had call by name, one of the most complex and painful of means of calling arguments, only because they specified first and then discoved what they had specified. Implementation first means that you can find some of the stupid mistakes first, before you write the implementation.
Code defines an implementation, not a specification, and using code as a spec leads to 'bug compatible' further implementations (ie. Yeah, that's feature's done really poorly, but it has to in order to be compatible with the bug(s) in the original)
You can always ask the authors whether that's a feature or a bug. And it's not like you don't have to be bug compatible with specifications, too.
Do you run around telling people "Check out the new Moving Pictures Experts Group - Layer 3 player I got!!"
No, of course not. "OV player" or "Vorbis player" would work just as well.
(slightly OT)
I do have problems with stupid product names, though. How could you be a linux advocate and try to steer people (especially large organizations) to a distro called "Phat Linux". The sites for many of these distros are so goofy and unprofessional, it's no wonder the general public doesn't go for more open source software.
bytesmythe
bytesmythe
Hypocrisy is the resin that holds the plywood of society together.
-- Scott Meyer
JPEG vs GIF is more like MP3 vs MIDI. (actually that's a reasonable analogy
:: mp3/ogg/etc. (lossy compression via removal of high frequencies)
:: flac/lpac/shorten/etc. (lossless compression via huffman coding compression)
:: midi (lossless symbolic description of media primitives)
Here's a more reasonable isomorphism between audio and image formats:
JPG
.gif/.png
.svg/.eps/etc.
The assumption that Windows is of higher quality because more people use it is a fallacy. As if the only factor determining a products qulaity is how many people use it.
I'm the big fish in the big pond bitch.
C, C++, Fortran, and Pascal may have been specified after the fact. However, if you had studied programming languages you would know that to be able to implement a language you also have to implement a grammar.
A document describing the grammar of the language + the source code for the implementation of the language (a compiler) is much more descriptive than the implementation (the compiler) alone.
There is no way that you could write a compiler without said language grammar. The notion that you could conceviably write a useful compiler for a language that you only have knowledge of in an informal manner (i.e. me trying to write a Java compiler from just my knowledge of how the Java language works and not from design documents like grammars) is insanity.
Also, you mention Algol 60 being specified and then implemented. Two points:
1. Call-by-name is bizarre, but useful in some cases. Can you provide proof that the designers of Algol 60 considered the call-by-name parameter passing scheme implemented in that language a fault?
2. The whole point of having a series of steps before you get to implementation is because faults you catch in the requirements, specification, or design stages of development are much cheaper to correct than if you caught that same fault as you were implementing / after the product is already complete.
Implementation before specification = bugfest.
However, if you had studied programming languages you would know that to be able to implement a language you also have to implement a grammar.
To implement any program that reads a file, you have to implement a structure for the file. That's the easy part. It's the semantics - what the bytes mean, instead of how they are ordered, that's the hard part.
There is no way that you could write a compiler without said language grammar.
But it's been done. It's not that hard to discover from studying sample code. The tricky stuff is getting the semantics right, and that wasn't clearly specified in C, C++ or Fortran prior to the standards.
Can you provide proof that the designers of Algol 60 considered the call-by-name parameter passing scheme implemented in that language a fault?
Besides the fact that the designer's own implemenation didn't handle it correctly, because it was too much work? Between call by name, and integer labels, I don't believe there ever has been a complete implementation of Algol 60.
2. The whole point of having a series of steps before you get to implementation is because faults you catch in the requirements, specification, or design stages of development are much cheaper to correct than if you caught that same fault as you were implementing / after the product is already complete.
The point that you're missing, is that people miss problems in specifications all the time. If you implement first, then you are guarenteed to catch anything that's unimplementable or unusable; if you standardize first, then there's a chance they will pass you by.
Implementation before specification = bugfest.
Argument by assertion! How profound. I guess you couldn't find any examples to back up your case, then.