Xiph.org Releases Free Fixed-Point Vorbis Decoder

volsung writes "A lot of us want portable music players with Vorbis support, right? Well, Xiph.org has decided to help speed the process by releasing their integerized Vorbis decoder, named "Tremor," under a BSD-like license. Tremor is a Vorbis decoding library written for CPUs without floating point hardware, like most handheld devices use. It was previously a proprietary library--licensed by theKompany for their Sharp Zaurus player, among others--but now it's available for everyone to use. The release page also gives contact information for many of the popular hardware manufacturers. If you want Vorbis support in your hardware, now is the time to send some emails! (Also, please say thanks to the Xiph.org crew with a donation if you can.)"

Comments

2 Questions

[Buck2]

I was wondering if someone with more relevant knowledge than I might make an estimation about how much more quickly we might expect to see Ogg support now that this has happened. Are embedded chips without FPU really that much more prevalent, or are they just that much cheaper?

I also wanted to know, on a side note, why the hell portable mp3 players don't come with a damn FM tuner in them. Is it a design/form factor issue? Perceived marketability problem?

I want to use my mp3/ogg player while at the gym ... listen to Howard Stern and then switch to music when it gets dull/commercials. Is this so complicated?

Re:2 Questions

[AT]

The Intel StrongARM chip is pretty popular in embedded devices, including the Zaurus, iPod and other PDAs and portable music players. While the chips have an excellent power consumption vs performance and price ratio, it lacks a hardware FPU.

I'm not sure companies choose the StrongARM because it's cheaper than chips with a FPU. More likely, they choose it because it is supported by GCC, Linux, Windows CE and hundreds of commercial tools. It is low power, widely deployed, and relatively powerful for a low power chip. And having Intel behind it doesn't hurt. In short, it is a very low risk platform with significant advantages and a few minor disadvantages (no FPU).

Nice, but I hope they stick around

[IamTheRealMike]

This is good news, but without a big corp behind it I'm sceptical about whether hardware manufacturers will adopt it. What I'm more worried about now is Xiph themselves though. They've done a great job, and given us this fantastic gift, but now how do they make money? If the library was originally proprietary, then what do they have now?

Re:Nice, but I hope they stick around

[iabervon]

They're contractors. They wrote this on contract for someone, and the contract allowed them to give it away after a while (IIRC). They weren't selling this in the first place. They wrote the floating-point vorbis, and then they were contacted by a company who wanted a fixed-point version and were willing to pay them to write it. Now they're giving away the fixed-point version in addition to the floating-point version, and probably working on other stuff for other people, with a similar deal.

It's like working for a software company. Once you've written something for them, you give it away (to the company); you continue to make money by getting paid to write more software, not being paid royalties or paid for licenses for the stuff you wrote previously.

you really gotta love that BSD license

[TechnoVooDooDaddy]

I know that everyone is down on the BSD and up on the GPL, but we owe a tremendous amount to the BSD license.. Companys (like microsoft) took up stuff like the TCP/IP stack, BIND, etc..

and I believe OGG will achieved the same popularity and extension that it's other BSD Licensed bretheren enjoy. It's gotta be the freedom of the BSD license that encourages companys to pick up on this stuff, rather than re-inventing the wheel with yet another standard because they don't like a particular clause or so in the license..

Processor requirements?

[dschuetz]

Does anyone familar with this implementation have any idea how processor-heavy it is?

I ask because people have played with an earlier floating point implementation on the Rio Receiver, and have found that it wasn't terribly usable. I'm a little short on details, but I think it was too intensive for the low-speed CPU in the receiver.

