Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
The Trouble with Vorbis

By Verement in Op-Ed
Fri Apr 26, 2002 at 12:05:21 AM EST
Tags: Technology (all tags)
Technology

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.


ADVERTISEMENT
Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad
ADVERTISEMENT

Introduction

I am the author of MAD, a fixed-point MPEG audio decoder library currently used by many software applications. I implemented MAD from scratch using the specification contained in the official ISO/IEC standards documents.

For some time I have been asked and have wanted to write a similar library for Ogg Vorbis, but as I will explain, for all practical purposes this is currently impossible. While I am very interested in supporting Vorbis, I am held back by the current state of affairs. I believe I am not alone; the present situation is unnecessarily delaying the acceptance of Vorbis, and I think the strategy for Vorbis advocacy needs to be reexamined.

The Facts

The Xiph.Org Foundation says it offers a "fully Open, non-proprietary, patent-and-royalty-free, general-purpose compressed audio format" called Ogg Vorbis. In fact a full detailed description of the format has never been made available, but in spite of this Xiph.Org offers two implementations:

  1. libvorbis (et al.) is a floating-point reference encoder/decoder implementation provided under a BSD-like license. This implementation offers royalty-free drop-in support for Vorbis in many applications, and is used by virtually all software that currently supports Vorbis. Unfortunately it is neither highly optimized nor well-suited for all platforms, particularly embedded systems and other hardware lacking native floating-point support.

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

The Problem

The specification for Ogg Vorbis is currently incomplete and is unavailable in its entirety. This presents a problem for anyone who wants to create an independent implementation of the codec.

Without a specification, would-be authors of independent implementations are forced to reverse-engineer the reference implementation, with varying degrees of success. Indeed, independent implementations have no hope of remaining relevant in the face of an evolving reference implementation, and are prone to compatibility problems, unintentional or otherwise.

In effect, Xiph.Org presently has a monopoly on the only viable implementations of Vorbis. Anyone interested in supporting Vorbis in their application has little choice but to use one of Xiph.Org's implementations, a situation little better than that of proprietary formats like WMA or RealAudio. Granted Xiph.Org's license terms are considerably more generous than those of such formats, but the main selling point of Vorbis -- that it is non-proprietary -- is largely irrelevant when there is not, in fact, a full specification available for the format, and the only practicable implementations come from its creators.

The fact that one Vorbis implementation is royalty-free and open source does not change the reality that without a specification, few are able or willing to verify the claim that the format is actually patent-free. Who will indemnify those that choose to use Vorbis and are subsequently accused of patent infringement, despite Xiph.Org's assurances that the Vorbis algorithms do not infringe upon any patent? Xiph.Org offers no warranty for its code. In the absence of indemnification, publication of the format specification is the most important means of mitigating risk for anyone to use the format. Like the benefit of open source to find and eliminate bugs, a thousand eyeballs reading the specification are more likely to find and eliminate potential patent pitfalls than Xiph.Org alone.

To be widely accepted, Vorbis ought to be submitted to standards bodies. Not only is the absence of a specification an obvious impediment, but the lack of multiple independent implementations often sought during standardization may also delay the process.

Unfortunately the situation is now exacerbated because Xiph.Org has created a conflict of interest by developing and commercially licensing their own fixed-point implementation. The motivation to release a full specification is now weakened, as any subsequent independent implementation could become a competitor to Xiph.Org's new source of revenue.

Solutions

I submit that a Vorbis specification is more important than any implementation offered by Xiph.Org. A specification would:

  • hasten the adoption of the format as a standard;
  • allow the patent-free claims to be verified;
  • leverage input and experience from the community through feedback;
  • promote awareness as implementations proliferate, and spread knowledge; and
  • create an industry and a market for implementations, each on their own merits. Implementations can be tailored for particular platforms, optimized for speed or for quality, or combined with options for support, warranties, and value add-ons.

Jack Moffitt, executive director of Xiph.Org, a year ago confirmed to me his belief in the necessity of producing a full specification, but to date there appears to be little progress.

I believe it is imperative that Xiph.Org give priority to completing and publishing the Vorbis specification, above efforts to continue developing the reference implementation (beyond that necessary to support the specification), and before selling any further commercial licenses for their own implementations.

I am not suggesting that Xiph.Org should not try to make money. However, there are other ways Xiph.Org could make money without creating a conflict of interest. Here are some ideas:

  • Sell copies of the specification. This is the approach taken by standards bodies like IEEE, ANSI, and ISO/IEC.
  • Dual-license the implementation(s). Commercial examples of this approach include Trolltech, Sleepycat Software, and Sendmail.
  • Offer a warranty of non-infringement with respect to patents. In a sense, this is like selling insurance.
  • Sell support and/or developer subscriptions for the implementation(s). Examples include MSDN and ADC.
  • Franchise the Vorbis brand to value-added partners. This is one source of revenue for MySQL AB.
  • Perform certifications. This could be applied not only to independent implementations, but to any product which claims to support Vorbis regardless of the implementation. Some kind of certification mark might be useful, like the ones used by Dolby Digital/THX or Linux Journal.
  • Offer consulting services. Unexciting, perhaps, but the experience and expertise of Xiph.Org could be worth more than they realize.
  • License proprietary implementations after producing a specification. Xiph.Org has the advantage of being known for creating Vorbis, and a quality implementation from them could go a long way. Other examples in industry include Fraunhofer, Adobe, and RSA.

Conclusion

Vorbis offers promise, but Xiph.Org should reevaluate their strategy if the codec is to succeed. A full specification of the format is essential, as it will permit new implementations to be created and the codec to be standardized. That is what will give Vorbis the critical mass it needs to become ubiquitous.

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Poll
Were you aware that the Vorbis format is not, at present, completely documented?
o Yes 15%
o No 83%

Votes: 216
Results | Other Polls

Related Links
o MAD
o many software applications
o Xiph.Org Foundation
o Ogg Vorbis
o begun to commercially license
o currently incomplete
o varying degrees of success
o no hope of remaining relevant
o accused of patent infringement
o ought to be submitted to standards bodies
o little progress
o Also by Verement


