The Future of Ogg Vorbis

Brett writes "The author of MAD, the fixed point MP3 decoder comments on what is wrong with Ogg Vorbis, with a response from jack, one of the founders of the format. "Ogg Vorbis may be the holy grail of patent-free audio compression, but there are some serious issues blocking its path to widespread acceptance. Unfortunately most of us are powerless to correct the situation; the problems must be addressed by Vorbis' creators. " The rest of the of the story is currently running on K5." And Jack's response is enlightening as well.

Comments

Mentality

[jeroenb]

From the Vorbis guy's response it's clear what the problem is: The idea is great, the plan is good, but the deliverables just take time to materialize. Nothing bad about that, it's true for practically every piece of software (or related, like the Ogg Vorbis specification.)

Regardless of whether the author of the K5 piece is right about the points he discusses, the Ogg Vorbis creators should take his criticism to heart instead of dismissing it. It's not about whether all those points are valid, so trying to prove that they are not doesn't accomplish anything. They should understand that apparantly they have a problem communicating their plans to their possible supporters from the development community and that what they are doing apparantly makes a strange impression.

They should be glad someone took the time to actually write this down and complain instead of just forgetting about their project and doing something else.

Re:arrogance

[Zachary DeAquila]

Actually, I got the impression that the author was very frustrated at trying to do an independent 'from-spec' implementation of Ogg... which is impossible since there's no spec.

Code defines an implementation, not a specification, and using code as a spec leads to 'bug compatible' further implementations (ie. Yeah, that's feature's done really poorly, but it has to in order to be compatible with the bug(s) in the original)
This is ungood.

--Z

Re:The author of that article needs some cheese...

[Zachary DeAquila]

What kind of embedded system would have an Ogg player? How about a car stereo? Like, say.. an empeg? Which doesn't have a much in the way of CPU, including the fine lack of a floating point processor?

wtf?

[SuiteSisterMary]

In regards to the standards bodies, there are really two well known ones, the IETF and the W3C.

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?

Most embedded systems don't have an FPU

[pslam]

See my comment here.

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

[Skuto]

>Nobody is going to fit an expensive and battery draining processor into their product just to support an extreme minority codec.

>By using floating point for the algorithms, libvorbis is ruled out from nearly all embedded
>devices. At the moment it pretty much only runs (in real time) on PC/Mac systems.

The 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

Too little, too late

[NiftyNews]

The problem with OV is that it doesn't make enough of a jump in compression from its predecessor, the MP3 format.

MP3s will continue to rein supreme, Iron Chef style, until someone releases a new compression algorythm that saves at least 10x more space. It is too much work to convince MOST people to use other forms of music compression when there is negligable savings (in quality and size) for the average user.

Reasons

[moonboy]

• The name. Cool for geeks, but for the general public, it sounds funny. It gives no indication whatsoever about the product and what it's used for. Granted 'mp3' isn't much better, but that leads to the next point.
  
• mp3 was "first to market". It is deeply entrenched .
  
• Ogg may be better sound quality-wise, but for the majority of mp3 users, mp3's "sound good enough" and Ogg doesn't offer enough of an improvement for people to encode all of their stuff over again.
  
• Yes Ogg is FREE but again, the average Joe could care less about Free or Open Source software.
  

Sorry if I sound like I'm trolling. I'm not. I'm just being honest.

Specifications more important than Implementation

[inquis]

What I'm going to say is what software engineers already know.

The specifications for software are much, much more important than your implementation. If the specifications are written completely and well, the design of said software project will "fall" from the specifications, and the implementation will "fall" from the design. "Specification" isn't something you can do after-the-fact; at best, you will have an incomplete specs document (because of developers who incompletely document their own code), and at worst you will have WRONG specs (because a developer makes an innocent typo that doesn't get caught).

Sure, the ogg stream format and the vorbis audio format have been frozen for a year; however, code is not self-documenting. One of my wisest professors said that the only man he has known that writes self-documenting code is Knuth, and you might be a good hacker, but you are NOT Knuth. Every mortal man needs specifications and design documents to be able to make ANYTHING out of ANY piece of code; hell, I have some relatively simple Java apps I hacked together six months ago that would read like Greek if I didn't have my specs and my design documents.

How can anyone expect to reasonably use an undocumented format?