On the other hand, there has been work to build replacement clients for the Rio Receiver that use FLAC lossless compression, and that apparently works pretty well. So the current thinking is to transcode .ogg to flac at the server level. Or just to rip everything to flac (which requires a whole lot more disk space. :( )

Re:Processor requirements?

[zsazsa]

Does anyone familar with this implementation have any idea how processor-heavy it is?

Using tkcPlayer on my Sharp Zaurus (which uses this library,) Ogg Vorbis playback takes up less CPU than mp3 playback (and the .oggs take up less space - it's a win-win situation.)

Re:theKompany is screwed (not)

[Anonymous Coward]

Actually not at all. We didn't pay a big licensing fee for Tremor and this came about before we paid any royalties, so it works out just fine for us. We love Xiph and Ogg Vorbis and have lots more stuff coming along to continue working with them. We have a nice easy to use and multi-platform (later this week) ripper for Ogg Vorbis called tkcOggRipper which you can check out at www.thekompany.com/projects/tkcoggripper. We also have an entirely ogg based internet radio station coming online shortly at www.progrock.com - we ripped about 350 CD's using tkcOggRipper, and we have even more fun stuff ahead.

Rock on Xiph and may Ogg Vorbis rule the day!

Shawn Gordon
President
theKompany.com
www.thekompany. com

Both Licenses are Excellent

[FreeUser]

I know that everyone is down on the BSD and up on the GPL, but we owe a tremendous amount to the BSD license.. Companys (like microsoft) took up stuff like the TCP/IP stack, BIND, etc..

The BSD License is an excellent license for some things, just as the GPL is an excellent license for other things.

OggVorbis is one area where the BSD License makes perfect sense, namely, in an effort to get a published, open format implimented as widely as possible.

The GPL is an ideal license for persons and companies that wish to make their code available and participate in a public commons, without unconditionally handing their crown jewels over to a competitor. Indeed, there are many commercially written programs whose source code likely wouldn't have been released at all, or would have been released only under really onerous restrictions, such as Microsoft's so-called open license, Sun's community license, or something along those lines.

Both licenses are excellent. Both philosophies are a positive contribution to the intellectual wealth of humankind, and both have their place. Which one is most applicable to a given set of circumstances depends largely upon those circumstances and the goals in mind.

In this case, the goal is to spread the use of Ogg Vorbis as far and wide as possible, for which the BSD license is ideal. Indeed, even the FSF, which normally has strong reservations with regard to the BSD license, has endorsed the release of OggVorbis under the BSD license.

Re:Both Licenses are Excellent

[John Whitley]

Excellent points. In this sense, a BSD-like license seems to be more appropriate than GPL/LGPL where the promotion of an open software-based standard is more important than any single codebase that implements that standard.

I'm a firmware engineer in this market, and this definitely lowers the barrier to entry for companies who would previously have had to implement a custom Ogg Vorbis codec. Such a project would have been very expensive to undertake, probably prohibitively so. (both in the development cost and in the lead times to a QA'ed and marketable finished product.)

Give feedback to Apple!

[binaryfeed]

Please tell Apple you want Ogg Vorbis support in the iPod.

Re:Give feedback to Apple!

[John Whitley]

At last, someone with the right idea. The embedded digital audio space is a volatile new market, with a bunch of relatively young companies and/or young divisions within large companies (which is much the same thing for my purposes here) vying for marketshare. Feature sets end up being defined in two general ways: 1) via feedback about a shipping product (market success or failure, direct user feedback, etc), or 2) marketing gets the idea that customers Must Have This Feature. User feedback can make a difference in this latter model.

Ogg isn't yet big enough on its own to be an automatic target for these electronics marketing divisions. It needs grassroots backing to give it the same boost that MP3's mindshare and Micosoft's market power (WMA) have done for those formats already.

This codebase makes this grassroots effort VERY VIABLE. So write your favorite digital audio portable company (be brief -- you're talking to marketing) and ask for Ogg Vorbis support. FWIW, Apple's design prowess made big waves in this industry. If Apple adds Ogg it, it's very likely that it will become a bullet on everyone else's next product feature list. (Note: the iPod uses an ARM-based processor.)

AudioTron support for Vorbis?

[Wee]

Does anyone know if there's planned AudioTron support for Vorbis? I spent a long time looking through their site, the discussion boards, etc this weekend and found nothing. I don't even know that it's possible via a firmware upgrade.

I don't care about portables, it's my home system I'm curious about. XMMS I don't so much worry about, but I'm not going to replace hardware. What I have works for me, and if I have to use .mp3 with it, then I will, no matter what license the format has. I suspect a lot of people that have bought and are using MP3-only hardware feel and will act the same way, at least until that hardware gets replaced. mayeb what we need is for new hardware to decode both formats? I could see phasing in Vorbis decoders as being easily doable.

I really wish OGG would have been around (read: taken off) like in 1997...

-B

Well, integerized moving point, actually...

[xiphmont]

Strictly speaking, this isn't 'fixed-point' although it is all integer. It uses primarily fixed point, but in the deep S/N vector paths, it uses integerized movable point in a way that most embedded architectures can do the shifts for free during ALU load (eg, look at the ARM assembly for the shift/multiplies). Have a look at the Vorbis codec spec on xiph.org if you want to know why this is necessary.

Also, this code's been around for a while... we're releasing it for free now as commercial code has a short shelf life. It ran through it's commercial usefulness, and now we want it to be commodity code.

Monty

Oooh, I'm cranky and haven't had my coffee yet

[xiphmont]

>> A lot of us want portable music players with Vorbis support, right?

> Uh, no, seeing is that I haven't heard of Vorbis until now.

Mmm, this begs one of a few responses:

1) "Gee, you don't care. That's nice. You must be talking to hear yourself talk, then."