Display: Sort:
The Trouble with Vorbis | 107 comments (103 topical, 4 editorial, 1 hidden)
what about you? (3.50 / 6) (#5)
by highenergystar on Thu Apr 25, 2002 at 11:07:19 PM EST

reading your article it seems that you are a highly talented and motivated coder, and one dedicated to the ideas/ideals of open source and collaborative efforts. maybe you could suggest some framework for the specification..having had experience in audio coding, standards bodies and the vorbis format, you could possibly create a document that would be a seed (possibly based on the test model long-term/short-term type documents for the audio and video standards bodies) and request contributions from interested parties....i think it may not be a trivial effort, but certainly other standardisation bodies work backwards (from a fixed file format- which is available with vorbis and the ogg framework) and forwards (with the basic algorithms to get there) and finally come up an acceptable working draft

damn. (4.00 / 10) (#6)
by regeya on Thu Apr 25, 2002 at 11:57:48 PM EST

The more I try to nitpick, the more I find I can't. The only thing I could nitpick is your use of business-ese when describing the organizational structure (damn!) of Xiph.Org. But that's it.

I truly hope that Jack Moffitt is reading this, because (and I would like this to be well-understood :-D) many of us (hey, that's me! :-D) would like to see Vorbis succeed. It's got a lot of things going for it; it just doesn't have the right things going for it to reach, as you say, "critical mass."

I wonder what, had MPEG not had public specs, would have filled the void that MPEG 1 Layer III has filled so far.


[ yokelpunk | kuro5hin diary ]

If there were no MP3... (4.00 / 6) (#19)
by pin0cchio on Fri Apr 26, 2002 at 01:27:07 AM EST

I wonder what, had MPEG not had public specs, would have filled the void that MPEG 1 Layer III has filled so far.

Had the MP3 spec not been public, we would probably be concentrating on linear-predictive codecs such as the one used for mobile telephones rather than codecs based on MDCT (an overlapped spectral transform with better coding properties than FFT).



[ Parent ]
A world without lossy audio compression (none / 0) (#92)
by statusbar on Sat Apr 27, 2002 at 12:42:46 AM EST

...would still be fine, although the hardware devices and file sharing apps would have been delayed a few years.

Bandwidth and memory storage devices have increased in size rapidly and will continue to increase.

back in the 28.8 kbaud modem days I downloaded mp3 files of my friend's band. Half an hour to download one song.

Now with ADSL I could download a lossless compressed 4 minute song (via shorten) in 4 minutes.

80 gig drives are only $200.00 canadian now. Assuming 388 megs per 'shortened' lossless compressed CD, I can fit 211 cd's on the drive. Cost now is $0.94 per cd.

Only 3 years ago a 4 gig drive cost $200.00 canadian. On that drive I could fit 117 mp3'd cds. Cost then was $1.71 per lossy cd which was great!

MAYBE the usefulness of mp3 and ogg is actually less now because of this. MP3s were required back in the modem days and small hard disk days. And mp3's were fine and useful back then. Now, lossless compression delivers more songs per download minute and storage device dollar then mp3's did only 3 years ago.

I personally do not NEED to use patent-encumbered lossy mp3 files anymore. Before, I did have to. And I would rather not now.

--Jeff




[ Parent ]
need / want (none / 0) (#98)
by minra on Sat Apr 27, 2002 at 09:30:32 AM EST

You make good points wrt increased bandwidth and storage capacity, however in rebuttal:

People want to store and transfer music. Perceptual encoding delivers 2-5 times more music per storage-unit than does lossless compression. This relationship remains irrespective of how much bandwidth/storage you have available.

While the perceptual encoding patent issues may be important to developers, they are even less relevant to today's end-user than, say, copyright law.

hmm... this is all to obvious... cancel or post? aww heck.

[ Parent ]
What the...? (3.66 / 12) (#7)
by J'raxis on Fri Apr 26, 2002 at 12:09:29 AM EST

You can download the source from them. How, again, do you need to reverse-engineer anything? Reading other people’s source code is not typically referred to as reverse-engineering. And it’s hardly proprietary if they’re releasing source code...

— The Raxis

[ J’raxis·Com | Liberty in your lifetime ]

Whoah! (3.00 / 2) (#8)
by J'raxis on Fri Apr 26, 2002 at 12:11:37 AM EST

I posted this as Editorial!! I started writing it before the story had been voted up and hit submit a few minutes afterward, it would appear. (Shouldn’t Scoop report an error or something instead of just changing the comment to Topical?)

— The Confused Raxis

[ J’raxis·Com | Liberty in your lifetime ]
[ Parent ]

That's ok (2.50 / 2) (#9)
by Kingmaker on Fri Apr 26, 2002 at 12:26:44 AM EST

This Front Page story obviously needed some topical comments.

[ Parent ]
It's not a bug, it's a feature (4.60 / 5) (#18)
by QuickFox on Fri Apr 26, 2002 at 01:08:14 AM EST

Scoop is much better than most people realize. Your post isn't Editorial, it's Topical. Scoop read your post and corrected your mistake.


Give a man a fish and he eats for one day. Teach him how to fish, and though he'll eat for a lifetime, he'll call you a miser for not giving him your fis
[ Parent ]

Sourcecode != Specification (4.87 / 8) (#13)
by Farq Q. Fenderson on Fri Apr 26, 2002 at 12:40:07 AM EST

While the sourcecode may specify an algorithm that adheres to the specification, it doesn't necessarily allow you to deduce the specification properly.

What the code actually does is tell the computer how to behave (in such a way that's compliant with the spec, presumably) but that's far from plain english - and sometimes it's hard to tell what's relevant. When it's a large chunk of code, written by someone else, it quickly becomes a serious challenge.

Consider: I've got the sourcecode to a bazillion different RFC-compliant email clients, but not one of them will allow me to properly deduce the actual RFC from the source.

farq will not be coming back
[ Parent ]
In most cases no. (5.00 / 7) (#16)
by jackiem on Fri Apr 26, 2002 at 12:56:43 AM EST

I'll agree that even for Ogg Vorbis, the source is not a spec. But at the same time, we knew it would take us a while (due to limited resources) to get a full spec out, so we've made the source as 'reference-like' as possible. And unlike MP3 where there were very few free implementations and even fewer good implementations, our implementation happens to be free and quite good. Most people have no need to create another general C-based impelentation, and what people have the need, have stepped forward and done so. I really have to give some kudos to the guy behind Jorbis. Not only is it a Pure Java implementation, it's also realtime on most machines.

[ Parent ]
No kidding? (1.20 / 5) (#22)
by Farq Q. Fenderson on Fri Apr 26, 2002 at 02:35:58 AM EST

I really have to give some kudos to the guy behind Jorbis. Not only is it a Pure Java implementation, it's also realtime on most machines.

I quote this on IRC, and it requires no explanation: Java is icky, and not even worth it.

farq will not be coming back
[ Parent ]
What'd really be cool (1.00 / 1) (#25)
by lazerus on Fri Apr 26, 2002 at 05:54:28 AM EST

is if someone wrote a Python implementation, called it Porbis, and then ported it to Jython. JPorbis?

[ Parent ]
Python bindings are already available (5.00 / 1) (#58)
by jackiem on Fri Apr 26, 2002 at 10:43:37 AM EST

And used by a few projects. It's not pure python, but it is certainly accessible to most who use the langugage.

[ Parent ]
Wow !! (5.00 / 1) (#65)
by lazerus on Fri Apr 26, 2002 at 11:52:28 AM EST

That's not bad. Well, one of these days I'm going to get around to getting an Ogg player going and installing it in my car. Love the quality. Congrats, keep up the good work.

[ Parent ]
Release a spec (4.37 / 8) (#36)
by tneff on Fri Apr 26, 2002 at 08:59:58 AM EST

You posted a lengthy rebuttal but the core of the whole thing boils down to this: Yes, there is no spec, we wish there were, but we're busy.

When you stop being busy and release a spec, or hire someone else to come in and read your code and talk to your designers and write a spec while you stay busy, then (and only then) Vorbis will finally be a living open source format.

When you release the spec, six crazy Russians you never heard of will write an insanely fast encoder that implements it, and someone else will try to outdo them, and you will benefit from the competition.

[ Parent ]
Don't forget hardware (3.57 / 7) (#10)
by gbd on Fri Apr 26, 2002 at 12:31:08 AM EST

I just bought a new truck, and much to my surprise, part of the included equipment was an in-dash Ford Mach MP3 player. My music collection was (about) 90% MP3 and 10% Ogg, but I ended up deleting the Ogg tracks, re-ripping the CDs, and re-encoding as MP3 so that I could play them in the truck.

Don't get me wrong .. I love Ogg and the sentiment behind it, and I want to see a completely open codec as much as the next guy does, but I'm pragmatic; if I can't play Ogg tunes on devices that are capable of playing other formats, then I'm going to end up converting my Oggs to the other format for purely utilitarian reasons.

Hopefully, future pieces of hardware (in-dash players, portable players like Diamond Rio, etc.) will support multiple codecs. But in order for that to happen, we need two things: 1) widespread use of the Ogg Vorbis format in the PC realm and 2) serious lobbying of hardware manufacturers. You have to believe that hardware manufacturers are going to be as receptive to the idea of a high-quality, well-established, patent-free codec as the "geek community" is.

--
Gunter glieben glauchen globen.

That's what he's talking about (3.50 / 4) (#11)
by Therac-25 on Fri Apr 26, 2002 at 12:36:26 AM EST


He's trying to write a fixed-point Vorbis decoder, presumably for an embedded (i.e. hardware) solution.

Xiph.org charges money for thier fixed-point solution, and has shown little desire to open up the spec so people can create alternate implementations. This is what the article is about -- no one is exactly forgetting about the Hardware :)

Modern mp3 players (Rio, Nomad II, etc) are already software upgradable for alternate codecs -- they can have a Vorbis player given to them after the fact. But if it's painful or costly for the hardware company to create this for the mp3 player to begin with...

--
"If there's one thing you can say about mankind / There's nothing kind about man."
[ Parent ]
Little desire? (5.00 / 6) (#14)
by jackiem on Fri Apr 26, 2002 at 12:40:26 AM EST

Companies that want fixed point decoders, also want support. Before we offered our for-money version, few people would talk to us. Now we're in discussions with everyone.

We've made every effort to be open. The fixed point version is based on the open version. We even said what specific parts of the code we converted, and we've helped others make competing implementations.


[ Parent ]
Sorry for being confusing (3.00 / 1) (#17)
by Therac-25 on Fri Apr 26, 2002 at 01:00:29 AM EST


I was attempting to restate the position of the original article for someone who didn't comprehend it very well. :) I don't really know anything one way or another about the situation.


--
"If there's one thing you can say about mankind / There's nothing kind about man."
[ Parent ]
Dual License? (3.00 / 1) (#23)
by jacmet on Fri Apr 26, 2002 at 05:39:34 AM EST

Have you considered putting the fixed point implementation under dual license? Then companies who makes commerical embedded systems and needs support can buy it, and unofficial community projects like the familiar linux distribution from handhelds.org can still have a GPL'ed ogg/vorbis player.

[ Parent ]
To get $$$ from embedded sys. vendors? Maybe not. (4.00 / 2) (#51)
by cduffy on Fri Apr 26, 2002 at 10:26:44 AM EST

But folks doing embedded systems work -- even commercially -- can use GPLed software inside their proprietary hardware without forcing altered licensing terms on anything they care about. That variety of dual licensing, thus, is no guarantee of income.

[ Parent ]
Doesn't have to be GPL (3.00 / 1) (#73)
by damiam on Fri Apr 26, 2002 at 03:41:59 PM EST

The new license could be something like "This software is only freely available for use in noncommercial projects, all commercial uses must be licensed."

[ Parent ]
Noncommercial-only licensing unopen. (4.00 / 1) (#90)
by cduffy on Fri Apr 26, 2002 at 10:50:57 PM EST

That would violate point 6 of the open source definition, and result in the end product being little better than demoware. More practically, it discards many of the advantages of open source -- a lot of the best contributors are those contributing as part of their jobs. (But then, I work for a [thriving!] open source company, so I could conceivably be just a teensy bit biased).

[ Parent ]
Gah, you're right (4.00 / 3) (#15)
by gbd on Fri Apr 26, 2002 at 12:45:59 AM EST

That'll teach me not to hastily skim an article after eight beers and four hours of re-encoding CDs. (Sorry for trying to restate your point, Verement.) At any rate, I think we can all agree that responsible advocacy is going to be our greatest asset in attempts to get Ogg support in the dashboards and handheld units of consumer .. let's hope it happens soon. :-)

--
Gunter glieben glauchen globen.
[ Parent ]
Who needs the spec? (2.50 / 2) (#24)
by gordonjcp on Fri Apr 26, 2002 at 05:48:57 AM EST

The source code is right there. It's far easier to make a fixed-point version given the source, than the spec.

Give a man a fish, and he'll eat for a day. Teach a man to fish, and he'll bore you rigid with fishing stories for the rest of your life.


[ Parent ]
"widespread" (none / 0) (#78)
by Refrag on Fri Apr 26, 2002 at 06:44:07 PM EST

widespread use of the Ogg Vorbis format in the PC realm
This isn't going to happen with you deleting your Ogg Vorbis files and re-ripping the CDs down to MP3 files. What we need are for more grassroots artists to make their music available in Ogg Vorbis format and then for these artists to provide some of their work on peer-to-peer systems.

Refrag

Kuro5hin: ...and culture, from the trenches
[ Parent ]

Response from the folks at Xiph.org (4.91 / 118) (#12)
by jackiem on Fri Apr 26, 2002 at 12:36:27 AM EST

I'll try to respond as best I can to these points.

There are actually five implementations of Ogg Vorbis now. Two of which are available from Xiph.org as you say. One is a Java port. One is an old fixed point version done under contract for Fullplay (which they have since open sourced). The Fullplay code only plays up to beta4 files. The fifth implementation is a completely new (not based on the reference) one by Segher, one of the Xiph.org team. It's not publically available at this time. I am not sure what Segher plans for this code.

I think it's plain from this, that there is no monopoly here. We control less than half of the implementations.

Now, about the optimization and platform suitability of libvorbis, the real reference implementation. It's is not fully optimized because it is the reference implementation. Who wants to look at lines of architecture specific assembly when they are trying to find out how stuff works or fix bugs. Premature optimization is the root of all evil, someone said. And I must inform you that it is quite platform agnostic. Sure, if you don't have an FPU, it's not great, but it runs on every OS, compiles with just about every compiler, and even runs on some embedded systems like the Dreamcast. I think we've done an excellent job in this department.

The specification is not complete. This is a very important point. I wish it were; we all do. We would like nothing better than a specification to magically appear. But the reality is we're only so many people, and there is only so much time. It takes a lot of work to write a good specification, and bad ones are almost useless. Look at the PDF spec, with it's team of authors that get paid fulltime to do nothing but maintain and write the spec.

We will provide a specification. Our goal has always been to ship Ogg Vorbis 1.0 with a first draft specification.

You also claim that the reference implementation is "ever-evolving". This is simply not true. The decoder has been frozen since RC1, except for minor bugfixes. I believe that comes out to almost a year without change. Sure the encoder gets better, but so do all the MP3 encoders too. Encoding will always evolve to be better as we collect better data and fix bugs, but the decoder we have now is the final decoder. You have no worries that we will change it out from under you. There was a reason for calling that release RC1.

I really don't see how using Ogg is anything like being locked into WMA or RealAudio. Many of the game developers have done their own optimizations or work to make it fit in their products, and several people are working on in non-compatible ways. Our code is Free Software. 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.

In regards to the standards bodies, there are really two well known ones, the IETF and the W3C. I have asked both standards bodies about Ogg and both basically rejected the idea. The exception was that the IETF said they might allow an information RFC with the Ogg Vorbis spec to be published. If you look, you will see that there are three drafts (maybe some got merged at this point) for various parts of Ogg Vorbis systems, including mime-types and streaming specs. We're trying the best we can here, but the reality is that the standards bodies are quite slow.

Now, about the patents. We have done our research. We sat down with multiple lawyers, went over patents, over algorithms, and even got issued patent opinions. Other companies have probably done the same, or big companies like Sonic Foundry, Steinberg, EPIC Megagames, etc wouldn't have shipped products with Ogg Vorbis.

We cannot indemnify Ogg Vorbis to anyone. Thompson does not indemnify it's patents on MP3 when you license them. It is not a common practice to do so in the business world. Who in their right mind would do such a thing in today's patent situations.

I have my doubts that the Open Source community (or any non-legal community) is as good at finding infringement as it is at finding bugs. The legal world is a different place.

We do sell our fixed point code. We are trying to fund our own development efforts. We're applying to be a non-profit and I can assure you that none of us are getting rich. We have no intentions of hiding anything to "preserve a revenue stream". In fact, Monty has many times told people exactly what parts need to be integerized and how best to do it. Just look on the list for all the people woh are working on this project. We give away a lot of hours to the community, and while you're free to disagree with our practices, we certainly aren't doing anything that conflicts with our stated goals.

I agree with most of your thoughts on the specification. It would benefit Ogg Vorbis a lot. That's why we intend to write one. It's a daunting and scary task, but it will get done.

However, I disagree with your points on proposed solutions.

Selling copies of the specification is a plan. PDFs for free, dead tree versions for some reasonable amount of money. I've even talked to publishers about this. We can't do this until the spec is written, of course.

We are dual licensing the implementation. We have one license for the reference, and one for the fixed point. I think this is quite reasonable. It allows us some amount of income in the short term to fund projects such as the writing of the spec, but we get to keep all of the important code Free.

As I already stated, we cannot offer warrantys or indemnification on patent claims. Neither can most large companies.

Selling support isn't really something that people have demanded. The exception is with fixed point code since it's sitting on devices that don't get upgraded as often as desktop machines. We do sell support if people want it. Trust me when I say this is not a very viable revenue stream.

Franchising the brand might be possible if we had much of one. Right now, even with all the adoption, we're still a far cry away from being able to sell the logo or something. If you disagree, I'd be happy to pay you a large commission on any deal you can close.

The certifiction stuff will probably happen with the spec. Just like with the MP3 spec, we will have some test files and such that people can use to determine if they are compliant.

We also offer consulting services. And I can tell you that not many people are hiring consultants right now. A year ago I was turning down jobs, and now I haven't had even a hint of one for a number of months. The original fixed point decoder was the result of such a contract. So was teh mixed-stream code I wrote to do Vorbis + MIDI in a single Ogg. I hope there will be more jobs like this, but we're in a slow time right now.

You seem to think that we have enough time and money to sit down and write a specification before we even think about raising some money to support ourselves. This is just flawed. If we wait until we're out of funding and broke before we start trying to bring in some cash, we're going to be left with an unfinished projects, no spec, and a bleak future were proprietary codecs are all that we have.

If you'd like the spec to get written faster, please donate. You can Paypal Xiph.org money at the donate@xiph.org address, or write to us to find out how to send a check, etc.

We have a lot of work to accomplish. Metadata specs, finishing Ogg Vorbis 1.0, icecast, Ogg Tarkin, Ogg Squish, etc. These are all important projects.

Jack Moffitt
Excutive Director
Xiph.org Foundation


P.S. Sorry for the rambling. Writing in this little box is a little difficult and is not nearly as much fun as Emacs :). If anyone has any questions regarding you can contact emmett@xiph.org or myself if I don't respond to here.

Reference libs can also include asm versions (4.37 / 8) (#21)
by pin0cchio on Fri Apr 26, 2002 at 01:52:36 AM EST

Now, about the optimization and platform suitability of libvorbis, the real reference implementation. It's is not fully optimized because it is the reference implementation. Who wants to look at lines of architecture specific assembly when they are trying to find out how stuff works or fix bugs.

Reference implementations come with portable C code. Many also come with hand-optimized assembly language versions of workhorse functions for i386 and a few other architectures. zlib, libpng, and Allegro are examples of reference libraries with alternate assembly implementations of some functions that can be turned on or off at ./configure time.

If you'd like the spec to get written faster, please donate. You can Paypal Xiph.org money at the donate@xiph.org address

I've just dropped 10 U.S. Dollars into that account, and I encourage fellow K5 readers to do the same.


lj65
[ Parent ]
Platform agnostic != Runs on any PC (4.50 / 12) (#29)
by pslam on Fri Apr 26, 2002 at 06:44:31 AM EST

Now, about the optimization and platform suitability of libvorbis, the real reference implementation. It's is not fully optimized because it is the reference implementation. Who wants to look at lines of architecture specific assembly when they are trying to find out how stuff works or fix bugs. Premature optimization is the root of all evil, someone said. And I must inform you that it is quite platform agnostic. Sure, if you don't have an FPU, it's not great, but it runs on every OS, compiles with just about every compiler, and even runs on some embedded systems like the Dreamcast. I think we've done an excellent job in this department.

Ok then, let's look at the numbers. Some platforms that lack an FPU:

  • RiscPC
  • empeg/Rio car player
  • Rio Receiver
  • Rio Riot
  • Rio Central
  • Turtle Beach Audiotron
  • All ARM based pocket flash portables
  • Most (all?) DSP based pocket flash portables
  • All other ARM based audio solutions

And I'm sure the list is much larger than that. On the other hand, platforms which have an FPU:

  • Wintel PCs
  • Macs
  • Alphas
  • Some MIPS audio platforms
  • Some Intel based audio platforms
I don't know of any MIPS based dedicated audio platforms (but there probably are some). There's a few Intel based audio platforms but they're not exactly cost effective and generally suck (read as: PC in a fancy box).

So what are we left with? libvorbis basically only runs on PC and Mac platforms! That's NOT platform agnostic. You might as well have required 64MB of RAM and said "sure, if you don't have 64MB of RAM it's not great - but it runs on every OS". You don't see an FPU in most embedded devices because they aren't cost effective and you can do everything in integer anyway. So you've effectively ruled out embedded audio use unless you pay for a licensed version. In other words, almost (I am aware of one) no consumer-oriented audio device will use vorbis. I work for empeg/Rio/SONICblue and I can tell that if an integer libvorbis were available in a free BSD or even LGPL license, all of our above mentioned products would most likely have Vorbis support. People aren't willing to pay a license for what is a tiny minority codec, and they certainly aren't willing to divert any development time to integerizing it.

In fact, Monty has many times told people exactly what parts need to be integerized and how best to do it. Just look on the list for all the people woh are working on this project. We give away a lot of hours to the community, and while you're free to disagree with our practices, we certainly aren't doing anything that conflicts with our stated goals.

The trouble is the people who are most interested in working on an integer vorbis are exactly the people who don't have the time to work on it. I myself have the ability to do it, and would love to - but I lack the spare time. There's also issues with who owns the code I write, even if I write it in my spare time. I suspect there are many people in my this position. Telling us exactly which bits need converting doesn't help at all. I could tell Microsoft which bits of Windows suck and how to change them, but that's not exactly going to speed things up. I personally don't expect to see any third party free implementation in the next year.

[ Parent ]

Hmm (4.33 / 3) (#30)
by jonathan_ingram on Fri Apr 26, 2002 at 07:53:44 AM EST

The trouble is the people who are most interested in working on an integer vorbis are exactly the people who don't have the time to work on it.

And what makes you think that the people working on Vorbis have any more free time? Hopefully, if they get some money in through licencing their integer implementation, they'll be able to get some time to write all the needed documentation.
-- Jon
[ Parent ]

Empeg got a free license already (4.00 / 5) (#57)
by jackiem on Fri Apr 26, 2002 at 10:39:40 AM EST

But obviously you knew about this since you work for them. So is the Rio car playing Oggs yet?

People are willing to pay a license for our codec, and several people have. I wish people would stop assuming that we haven't done any deals, especially when there are already several shipping products!

[ Parent ]
"Free license" is not quite as simple as (4.50 / 2) (#64)
by pslam on Fri Apr 26, 2002 at 11:49:17 AM EST

But nearly. For a start it's not an entirely "free" license - there's strings attached - so I assume there's some sort of legal sign-off which needs to happen. This has also happened at pretty much the worst time in terms of how busy we currently are.

Still, as soon as we have some spare time and a go-ahead I'm sure we can polish it off in a day or two. We'll probably go-ahead anyway and wait on a sign-off :)

[ Parent ]

Strings attached? (4.00 / 1) (#84)
by jackiem on Fri Apr 26, 2002 at 08:33:04 PM EST

As I recall we gave you the license to Tremor for your Rio Car product (since it was discontinued and had a community of people who are really wanted this support) only, but other than that I wasn't aware of any 'strings'. Sure you can't open source it, but I'm sure there's plenty of code you guys have at diamond that has similar restrictions.

The empeg guys said before if we gave them the code it would be done in 24 hours :)

I understand the need to get signoff. We waited months before AOL signed off on shipping Ogg in every copy of winamp, which finally started happening this week.

[ Parent ]
Free Integer Vorbis Implementations (5.00 / 1) (#108)
by nyar on Mon Jun 03, 2002 at 09:18:36 PM EST

fixp vorbis, done by Nicolas Pitre: ftp://ftp.arm.linux.org.uk/pub/linux/arm/people/nico/vorbis/

oggonachip half-done by Pattara & his German schoolmates: http://oggonachip.sourceforge.net/

Oh, and an arm-linux version of ogg123 using Nicolas Pitre's decoder at Zaurus Zone, for the Sharp Zaurus (an ARM SA1110-based handheld): http://www.zauruszone.com/cgi-bin/ikonboard.cgi?s=3cfbdc281809ffff;act=ST;f=15;t =51

It has been done, and will continue to be supported.  It would sure be nice to have a Spec though, since both of these decoders will blow up on newer versions of the Encoder (not the reference implementation) which will better support bitrate peelers.  Of course you wouldn't know this unless Monty was nice enough to pop in on the vorbis-dev list and mention it several times.

I can assure you though, that my Zaurus w/ ogg123 has recieved many ooh's and ahh's when plugged into home stereo systems vs. a portable mp3 player.  The market is certainly there for vorbis on embedded systems.

[ Parent ]

Author's reply (4.66 / 21) (#31)
by Verement on Fri Apr 26, 2002 at 07:54:10 AM EST

Jack Moffitt wrote:
There are actually five implementations of Ogg Vorbis now. Two of which are available from Xiph.org as you say. One is a Java port. One is an old fixed point version done under contract for Fullplay (which they have since open sourced). The Fullplay code only plays up to beta4 files. The fifth implementation is a completely new (not based on the reference) one by Segher, one of the Xiph.org team. It's not publically available at this time. I am not sure what Segher plans for this code.

I think it's plain from this, that there is no monopoly here. We control less than half of the implementations.
My point is that Xiph.Org currently has control over the only viable implementations of Vorbis. An old fixed-point version is not really viable when it only decodes up to beta4 files. Neither is an unreleased version. The only possible exception is JOrbis, the Java port you mention, which was reverse-engineered from the reference code.
Now, about the optimization and platform suitability of libvorbis, the real reference implementation. It's is not fully optimized because it is the reference implementation. Who wants to look at lines of architecture specific assembly when they are trying to find out how stuff works or fix bugs. Premature optimization is the root of all evil, someone said. And I must inform you that it is quite platform agnostic. Sure, if you don't have an FPU, it's not great, but it runs on every OS, compiles with just about every compiler, and even runs on some embedded systems like the Dreamcast. I think we've done an excellent job in this department.
It was not my intention to criticize the reference implementation; I believe it serves its purpose. Rather, my point is that alternative implementations which offer improvements over the reference code are unlikely to exist without first a complete specification.
The specification is not complete. This is a very important point. I wish it were; we all do. We would like nothing better than a specification to magically appear. But the reality is we're only so many people, and there is only so much time. It takes a lot of work to write a good specification, and bad ones are almost useless. Look at the PDF spec, with it's team of authors that get paid fulltime to do nothing but maintain and write the spec.

We will provide a specification. Our goal has always been to ship Ogg Vorbis 1.0 with a first draft specification.
These are good things to hear. My suggestion of course is that Xiph.Org's resources could be spent developing the specification to make it happen, rather than continuing to tweak the reference code or expending effort to answer individual questions on IRC or mailing lists that could be answered for everyone in a specification.
You also claim that the reference implementation is "ever-evolving". This is simply not true. The decoder has been frozen since RC1, except for minor bugfixes. I believe that comes out to almost a year without change. Sure the encoder gets better, but so do all the MP3 encoders too. Encoding will always evolve to be better as we collect better data and fix bugs, but the decoder we have now is the final decoder. You have no worries that we will change it out from under you. There was a reason for calling that release RC1.
Please note I did not claim the reference implementation is "ever-evolving." I claimed that Vorbis implementations reverse-engineered from the reference code are at a serious disadvantage when the reference code changes. It has happened in the past, and despite your assurances it will not happen to decoders in the future, I don't think you can guarantee that the reference code will never need to be changed. Even with a stable decoder, how are third-party encoders to keep up with improvements to the reference, or invent their own improvements, without understanding the details of Vorbis that a specification would make clear?
I really don't see how using Ogg is anything like being locked into WMA or RealAudio. Many of the game developers have done their own optimizations or work to make it fit in their products, and several people are working on in non-compatible ways. Our code is Free Software. 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.
My comparison of Vorbis to WMA and RealAudio ends after noting where the viable implementations of each come from. Of course we all believe and hope that Xiph.Org will do the right thing and release a specification as promised, and not steer Vorbis toward exclusively proprietary implementations, but at this point in time, Vorbis is not completely living up to its claim.
In regards to the standards bodies, there are really two well known ones, the IETF and the W3C. I have asked both standards bodies about Ogg and both basically rejected the idea. The exception was that the IETF said they might allow an information RFC with the Ogg Vorbis spec to be published. If you look, you will see that there are three drafts (maybe some got merged at this point) for various parts of Ogg Vorbis systems, including mime-types and streaming specs. We're trying the best we can here, but the reality is that the standards bodies are quite slow.
There are many other standards bodies also worth investigating, for instance ISO, ITU, and IEEE, to name a few. In any case, the point stands that standardization cannot take place without a specification.
Now, about the patents. We have done our research. We sat down with multiple lawyers, went over patents, over algorithms, and even got issued patent opinions. Other companies have probably done the same, or big companies like Sonic Foundry, Steinberg, EPIC Megagames, etc wouldn't have shipped products with Ogg Vorbis.

We cannot indemnify Ogg Vorbis to anyone. Thompson does not indemnify it's patents on MP3 when you license them. It is not a common practice to do so in the business world. Who in their right mind would do such a thing in today's patent situations.

I have my doubts that the Open Source community (or any non-legal community) is as good at finding infringement as it is at finding bugs. The legal world is a different place.
None of these conjectures changes my assertion that a specification is an important means of mitigating risk. The longer a specification has been published without a challenge of patent infringement, the more comfortable anyone is likely to feel that indeed, Vorbis does not infringe upon any patent.
We do sell our fixed point code. We are trying to fund our own development efforts. We're applying to be a non-profit and I can assure you that none of us are getting rich. We have no intentions of hiding anything to "preserve a revenue stream". In fact, Monty has many times told people exactly what parts need to be integerized and how best to do it. Just look on the list for all the people woh are working on this project. We give away a lot of hours to the community, and while you're free to disagree with our practices, we certainly aren't doing anything that conflicts with our stated goals.
Why would you choose to sell your fixed point code at the same time you are telling others how to create their own for free? This is a conflict of interest. Either you are shooting yourself in the foot, or you are motivated to delay others from creating something that may compete with you.
I agree with most of your thoughts on the specification. It would benefit Ogg Vorbis a lot. That's why we intend to write one. It's a daunting and scary task, but it will get done.
I am glad you agree a specification would be beneficial. Hopefully I have made the point that a specification not only would be beneficial, but is essential to Vorbis' future.
However, I disagree with your points on proposed solutions.

[...]

You seem to think that we have enough time and money to sit down and write a specification before we even think about raising some money to support ourselves. This is just flawed. If we wait until we're out of funding and broke before we start trying to bring in some cash, we're going to be left with an unfinished projects, no spec, and a bleak future were proprietary codecs are all that we have.
My intention was only to encourage thoughts and ideas on ways for you to make money that are not in conflict with the motive to produce a specification. I think you may have misinterpreted or overlooked some interesting facets of those possibilities, but I won't address them point-by-point right now. I am interested in feedback, as I hope you are, from others who may have other ideas and suggestions.
If you'd like the spec to get written faster, please donate. You can Paypal Xiph.org money at the donate@xiph.org address, or write to us to find out how to send a check, etc.
If nothing else, I am happy if my article encourages people to do so.

With kind regards,
Rob Leslie

[ Parent ]

No conflict of interest. (4.00 / 3) (#59)
by joev on Fri Apr 26, 2002 at 10:44:24 AM EST

First, a nit: you mention "reverse engineering" a couple of times. Reverse engineering implies that there is a "closed" product that is mimicked(sp?) by decompiling, reading assembly code, etc. For example, the JOrbis java classes are nearly line-for-line copies of the reference implementation decoder; the code looks a lot more like C than it does Java. Second, you mention "Why would you choose to sell your fixed point code at the same time you are telling others how to create their own for free? This is a conflict of interest." Writing code and telling others how to do something are very, very different things. I think I know how to build a jet engine from a turbocharger and a propane tank, but I don't have the detailed knowledge or resources to actually perform this task.

[ Parent ]
Epic Megagames? (4.60 / 5) (#32)
by AmberEyes on Fri Apr 26, 2002 at 08:18:19 AM EST

Epic upgraded their tech to support Ogg?

Veeeery interesting. Hadn't heard about this anywhere. Good news for me -- hope that you were allowed to say that and you don't get in trouble.

-AmberEyes


"But you [AmberEyes] have never admitted defeat your entire life, so why should you start now. It seems the only perfect human being since Jesus Christ himself is in our presence." -my Uncle Dean
[ Parent ]
Many games are using Ogg (4.57 / 7) (#56)
by jackiem on Fri Apr 26, 2002 at 10:36:19 AM EST

Serious Sam 2 is shipping with ogg, as did Operation Flashpoint, Star Trek Away Team, and probably some others I don't know about.

EPIC Megagames uses it (and are active on the development list), Papyrus Racing Games (these guys make the NASCAR games), Silicon Knights, Pyrogon (Brian Hook's new company), and many others. I'm starting to get hesitant to list them because I don't want to forget any and I'm sure I have.

[ Parent ]
Yeah (4.00 / 4) (#61)
by AmberEyes on Fri Apr 26, 2002 at 10:48:49 AM EST

I knew about Serious Sam2 and Op Flashpoint. I didn't know about Epic though.

Very interesting.

-AmberEyes


"But you [AmberEyes] have never admitted defeat your entire life, so why should you start now. It seems the only perfect human being since Jesus Christ himself is in our presence." -my Uncle Dean
[ Parent ]
Pyrogon (none / 0) (#77)
by Refrag on Fri Apr 26, 2002 at 06:30:32 PM EST

Yes, Pyrogon does use Ogg Vorbis in their game Candy Cruncher which is very cool and is out for Mac OS X, Linux, and Windows.

Refrag

Kuro5hin: ...and culture, from the trenches
[ Parent ]

Specifications (4.50 / 6) (#34)
by katie on Fri Apr 26, 2002 at 08:31:17 AM EST

"The specification is not complete. This is a very important point. I wish it were; we all do. We would like nothing better than a specification to magically appear."

How are your internal developers developing stuff if you don't have a specification? They're making it up as they go along and you're going to extract a specification from the source code?


[ Parent ]
"Specification" (4.50 / 6) (#40)
by Armored Scrum Object on Fri Apr 26, 2002 at 09:30:01 AM EST

"Specification" means different things to different people. The xiph.org folks almost certainly have some internal documentation on the format, but that's not the same thing as a full-blown specification that's "shopped out" and ready to be independently implemented. One is a moderate amount of work, the other is a huge amount of work. You can't just describe the format, you have to describe the format absolutely, so that there can be no confusion on the part of the implementor. Everything must be finalized and spelled out exactly and consistently. Otherwise, you have a bad spec.

[ Parent ]
specs (4.00 / 5) (#48)
by katie on Fri Apr 26, 2002 at 09:57:17 AM EST

That's what I figured - why not release the interim spec? yeah, it might be incomplete, but then it's got to be better than reverse engineering reference implementations.


[ Parent ]
Everything we have is there (4.42 / 7) (#54)
by jackiem on Fri Apr 26, 2002 at 10:31:39 AM EST

We have released every document we have. These things usually go right into CVS.

The Ogg container part is documented. It's just the vorbis pieces that are not. There were several attempts by people to write interim documents, and you can find pointers to these on the mailing list.

[ Parent ]
A more appropriate standards body (4.57 / 7) (#45)
by GuyZero on Fri Apr 26, 2002 at 09:45:13 AM EST

> In regards to the standards bodies, there are really two well known ones,
> the IETF and the W3C. I have asked both standards bodies about Ogg
> and both basically rejected the idea.

What the hell are you talking about?

There's the IEEE, the ECMA, and of course, the super-standards bodies like
ANSI and ISO.

It's unsurprising that the IETF and the W3C are uninterested in your
audio format standard - they work primarily with text & protocol oriented
Internet interoperability standards surrounding TCP/IP and HTML respectively.

Maybe try to find a more appropriate standards body.

[ Parent ]
Doesn't it take years? (4.20 / 5) (#53)
by jackiem on Fri Apr 26, 2002 at 10:29:30 AM EST

My understanding is that those "normal' standards bodies take years and years. We're certainly willing to entertain the idea, but I suspect it takes a lot of time, not to mention money.

In any case, we've been doing this for a while, but certainly not long enough to have produced a standard endorsed by ANSI or IEEE or one of those I think. Even if we had started two years ago, I think the spec still wouldn't be out.

If you have some pointers on the process and how it works for those guys, or how other Free Software projects have done this, I'd love to see them.

[ Parent ]
Fast-track. (5.00 / 5) (#67)
by jason on Fri Apr 26, 2002 at 12:13:54 PM EST

Many standards bodies have fast-track solutions, ones that can bring the standard time down to months. See what MS is doing with C# in ECMA, and what Sun wanted to do with Java in ISO. However, all of the alternative organizations discussed require money, iirc. I'd rather see you spend money internally to get a spec out. And none of this saves you the effort of writing the damned thing. ;)

And the only difference between standards issued by standards bodies and de-facto standards are that the former have a set process for changes. This can be really detrimental to an early stage project. I realise Ogg may be passing out of that phase, but you still want to watch out for premature standardization.

Sorry I'm missing links to the procedures, but I'm in a hurry. If I get a chance later today, I'll add some. Or maybe someone else will.

Jason

[ Parent ]

W3C (none / 0) (#91)
by statusbar on Fri Apr 26, 2002 at 11:55:18 PM EST

Good thing the W3C didn't get involved. Otherwise you'd probably end up with a compressed digital audio format standard represented in XML.

--Jeff

[ Parent ]
Loan 'ya a tech writer? (4.25 / 4) (#47)
by cduffy on Fri Apr 26, 2002 at 09:53:17 AM EST

One suggestion that might have the potential to make folks happy: If you were given a tech writer on loan, might that make the specification happen quicker?

Now, I'm not offering to do that myself -- but if the option is publicly extended, it might incline some folks (such as the author of this article) to take that route of assistance rather than publicly complain about the inavailability of a spec.

[ Parent ]

"Premature optimization..." --Don Knuth (4.40 / 5) (#68)
by jholder on Fri Apr 26, 2002 at 12:15:26 PM EST

"Premature optimization is the root of all evil..." was said by Don Knuth

[ Parent ]
Re: rambling (2.75 / 8) (#69)
by FattMattP on Fri Apr 26, 2002 at 12:42:12 PM EST

Sorry for the rambling. Writing in this little box is a little difficult and is not nearly as much fun as Emacs
Why didn't you write the response in Emacs and then cut and paste into the little box? Wouldn't that be better than rambling?

[ Parent ]
uh huh (none / 0) (#104)
by vsync on Mon Apr 29, 2002 at 05:29:24 PM EST

One is an old fixed point version done under contract for Fullplay (which they have since open sourced). The Fullplay code only plays up to beta4 files.
Fullplay sucks. HipZip, anyone?

--
"The problem I had with the story, before I even finished reading, was the copious attribution of thoughts and ideas to vsync. What made it worse was the ones attributed to him were the only ones that made any sense whatsoever."
[ Parent ]
How about 'The Extra Push Vorbis Needs to Succeed' (4.55 / 18) (#20)
by kimmy on Fri Apr 26, 2002 at 01:44:05 AM EST

Rather than titling this article 'The Trouble With Vorbis', I'd propose taking a constructive, pro-active slant towards the issues presented. Choosing a helpful rather than confrontational approach is almost always a more productive way to get goals accomplished. Headlines and word choice do affect how the project is perceived in the community and in the world at large.

It's also somewhat hasty to presume that the Xiph.org Foundation hasn't considered the issues raised in this article. However, this may not always be well communicated to the public. One of the most helpful things for the project may be to open up dialogues and clear up these misconceptions. I think many people would be very surprised at the extent of careful thought, business planning, research, and just plain hard work that has gone into the Xiph.org effort. Rather than taking a confrontational path, ask for more information and offer input into the ongoing process. Does the public know about Xiph.org's legal research? Or its efforts to get Vorbis into hardware? Or the financial viability of consulting in the digital audio space? Probably not, but that doesn't mean that Xiph.org can't offer some of those answers or hasn't thought about those issues.

In the case of these suggestions, there are two different ways to look at them. One is to assume that the current path of Xiph.org is set in stone and to offer criticism of current group choices as a condemnation of Vorbis itself. The other way is to give these suggestions, ask for clarification on where the group stands in regards to these issues, and rally the community to help in areas which are falling short. It might just be as simple as asking, "Hey, have you guys thought about this?"

It comes down to choosing to help, or to hurt. If you take the attitude that Vorbis is destined to fail, the project isn't being helped, especially if you spread that attitude to others through factors as subtle as word choice. On the other hand, if you can help the Xiph.org Foundation fill in the blanks, whether in public communication, financial support, or development effort, then these suggestions are well worth making.

I, for one ... (3.00 / 1) (#62)
by beergut on Fri Apr 26, 2002 at 10:49:32 AM EST

... have put off ripping my CDs and setting up a centralized music jukebox at home because there hasn't been a "real", "stable" Vorbis encoder, nor a decoder I could realistically use to feed a home stereo/appliance.

MP3 pisses me off, so I haven't used any of those encoders. I've been waiting for Xiph to release a final specification, myself, so that either someone can come out with a "real" encoder, or I can knock one off myself. Sounds kinda fun, anyway.

i don't see any nanorobots or jet engines or laser holography or orbiting death satellites.
i just see some orangutan throwing code-feces at a computer screen.

-- indubitable
[ Parent ]

Huh? (3.75 / 4) (#71)
by Shren on Fri Apr 26, 2002 at 01:29:03 PM EST

The article is about a problem with vorbis. Are you suggesting that the article should have been named "Vorbis is GREAT!", had about a paragraph or two of compliments, then have two dozen paragraphs of "but" dealing with the specification issue?

The article is perfect. It introduces a problem, describes it, and suggests solutions. The supposed advantage of open source is that problems in the code get brought to light and fixed. Can't this apply to other aspects of the software engineering process, such as this specification issue? It'd hardly be 'brought to light' if the problem was buried in a pro-vorbis fluff piece.

[ Parent ]

Criticism both necessary and welcome (5.00 / 1) (#81)
by kimmy on Fri Apr 26, 2002 at 07:32:24 PM EST

I'd never suggest burying helpful comments in a fluff piece. As I pointed out, this brought out, more than anything, where the communication coming out from Xiph.org has fallen short. There is no need for compliments of any kind.

However, this article was NOT solely about the specification shortage. I, personally, would argue that the implied point of this article is, as follows:

The Trouble With Vorbis Is the Xiph.org Foundation.

The article makes several points and suggestions that are not, in fact, unaddressed by Xiph.org. The implication that Xiph.org is unhelpful, unprofessional, and shortsighted helps no one. Merely asking Xiph.org, "Have you thought about this?" would have resolved at least half of the issues raised. It's simply a more productive approach to tell the community "These people need help! It's worth helping, and specifically, this needs to be done," and to tell Xiph.org "Your product doesn't fill our needs because there aren't any specs!" Both sides need to know this information.

What are the steps and obstacles to getting a real specification together for Vorbis? That's the issue at hand, and no solutions are being offered. Short term money concerns are threatening the continued focused development of Vorbis, much less document production. The community demands a specification, fine; now help solve the problem through research, funding, code review, editing help, or any other form of assistance. This article implies that Xiph.org is a thoroughly closed entity with no room for change or new participants.

This has been a great opportunity for Xiph.org to clarify its positions and decisions. However, if this article solely wanted to address a problem, it would be phrased in such a way that actually ensured that the problem would be most likely to be attacked and solved by Xiph.org and its supporting community, rather than in a thinly veiled attack.

[ Parent ]

The name! (2.25 / 8) (#26)
by plutronic on Fri Apr 26, 2002 at 06:27:51 AM EST

Not to be trite, but 'Ogg Vorbis' is perhaps the worst name for any product/technology I've heard.

-------sig----
DeCSS
Nope (4.50 / 2) (#28)
by jonathan_ingram on Fri Apr 26, 2002 at 06:30:40 AM EST

There are two technologies here. 'Ogg' is a general container format. 'Vorbis' is the audio format. As to the names - worse than 'MP3' for example? I don't think so.
-- Jon
[ Parent ]
TWAIN anyone? (5.00 / 4) (#35)
by SnakeNuts on Fri Apr 26, 2002 at 08:57:56 AM EST

"Technology Without An Interesting Name". -Nuff said.


No man is an island - unless his name is MADAGASCAR!
[ Parent ]

TWAIN is taken (1.50 / 2) (#43)
by pin0cchio on Fri Apr 26, 2002 at 09:41:28 AM EST

"Technology Without An Interesting Name"

TWAIN is taken.


lj65
[ Parent ]
And? (3.00 / 2) (#63)
by offline on Fri Apr 26, 2002 at 11:21:04 AM EST

Somehow, i think that was the point...

Chris Rose
-----
Fly, you fools!


[ Parent ]
Indeed... (none / 0) (#97)
by SnakeNuts on Sat Apr 27, 2002 at 07:17:56 AM EST

It was. Thanks. :)

No man is an island - unless his name is MADAGASCAR!
[ Parent ]
Worst name (5.00 / 4) (#33)
by dennis on Fri Apr 26, 2002 at 08:26:43 AM EST

No, the worst product name was the eVilla "websurfing appliance." Sounds like it was made by the evil Cruella DeMille. I kept expecting it to be white with black spots.

[ Parent ]
Read some Discworld (3.00 / 1) (#37)
by eean on Fri Apr 26, 2002 at 09:02:04 AM EST

Ogg is the name of an old family in the Discworld series by Terry Pratchett series, one most notable member is a witch - she has a cookbook.

Whether thats where they got their name, I don't know.



[ Parent ]
Actually... (4.00 / 1) (#44)
by Verteiron on Fri Apr 26, 2002 at 09:42:31 AM EST

Somewhere on their site they address this, actually. Ogg, they claim, did NOT come from Discworld, however, Vorbis is named after the villian in Small Gods (a Discworld book). Why they'd want to name their audio codec after a slimeball like Vorbis is beyond me, but it IS a cool name.
--
Prisoners! Seize each other!
[ Parent ]
Becaue... (none / 0) (#60)
by Matrix on Fri Apr 26, 2002 at 10:47:38 AM EST

Perhaps because Vorbis had a very tidy mind capable of handling large quantities of information very efficiently without loosing anything?


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Not Vorbis, I think (4.50 / 2) (#66)
by Armored Scrum Object on Fri Apr 26, 2002 at 12:02:01 PM EST

IIRC, the guy with the perfect memory was Brother Brutha, not Deacon Vorbis. Vorbis was calculating, opportunistic, ruthless, and evil, but I don't think he was noted as having a good compression ratio.

[ Parent ]
Vorbis? (5.00 / 1) (#89)
by Matrix on Fri Apr 26, 2002 at 10:46:28 PM EST

Brutha had a perfect memory, yes. But Vorbis, I seem to remember, was renowned for observing a person committing a minor offense once and filing the fact away for future reference. And never forgetting it. (And the future circumstances of its retrieval usually involved a lot of threats involving sharp and/or very hot metal things) So while he couldn't remember his way out of the labyrinth, he could remember that his current opponent in the church councils on the issue of the annexation of Ephebe had skipped services three years ago on the second Monday of Grune.


Matrix
"...Pulling together is the aim of despotism and tyranny. Free men pull in all kinds of directions. It's the only way to make progress."
- Lord Vetinari, pg 312 of the Truth, a Discworld novel by Terry Pratchett
[ Parent ]

Trouble with tribbles.. (3.50 / 6) (#38)
by CaptBeyond on Fri Apr 26, 2002 at 09:14:42 AM EST

err, I mean ogg.
It's not as free as you think it is. I maintain the Open Palmtop Integrated Environment (Opie) media player, and was hoping to provide a free ogg plugin for Zaurus and ipaq on linux users. We tried the 'free' integerized code at sourceforge, but it is crap. I contacted xiph about licensing the real integerized ogg code for either myself to sell a cheap ogglib, or for a free ogglib for Opie, but never really recieved any proposals for terms. So much for professionsalism

It appears to me and other developers of Opie, that ogg is less free than mp3. Opie has an mp3 decoder, but unless licensing terms change, it will not have an ogg decoder.

That's hardly fair. (4.00 / 3) (#41)
by PFlats on Fri Apr 26, 2002 at 09:38:09 AM EST

Ogg Vorbis is no less free than mp3; rather, there is no viable and free implementation for it on a fixed-point system yet.

Xiph.org has a commercially available, closed souce, fixed-point implementation. With it comes the support a large company would want when implementing Ogg Vorbis on a portable device. This does not, however preclude anyone from making their own implemenation of a fixed-point Ogg Vorbis encoder or decoder; simply, without the complete documentation, attempts at writing such a program are hampered. Hence, Verement's article.

--- "It's not that I'm lazy, it's that I just don't care." - Peter Gibbons, Office Space
[ Parent ]
documentation (3.00 / 1) (#52)
by CaptBeyond on Fri Apr 26, 2002 at 10:27:36 AM EST

As an open source developer for many years now, the best documentation is usually in the code. so, to me, documentation is kind a moot point.
Perhaps xiph shouldn't purport ogg as a non proprietary codec, when it clearly isn't.

[ Parent ]
problem (3.00 / 1) (#70)
by vinay on Fri Apr 26, 2002 at 12:45:26 PM EST

That poses a problem, though. Most people who want to adopt a library or a format need some kind of specification that they can write their code against. That'll go much quicker if you can say, "the docs say this does that" as opposed to saying "well, I found this comment that says this.


-\/


[ Parent ]
The spec in the article.. (4.00 / 1) (#83)
by jackiem on Fri Apr 26, 2002 at 08:26:25 PM EST

Is a format specification, not a 'how to use vorbis' specification. We certainly do have API docs etc, that make it easy for 3rd party developers to use Vorbis. Due to the licensing of the reference implementation being so unrestrictive, and the fact that reguardless of the optimization claim, the code is reasonably fast, there is no need except for a very few people to write their own from-scratch implementation.

Writing from-scratch implementations is important, no doubt, but people who just want to use the code already have the documentation they need.

[ Parent ]
We want to support you (4.60 / 5) (#50)
by jackiem on Fri Apr 26, 2002 at 10:24:25 AM EST

Perhaps you wrote before Emmett came along to help us, or before the code was actually finished.

In any case, we apologize. I suggest you contact emmett@xiph.org and he will probably work out some way for you to use the Tremor code in your project.

[ Parent ]
less free than mp3? (4.00 / 3) (#75)
by Delirium on Fri Apr 26, 2002 at 04:24:23 PM EST

That's simply impossible -- integral parts of mp3 are patented by Fraunhofer, so no mp3 implementation, fixed-point or otherwise, can be legally implemented (at least in the United States or Europe) without paying license fees to FhG.

[ Parent ]
Only on the encoding phase. (3.33 / 3) (#76)
by FieryTaco on Fri Apr 26, 2002 at 05:15:03 PM EST

MP3 decoding is a fairly straightforward process and isn't patented. FhG's patents are on their psycho-acoustical model used in encoding. You can create an encoder that is patent free, it's just hard and possibly very difficult to acheive FhG quality.

[ Parent ]
Not according to Thompson (4.00 / 1) (#79)
by mbrubeck on Fri Apr 26, 2002 at 07:07:56 PM EST

At mp3licensing.com, Thompson claims that their patents apply to the format itself, even in third-party implementations. I don't know precisely how strong a legal case they have, but that's their claim.

This is worrisome to me, because I'm working on a free audio editor that includes the MAD decoder. We use the LAME libraries for mp3 encoding, but require users to download the library separately from outside the US or as part of a licensed product for fear of being sued. If Thompson starts going after third-party encoders, we'd have to do the same with MAD.

We support Vorbis decoding, and we've just added Vorbis encoding to our CVS version. Once we release this feature, we'll be heavily advocating Vorbis as an MP3 replacement. Hopefully this will make some of our users (which include a number of independent musicians doing CD mastering) more aware of these issues.

[ Parent ]

mp3 is patent-encumbered but safe (4.00 / 1) (#86)
by Delirium on Fri Apr 26, 2002 at 09:09:11 PM EST

FhG has as of late shown little interest in persuing patent infringements regarding its mp3 patents, because they see it as essentially a dead-end market. That's why, while they sued a bunch of free encoders (8Hz, BladeEnc, etc.) a few years ago, they haven't done so much as send threatening letters to the LAME team. The current interests amongst audio-patent holders are low-bitrate encoding for streaming and high-quality multi-channel encoding for DVDs. So the patents are enforced much more aggresively with regard to MP3Pro, AAC, etc.

[ Parent ]
Decoding AND encoding is patented for MP3 (4.66 / 3) (#94)
by Trepalium on Sat Apr 27, 2002 at 01:34:35 AM EST

FhG has just decided to allow decoders that are distributed without charge to use the patents without paying license fees, provided the decoder is "compliant". The patents for encoding, on the other hand, require payment. FhG also claims that Ogg Vorbis is covered by the same patents, despite the fact they say they haven't looked at it, and they also refuse to state exactly which patents are infringed.

[ Parent ]
Specification? (4.25 / 4) (#39)
by DarkZero on Fri Apr 26, 2002 at 09:26:04 AM EST

Could someone please explain what a specification is and why source code isn't enough for those of us that haven't been involved in the development of audio codecs? Personally, I'm sort of lost here, and I wouldn't be surprised if several others are, too.

blueprints (4.42 / 7) (#46)
by turmeric on Fri Apr 26, 2002 at 09:45:48 AM EST

they tell what the various pieces of a machine are, and how they fit together. software spec tells what the parts of the software are supposed to do , and how they fit together.

without it, you are flying by the seat of your pants when you try to build something. possible but .. ugh. very time consuming especially on a big project with lots of people working on it. you are never sure what is supposed to be doing what or where it goes, and you get confused and there are communication problems.

so if you want blueprints, but you only have the end product, you can use 'reverse engineering' which is taking something that has been built, and trying to figure out what the original blueprints were. then you take those blueprints and you do the building. this is what was done for the SAMBA project and probably WINE too. but its a billion times easier when you have the blueprints already.

[ Parent ]

Why a spec is needed (5.00 / 11) (#55)
by Grab on Fri Apr 26, 2002 at 10:32:04 AM EST

A specification gives the detail - in words and mathematical formulae - of what's supposed to be going on. Without a spec, you have no requirements. If you're a software engineer as a day-job, you know all about how successful a project without requirements is! :-)

An implementation OTOH only provides code which hopefully meets that spec. Without the spec, you're limited to reverse-engineering the code to find out what's going on, and you run the risk of screwing up over some implementation detail. For example, did they really intend to make a particular variable a char and is there some integer operation which depends on the char wrapping round from 255 to 0, or is it just an implementation detail and doesn't matter?

The most significant issue though is that with a spec, you can find bugs in the implementation. Without that spec, there may be a zillion bugs but you'll never find them. If you've only got the code, all you can say is that your implementation does the same as the reference code - there may be a huge gaping bug in the reference code, but you'll never know.

As an example, suppose someone handed you a car with one of the wheels missing. It looks wrong, but it seems to drive OK. However, without spending the next few months pulling the car to pieces, it's impossible for you to find out whether the car is designed to work with only 3 wheels and there's some large lead weight somewhere keeping it upright, so it's really a nifty bit of implementation, or whether the wheel has been left off by some lousy mechanic and the whole thing's a deathtrap. However, if you can read the design specs for the car and see it says "Wheels: 3 (due to advanced tyre and axle engineering)" then you can find out immediately.

Grab.


[ Parent ]
open source specification? oxymoron (2.17 / 17) (#42)
by turmeric on Fri Apr 26, 2002 at 09:38:22 AM EST

since fucking when has any open source program ever had a specification? Since when has any ever undergone anything resembling a real software engineering practice? just about every OSS ive seen has been congealed by a bunch of people who have a vague idea of what they are doing in their head, and are loathe to 'waste time' writing it down when they could be 'adding new features' instead.

Real Project, Real Engineering (4.75 / 4) (#49)
by Paul Jimenez on Fri Apr 26, 2002 at 10:08:25 AM EST

I think you're trolling, but just in case you're really just misinformed: It depends on the project - Yes, there's lots of crap, but there's also bind, sendmail, postfix, apache, and perl. Heck MAD itself is actually quite well engineered, complete with full compliance testing.

[ Parent ]
Apache (5.00 / 5) (#72)
by Brandybuck on Fri Apr 26, 2002 at 01:45:53 PM EST

Apache. Just go peruse their website and their project documentations if you want an example of Open Source projects with specifications and real softwaer engineering practices.

[ Parent ]
Exim (none / 0) (#85)
by labradore on Fri Apr 26, 2002 at 09:03:13 PM EST

In order to learn how to run it as a mail server you usually have to look at the specification for Exim. It is an excellent mail server and it sure is nice to know they have a spec.

[ Parent ]
Specification of Codec not Source (none / 0) (#99)
by SporranBoy on Sat Apr 27, 2002 at 01:05:51 PM EST

The spec being discussed is not for their IMPLEMENTATION of the codec but of the CODEC itself.

Otherwise how can one program encode and another decode?

Qmail may not have a specification but it has to conform to specifications for SMTP, POP3, IMAP etc.

[ Parent ]
Mozilla. (none / 0) (#105)
by emmons on Wed May 01, 2002 at 02:31:15 AM EST

PHP, Perl (in the last year or so), some GNU tools (GCC!), FreeBSD, NetBSD, OpenBSD, Darwin, Apache, MySQL, PostgreSQL, Samba, Bochs, Berlin, qmail, Mesa, OpenOffice, CVS, etc. etc.

NOT Slash.

I'm not saying that there isn't a ton of really shitty OSS, there is. There is, however, some really good and well organized stuff too.

---
In the beginning the universe was created. This has made a lot of people angry and been widely regarded as a bad move.
-Douglas Adams

[ Parent ]

We're on it (1.66 / 3) (#74)
by cyberlife on Fri Apr 26, 2002 at 04:17:59 PM EST

This is right up our alley.

- Milo Hyson
CyberLife Labs

[ot] Cyberlife? Really? (none / 0) (#103)
by fortytwo on Mon Apr 29, 2002 at 09:17:57 AM EST

How's Creatures 3D coming, already?!! I've been waiting over a year!

[ Parent ]
Creatures 3D??? (none / 0) (#106)
by cyberlife on Thu May 02, 2002 at 01:25:09 PM EST

Are you sure you have the right company? There's more than one CyberLife out there. We've never done anything like that. We're a scientific research lab.

[ Parent ]
Actually... (none / 0) (#107)
by fortytwo on Sat May 04, 2002 at 09:44:01 PM EST

They're called Creature labs now. But, still...

[ Parent ]
Patent Free ? I doubt it. (4.37 / 8) (#80)
by chbm on Fri Apr 26, 2002 at 07:15:53 PM EST

Intro, A few years ago I worked academically in a MPEG1 Audio codec. I started with the Fraunhofer reference code base and improved on that towards eficient code to run on a DSP. As not only I was potentially infringing Fraunhofer copyright but also several patents I decided to look into it. I'm not anything near a patent lawyer, i'm an EE.

When I first heard about Ogg/Vorbis I got excited about it. I started reading about it, code and technical docs. Then I realized I was reading about a respin on mp3 (which in turn was a respin on various codecs used to compress voice among other things). The block diagram was similar to the block diagram on ISO11172-3, it used a similar polyphase filter bank, a similar MDCT, a similar allocation loop and a psychoacustic analisys.

Yet Xiph claimed Ogg/Vorbis was unencunbered. But Thomson and Fraunhofer held patents on the block diagram, using a polyphase filter bank and using a psychoacustic model. There are tons of patents on DCT, the MDCT variations and FFT algorithms (needed for the the psy analisys). My conclusion at that point as Xiph was plain ignoring what I myself considered the 'stupid patents' and was just focusing on the patents that had sound claims, the 'implementation' patents like the MDCT implementation and the psychoacustic models. That of course meant Ogg was no less encumbered than mp3. If Ogg was free so were the later versions of LAME (*) and inded was possible to write a free mp3 encoder.

I didn't quite follow the Ogg development but from what I seen it didn't changed radically, honestly there aren't a lot of ways to do an audio high performance coder nowadays and the MPEG board made sure they hold patents on half of it (the Dolby crowd are still fighting them for the other half :\). I don't expect the Ogg developers to discuss patents openly as from my discussions with people involved in patent work in the USA I learned engineers aren't allowed to read patents. Engineers who read patents get tainted and became their patent lawyers worst nightmare. This rule was of course created by patent lawyers who decided there need be an army of patent lawyers to evaluate the finer technology points of patents which engineers aren't obviously qualified to do.

All in all I wouldn't touch Ogg commercially with an offshore corporate shell company without a very tight paper signed by Xiph saying "we hereby declare company Foomatic is licensed to use all IP needed for its Ogg/Vorbis product. Xiph takes all responsability for all patents that cover the format" or however that's spelled in weasel speak. This is pretty much one of the sugestion made in the article, if you're so sure it's patent free put it in writting and take responsability for it.

(*) There was a crackdown by Fraunhofer and Thomson on at least 3 'open source' mp3 codecs 3 to 4 years ago. They didn't use patent infridment but copyright infringment of the shared codebase all used, a reference Fraunhofer implementation (the same I used). LAME started out as a patch to that codebase (dist10.tgz) but the latest versions claim to be Fraunhofer free.



-- if you don't agree reply don't moderate --
You aren't a lawyer, as you said. (4.50 / 4) (#82)
by jackiem on Fri Apr 26, 2002 at 08:22:54 PM EST

We're not ignoring any patents. Sure the diagram may be the same, or the patent abstract may sound frighteningly broad, but the reality is that it just doesn't apply to Vorbis.

You can spread the FUD all you want, but people should put their trust in the lawyers on this one, not the casual patent readers (no offense intended).

[ Parent ]
FUD and lack of trust. (4.80 / 5) (#88)
by bodrius on Fri Apr 26, 2002 at 10:41:40 PM EST

That would be an even better reason for Xiph to provide the insurance both the article author and the parent poster talked about.

The fact that this person doesn't trust the patent-free claim is not going to change just because someone reinstantes the claim not to be ignoring any patents.

Whether this person "spreads the FUD" or not, the FUD is there. And unless there is some mysterious reasons why this person wants to "spread the FUD" for evil purposes, his FUD happens to be opinion, which might be representative of experience and he has the right to spread to his colleagues.

His FUD is not based in misinformation spread by someone else, but in the lack of information provided by Xiph. Without clear information differentiating Ogg Vorbis from those patents, and with the only information being, as you say, very similar and/or broad and vague, there is no reason for any professional or businessman to trust their product to Xiph's claim.

FUD is not always manufactured. The point the article seems to be making is that the lack of a reference implementation is, indeed, creating FUD that blocks the format's acceptance.

This FUD might even be the common state of mind among certain circles, which I think was the point of the poster.

After all, if someone says publicly that they wouldn't touch Ogg Vorbis because they're not willing to put their money at risk based on Xiph's good intentions, it might be more useful to wonder how many people are doing the same thing more discreetly, and telling their colleagues about it.

The way to fix this is not to accuse them of not trusting you. Of course they don't. Give them a reason to. Take the legal risk off their shoulders (or give them the docs to prove there is no legal risk).
Freedom is the freedom to say 2+2=4, everything else follows...
[ Parent ]
not really feasible (none / 0) (#95)
by Delirium on Sat Apr 27, 2002 at 03:46:33 AM EST

It's not feasible to take that sort of legal burden -- even if they're 100% in the right, it would mean they'd have to defend all the lawsuits, if there are any. Even major corporations usually don't do this -- if I license something from IBM, they generally don't agree to bear the responsibility for patent infringement, unless I specifically negotiate that (for quite a hefty extra fee).

[ Parent ]
FUD, in a way yes. (none / 0) (#100)
by chbm on Sat Apr 27, 2002 at 01:59:29 PM EST

This FUD might even be the common state of mind among certain circles, which I think was the point of the poster.

Fear, Uncertainty and Doubt, I have all of those. If I was working on DSP stuff now, my boss came to me and asked me to evaluate the IP claims on Ogg I'd say "No" considering the information I have now. Plain and simple, I wouldn't sign my name under a report saying Ogg/Vorbis is patent free. And I do believe my opinion is shared by some of the people on the field, which makes you exactly correct.

That is of course my technical opinion as an engineer, please do rebate it with real arguments if you disagree. There's nothing I'd like more than see Xiph be right after taking a peek at the MPEG world.

-- if you don't agree reply don't moderate --
[ Parent ]
Ogg is less free than MP3 (1.00 / 6) (#87)
by estimate on Fri Apr 26, 2002 at 10:40:32 PM EST

And everyone in the OggVorbis cabal knows it. We are being mislead. As soon as Ogg takes hold and MP3 is a rarity, expect the IP lawsuits, GIF-style.

The Fish Club (4.37 / 8) (#93)
by Idioteque on Sat Apr 27, 2002 at 01:14:54 AM EST

The more I learn about Ogg Vorbis, the odder things seem over there in xiph-land. First let me say Rob is absolutely right about everything he said. He's not ranting, just stating the way things are. I'm starting to realize that the Vorbis world is very small, not necessarily the user-base for which I have no information, but the developer community (I know Emmett or Jack will reply within minutes with a litany of all the "game developers, blah blah, etc. I just sold the fixed point decoder, etc...") And appartently Monty, the only guy with the brains to do any of the actual nuts and bolts of Vorbis, is always very busy, although the CVS logs would say otherwise. Why do I take this tone of sarcasm, because at least this developer/vorbis user is annoyed, this project has a chance to do something great, and its being mishandled and misdirected.

The only person who could write a complete specification on Ogg Vorbis is Chris Montgomery, the rest of us would just have to guess, because he's the only one who knows it completely, there is no Alan Cox character to help out, just one guy on this project. Yeah, there are people who can tell you about certain parts of Vorbis but none of them could write a complete specification in a timely manner.

But I can tell you the all important Ogg Vorbis COMMENT specification is almost complete, thank God for that, a great debate on the vorbis mailing list ensues on a weekly basis about how to TAG a song that has twenty parts, five movements, was written by on guy, performed by another and conducted by El Dorkus. So everyone has their 2-cents on comments, but no one says on a weekly basis, hey how's the spec going Monty! If this thing's going to work we need a spec, or at least a working rough draft, sooner than later. No, not that out-dated incomplete-stuff you have on the web-site. And no, reference code is not enough, and even if it was, the vorbis source code is not easy to follow and it is very poorly commented, well at least the important parts are poorly commented....hmmm, I wonder if that has anything to do with patents....

I know the, "Hey it's free, don't complain" response is probably in some of your heads, well, I've donated, and I try to promote Ogg Vorbis so the least they (Monty) can do, is give me and everyone else a specification.

And the interesting part is I've noticed the xiph guys are always very quick to defend themselves on k5, /., which initially seems good, but now, I wish they would spend less time typing on K5 and /. and more time on the specification...since they don't have any time anyways....right?


I have seen too much; I haven't seen enough - Radiohead
What I think. (4.50 / 2) (#101)
by /dev/trash on Sun Apr 28, 2002 at 01:29:31 AM EST

If Ogg Vorbis is to be the next thing or at least be more mainstream it needs to be used in more hardware player apps. This is where the Mom and Pop shoppers are going to notice.
For example, if on the box it says "Holds 120 mp3's or 160 ogg's." I'd bet that 9/10 would load oggs on to the device, especially if the device came with software to convert wav to ogg.

---
Updated 02/20/2004
New Site
That's actually a catch-22 situation. (none / 0) (#102)
by static on Sun Apr 28, 2002 at 10:44:10 PM EST

I've been watching the list for months now. The hardware makers are reluctant to support Ogg Vorbis because they say there's not enough market. But there's not enough of a market because they don't support Ogg Vorbis. :-/

Wade.

[ Parent ]

The Trouble with Vorbis | 107 comments (103 topical, 4 editorial, 1 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!