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.
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.
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
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!
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.
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.
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...
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
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
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
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.
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.
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