2) "Really? I'll tell you what Ogg is if you explain to me why I was supposed to get all excited about Jessica Simpson."

3) "[rolls eyes] Not need respond to rhetorical question, Grog."

4) "Quick! There's another parade to rain on over there! Hurry up, you'll miss it!"

Monty

"All in good fun until someone loses an eye. Then we're talking serious fun."

Yes, yes, there have. Try leaving the cave.

[xiphmont]

Your point would in fact be insightful (that only the quality matters, and quality is a hard problem) if you had looked around for a few tests first.

Start here: Hydrogen Audio

No, that's not us (Although we like them as they're likely the least bullshit-laden codec comparison and development bulletin board out there. These guys were *very* harsh about Vorbis's quality the first few years. That feedback was invaluable for making the codec as good as it is today.)

c't has also run tests including Vorbis, and will have a big test run on several thousand listeners to offer here sometime soon. It's basically a much larger version of the tests ff123 has run on Hydrogen Audio. We're not privy to any of the current results, but I expect we'll do just fine ;-)

As for 'cranking it out', Ogg development started in 1993.

Monty

Re:Isn't this odd.

[volsung]

Actually, no one cares if Fraunhofer (actually Thomson is the one managing the money end) charges for their decoder software since almost no one uses it anyway. On the other hand, people are a little perturbed that you still have to pay Thomson for a patent license even if you write your own decoder.

This is not the case with Vorbis. Xiph.org decided to charge for Tremor in the past, but there never was (and never will be) any restrictions on third-party encoders/decoders. Another person wrote a free integerized Vorbis decoder while Tremor was still proprietary, (though there were some concerns at the time about whether the decoder would produce output equivalent to the floating-point decoder). The Vorbis format is completely open and not hindered by patents, whereas Vorbis software can be licensed however the author wishes.

Which vorbis is faster on Intel?

[iabervon]

Is the original libvorbis faster (due to making productive use of the FPU), or is the new integer math one faster (because floating point is pretty slow in general)? I'd guess that libvorbis is better on Intel and tremor is better on non-Intel x86 (due to the relative strengths of different vendors), but it's hard to say. Has anyone actually benchmarked them? libvorbis is a noticeable load on one of the machiens I use, so it would be worth switching if it would help.

Re:Strange things are happening ...

[xiphmont]

The mail archives didn't disappear; they were never there. I made a permissions error in the archive spool after fixing a log rotation bug :-( None of May was logged.

The previous non-Xiph fixed-point decoder releases are derived from a flawed 'good enough for now' port of Vorbis to the HipZip originally done by iObjects/Fullplay. This port was a quick integerization of beta 3 done in late 2000 and has signal depth problems. It does not decode later-than-beta-4 files. Even if updated to full 1.0, it will still have dynamic range problems when playing 1.0 and later bitstreams.

Tremor was originally done as a report to ARM at the request of Fullplay after determining that starting from scratch was easier than repairing the existing beta-3-derived code. Fullplay opted not to purchase the new port, and eventually released their own beta-3 port under GPL on SourceForge. Those who then derived their own versions from the SourceForge project were generally aware that this was an incomplete 'good enough for now' version and that the code would eventually hit bitstreams that it couldn't play well or at all.

Now that Tremor is BSD, there's no reason to keep using derivations of this old beta-3 port.

Nothing strange about it. You can go back to chasing government UFO conspiracies now....

Monty

Re:Performance?

[xiphmont]

The original target for Tremor was a 74MHz Cirrus Maverick (ARM 7 TDMI core).

Monty