The Future of Ogg Vorbis 229
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.
No specification (Score:1, Informative)
of Ogg Vorbis. There we go, whole problem in one line.
Does OV run on Be? (Score:2)
Fixed point MP3 decoder (Score:2)
What is the fastest MP3 decoder (assuming output quality is moderately important, but not everything)?
Re:Fixed point MP3 decoder (Score:4, Informative)
The fixed point implementation of Vorbis would be very useful for embedded hardware where floating point support is usually not available on its CPUs.
Re:Fixed point MP3 decoder (Score:1)
Yeah, this used to matter a lot. I remember once seeing integer-only code for drawing a circle on an Apple II. This was in 6502 assembly language, which doesn't have floating point. Neither does 8086 assembly language [no I'm not counting the 8087 bridge instructions], which explains why Fractint was such a win.
Even when the 486DX came with an integrated x87, it pretended that the FP logic was still on a separate, optional chip - and as a result, floating point access sucked in a number of ways - specifically for context switching - the FP registers are really slow to load / unload in bulk. I guess Intel finally fixed this with new instructions in the PIII; AMD meanwhile seem to have given up on the x87, re-implementing FP math (incompatibly) with the 3DNow! instruction set.
Re:Fixed point MP3 decoder (Score:2)
(which the AthlonXP/MP/4 supports btw)
Re:Fixed point MP3 decoder (Score:2)
(Note: It was a rhetorical question)
Emacs (Score:3, Funny)
Unfortunately... (Score:1, Troll)
Re:Unfortunately... (Score:2)
What's your point? I copy and pasts in Galeon all the time.
Dinivin
Re:Unfortunately... (Score:2)
Is the problem that some people are too stupid to figure out how to copy and paste in X?
Dinivin
Re:Emacs (Score:2)
Well, I'm not sure what browser he's using, but ctl-e ctl-e under lynx launches your default browser, and I'd be willing to bet that some of the other browsers out there have the same functionality.
Re:Emacs (Score:2)
+ right-click anywhere in the window, and select "Mark"
+ use the mouse to select whatever text you want to copy
+ right-click again to copy the selected text to the clipboard
If you're using command.com and not cmd.exe, you'll need to click the control menu in the very top left corner of the window, select Edit and select Mark from that menu--from there, its the same. Not the most intuitive of processes, but it works, and works well in my experience.
Re:Emacs (Score:2)
Links is better, save for the low resolution on my laptop, where Lynx saves the day in console (since it ignores tables).
Btw, I have a win32 version of Lynx, but does anyone know of a win32 version of Links?
The author of that article needs some cheese.... (Score:1)
In his article he states:
Unfortunately it is neither highly optimized nor well-suited for all platforms, particularly embedded systems and other hardware lacking native floating-point support.
'Tremor' is the name of a fixed-point implementation optimized for certain embedded systems. Xiph.Org has recently begun to commercially license this implementation, but it is not otherwise freely available.
I suppose he has a legitamate complaint that the specs aren't complete...but that's really up to the author. They're providing a drop in library that's free. Try getting that from Freuhoffer.
His other point seems silly to me. Honestly...what kind of embedded system would have an Ogg player in it? Your microwave? A candy dispenser? I mean honestly... if you're going to make a player for music, you really should have the hardware support. (They don't rip the computers out of a microwave and try to adapt them to portable MP3 players.
Re:The author of that article needs some cheese... (Score:4, Insightful)
Re:The author of that article needs some cheese... (Score:2, Informative)
--Z
Re:The author of that article needs some cheese... (Score:4, Informative)
How about you look up which CPUs they use? (Score:5, Informative)
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.
Re:The author of that article needs some cheese... (Score:3, Interesting)
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.
Re:The author of that article needs some cheese... (Score:2, Interesting)
Anyway, talking microwaves exist now. Why? I have no idea.
Most embedded systems don't have an FPU (Score:4, Insightful)
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.
Re:Most embedded systems don't have an FPU (Score:5, Insightful)
>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 way you state this sounds like as if Vorbis can't be done with integer-only artihmetic, which is false.
The reference implementation uses floats, because it makes the code easier to understand (that's what the article indirectly is about!), but there's no reason why you can't have integer decoders (and they already exist...)
--
GCP
Re:Most embedded systems don't have an FPU (Score:3, Interesting)
Sorry, didn't mean to have that impression come across. The main problem is that it's going to take a long time to rewrite all of the algorithms for integer. It's a shame really, because it would have taken just about as long to write it in integer in the first place. Floating point isn't the magic bullet everyone makes it out to be - it doesn't eliminate truncation and it certainly doesn't eliminate word size issues.
Actually, I find DSP code written in integer easier to understand because you can see exactly where the author is taking care of those issues much more clearly. In floating point it's all a bit magic, and in most cases they just didn't realise what's actually going on.
There's integer decoders for MP3 and WMA (and all sort of other codecs), so I agree there's no particular reason Vorbis couldn't be either. In fact, there are integer implementation of Vorbis - the trouble is Xiph want to sell them. Fair enough, but hardly anyone's going to buy it, and you've got to weigh that against the market penetration you'd get if it were free. Maybe they've got it right, but it still annoys me that, for example, I couldn't add Vorbis to an empeg car player because integer Vorbis isn't free, and I don't have the spare time to write an integer version.
Re:Most embedded systems don't have an FPU (Score:2, Interesting)
See http://www.xiph.org/archives/vorbis/200204/0300.ht ml [xiph.org] for more information.
Re:The author of that article needs some cheese... (Score:2, Informative)
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".
Re:The author of that article needs some cheese... (Score:3, Insightful)
Mentality (Score:4, Insightful)
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.
Re:Mentality (Score:3)
Re:Mentality (Score:2)
Re:Mentality (Score:4, Interesting)
MAD is more portable, higher quality (outputs 24-bit samples instead of 16-bit samples if you want) and an order of magnitude faster.
Is that good enough for you?
Re:Mentality (Score:2)
I, as well, can vouch for MAD's extreme sexiness, by the way. Try it and you'll never go back.
Re:Mentality (Score:3, Interesting)
Also, it seems like the Ogg Vorbis people will only write up a specification if they think anyone is interested in reading it. It's obviously a lot of work, and, if they didn't think their format would be implemented by other people, they would just work more on their own implementations instead. It's not particularly useful for people to complain about the lack of a specification (since they know it hasn't gotten done), although it is probably useful to hear that people still care.
Re:Mentality (Score:2)
In any case the reality is that I'm not sure the world needs another audio compression method. I'm not even sure the ones we've got will be anything but a curiosity in another year or two: With Moore's law still making networking faster and storage bigger and cheaper, it's possible that the preferred audio format may simply be raw WAV rips of the CD Audio tracks. The nice thing about that is that even the technologically illiterate can ow play high-quality audio without having to concern themselves with codecs or optimized encoding parameters to ensure good quality when ripping/encoding. The best way to make the encoding problem go away is simply to make encoding go away. With cheap 160 GB drives already on the market, this *will* happen: audiophiles first, then many of the rest of us as prices continue to fall...
Barriers to acceptance (Score:5, Interesting)
Imagine how widespread Ogg would be if it was the favored soundtrack of the DiVX generation.
multichannel divx (Score:3, Interesting)
Re:multichannel divx (Score:2, Interesting)
Re:multichannel divx (Score:2)
Also, how would you go about getting the 5 channels out of an SPDIF connector using ogg? Shouldn't part of the spec be to be able to do this? Would it have to decode and re-encode in DD format in able to do this? If this were the case, I could possibly see the advantage of AC3, as the original source would be encoded in AC3, you decode and re-encode in ogg, then decode and re-encode in AC3 again... Quite an ordeal to save a few megs. But getting 5-channel audio working for movies would be a great feat for the Vorbis team, and I think it's a goal worth shooting for. Who knows, maybe three years into the future the MPAA will be streaming movies to your TV in 5.1 with OGG and DivX. It could be done.
Re:Barriers to acceptance (Score:2, Interesting)
Widespread acceptance? Yes, making OggVorbis the audio standard for divx would make that... 5.1 would be nice.
However, is this what 'we' really want? Because if Ogg becomes associated with DivX and associated and therefore ends up getting noticed by those sweet lads and lasses at RIAA... then what chance is there of seeing widespread use of Ogg in commercial applications?
I mean, its all well and nice that the quality is better and all the rest... but if your appliance dont work with it, then its mucho useless, no? How many people apart from the few 'in the know' actually use it?
The hard truth is that companies will stay away from anything divx-related like it's the black death.
The way I see it, Ogg needs all the support it can get by all the manufacturers.
If that means no surround sound on DivX, so be it
Re:Barriers to acceptance (Score:2)
Re:Barriers to acceptance (Score:2)
3 years ago, Joe User had never heard of even an MP3. Then some friend of his showed him Napster. "So how do I play one of these here MP3s?"
"Go get WinAmp."
So now Joe User is skilled in MP3..
Skip ahead to 2002. "So I got $DownloaderOfTheWeek and searched for my songs, but all I got was these Ogg files - how do I hear them?"
"Go get the Winamp Plugin..."
I was never particularly interested in Ogg. I thought it was a stupid name for an unneeded format. (I never understood their logo, either - it looks like Jesus beating the hell out of a snake...)
But then I put Mandrake on my ThinkPad and ripped a CD using Grip - It used to be with Grip, you got the program, then went out and downloaded BladeEnc or Lame to actually do the ripping, but this version comes with an Ogg ripper.So I tried it out and DAMN, but they sound good. As long as I can get all of my players to play them, I'm in business. Probably, a lot of other people will come to accept Ogg this way, too - MP3s are not so old to most people that they have some sort of strong loyalty - if the stuff they want to hear is in Ogg - they wil download the plugin for their player and go about their downloading. As for ripping and distribution, if Ogg is free and people are somewhat familiar with it, rippers will use it by default - they may even install the WinAmp plugin for you at the same time...
Just my 2 yen...
Jim in Tokyo
My iPod (Score:5, Informative)
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?
Re:My iPod (Score:5, Informative)
http://www.macosxhints.com/article.php?story=20
and more directly:
http://qtcomponents.sourceforge.net/
"This site is dedicated to open source QuickTime development for popular open source audio and video codecs. We are currently working on Ogg Vorbis, an audio codec developed by Xiphophorus, and MNG, an animation video codec.
We have just begun the project, expect many changes over the next few weeks. We will offer a site for developers, as well as one for end-users interested in using our software. At the moment, some areas of our site are not yet implemented. "
Re:My iPod (Score:2)
On the other hand, there's no technical reason why we shouldn't be able to have Ogg decoding in iTunes. It'll use a little more of your processor than MP3, but it'll work fine.
wtf? (Score:5, Insightful)
Re:wtf? (Score:3, Funny)
Why, pray tell, would you try to submit an audio codec to the Internet Engineering Task Force, or the World Wide Web Consortium? Why not submit it to one of the 'really well known' and yet APPROPRIATE standards bodies?
Yes, they should submit to the Microsoft, the standards body that has done good work to correct Kerberos, HTML and several other standards from their initially flawed state;)
Re:wtf? (Score:1, Funny)
Re:wtf? (Score:2)
Check the 'Presentation Layer' of the well known seven layer model. Thus, its perfectly rational to have an audio format aimed at network use be standardised in this way.
Please also note that MPEG is a Network Standard.
Re:wtf? (Score:3, Funny)
The Taco Bell 7-Layer model? The Presentation Layer is the Cheese, if I am not mistaken.
Re:wtf? (Score:2)
True story: Dave Clark, of MIT and one of the fathers of TCP/IP, used to teach a class on "The art and engineering of protocol performance" at Interop (back when it only had one name and fit easily in the small San Jose convention center.)
In one of these classes, someone asked why mapping the 7-layer OSI model to the real-world TCP/IP model was so awkward. He told this true story (he was a member of one of the committees nivolved at the time): When the OSI decided to study the networking problem, they formed seven study commitees, pretty much arbitrarily, to research the problem. They were NEVER intended to define boundaries. But in typical ISO "politics taking precedence over reality", when they got back together, they could not agree on how and where to create interface divisions, so to avoid deadlock, they finally decided to just use the ones they had for the study committees. So there you have it - there are seven layers because there were seven study committees, and that goes a long way to explaining the uselessness of the OSI model.
Personally, I think we should exorcise this horror of French bureaucracy from every network textbook on the planet. The number of man-hours that have been wasted trying to apply it to the real world (especially since TCP/IP trounced OSI permanently almost 10 years ago now) is staggering. It would be hard to identify a single more damaging and bone-headed idea in the world of networking than the OSI model. It should die, along with pretty nearly all other ISO standards relating to networking and communications. (And yes, I realize that is quite a strong statement from me, but it's true.)
Re:wtf? (Score:2)
Re:wtf? (Score:2)
A little confused... (Score:2, Interesting)
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
Re:A little confused... (Score:2)
is.. i'm not technically enough informed regarding material like OGG's specs and it's use.
So if someone want's to pick up the gauntlet....
Re:A little confused... (Score:2)
Expectations (Score:2, Insightful)
trashtalking helps no one (Score:1)
most end-user tools where in fact programmed by at least two people, who could coordinate their efforts. (gimp for example) but as soon as more cooks come in the stuff gets buggy, everyone has different targets, and people think they have to express themselves in producin l33t-stuff that in fact no one needs or can use, other then step back and do nothing. if you dont have people that get money for their work on the product the quality decreases.
Re:trashtalking helps no one (Score:2)
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.
Re:trashtalking helps no one (Score:2)
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.
a rose is but a rose... (Score:1, Insightful)
Re:a rose is but a rose... (Score:2, Funny)
Re:a rose is but a rose... (Score:2, Insightful)
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
Open-source speech coding (Score:2, Informative)
Too little, too late (Score:4, Insightful)
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.
Re:Too little, too late (Score:2)
MP3s will continue to rein supreme, Iron Chef style, until someone releases a new compression algorythm that saves at least 10x more space
That reminds of back when ARJ came out as a compression format for DOS. ARJ was superior to PKZIP, but only in a numerical sense. Its compression was only marginally better than PKZIP, which is probably the same reason it did not become a compression standard. On the other hand, if you compare GIFs and JPGs, your premise is confirmed, not only did JPGs blow away GIFs in terms of compression of data, but they also beat out GIFs in other respects as well (JPGs having support for more than 256 colors comes to mind). As a result, JPGs eventually replaced GIFs as a dominant standard for reasonably good image presentation.
Re:JPEG vs GIF (Score:3, Informative)
Here's a more reasonable isomorphism between audio and image formats:
JPG
.gif/.png
.svg/.eps/etc.
Re:Too little, too late (Score:3, Insightful)
until someone releases a new compression algorythm that saves at least 10x more space.
An order of magnitude more space? Take an mp3 file, and turn it into one tenth as many bits at the same quality level? I doubt that's even possible.
Reasons (Score:5, Insightful)
Sorry if I sound like I'm trolling. I'm not. I'm just being honest.
Re:Reasons (Score:3, Insightful)
I think the best hope for Ogg Vorbis is if it is accept alongside MP3. So if every (hardware and software) MP3 player can play
I think that is THE way to get Ogg in the mainstream. Make Ogg and MP3 exist together in perfect harmony.
mark
Re:Reasons (Score:2)
I was recently visiting some friends in Detroit -- about as "your average Joe" as you can get. They told me, point blank, that they don't buy CDs anymore. They download and burn. The music they listened to was mainly mainstream Top 40 and dance type of stuff, and they were tired of paying the price of a full CD for the one single on it that was any good. So you tell me whether cost matters or not. If recording companies start putting pressure on the people who make MP3 codecs to pay kickbacks in the form of "piracy surcharges," you think nobody will start looking at Ogg?
Re:Reasons (Score:2)
They'll encode with mp3.
You forgot that fact that players are widely available and most of their music loving friends who understand and use this sort of thing will more than likely be using mp3. So why encode with something different?
The trade off of a (small) amount of disk space pales into insignificance compaired to the hardware support for and sheer availablility of mp3's.
Remember that outside of the slashdot-type crew, Ogg Vobis is pretty much unknown.
Standards bodies? (Score:2)
FPU Club (Score:2, Funny)
I am Jack's rambling reply....
Ogg Vorbis is in Winamp 2.80 (Score:5, Informative)
Personally I thought the news that Ogg Vorbis is now shipped with Winamp 2.80 [winamp.com] 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?
Re:Ogg Vorbis is in Winamp 2.80 (Score:2)
There's a hole in the bucket, dear Liza.
Somewhat offtopic remark (Score:3, Interesting)
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
Here's how to gain widespread acceptance (Score:3, Insightful)
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.
Re:Here's how to gain widespread acceptance (Score:2)
Which, of course, leaves us with the obvious question: how available are the specs for writing WMP plug-ins?
Specifications more important than Implementation (Score:4, Insightful)
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?
Re:Specifications more important than Implementati (Score:2)
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.
Re:Specifications more important than Implementati (Score:2)
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.
Re:Specifications more important than Implementati (Score:2)
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.
Oggs Killer app not here yet (Score:2)
I have to agree (Score:2)
Previous discussion on the fixed point decoder... (Score:2)
Re:arrogance (Score:5, Insightful)
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
Re:arrogance (Score:2, Insightful)
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.
Re:arrogance (Score:3, Insightful)
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...
Not arrogance (Score:3, Insightful)
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.
Re:arrogance (Score:1)
help them write the specs
Erm, the usual order is to define your specs FIRST, then start with an implementation. Fairly basic CS stuff. Ok, this does not always happen in the real world, but that's hardly an excuse.
Re:arrogance (Score:2)
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.
Re:arrogance (Score:2, Insightful)
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.
Re:Isn't the problem the GPL ? (Score:2)
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.
Too bad my moderation points expired.. (Score:4, Informative)
Anyway, not to interrupt a fun GPL thread, but Ogg Vorbis is BSD-licensed precisely to encourage adoption.
Daniel
Re:Isn't the problem the GPL ? (Score:3, Informative)
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.
Re:Isn't the problem the GPL ? (Score:5, Informative)
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 [vorbis.com].
-Rob
Re:Isn't the problem the GPL ? (Score:3, Informative)
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.
Re:Ogg is not finalized (Score:3, Insightful)
Re:Ogg is not finalized (Score:2)
Re:Winamp 2.80 (Score:2, Informative)
Still, it's a nice step in the right direction...