Slashdot Mirror
Ogg/Vorbis on Palm OS
loshwomp writes "We have built an audio player for Palm OS, and a public beta is available now. The beta includes support for Ogg/Vorbis audio, and a future beta will include plug-ins for more formats, as well as the plug-in SDK itself."
if your palm uses smartmedia or compact flash cards than you can store up to a gig of music depending on how much money your willing to shell out. more info here
The Blade Itself
but it's still good to see it on the palm as well.
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
The main stumbling block to Vorbis implementations was that the reference decoder was floating point intensive, whereas MPEG decoding can be done with mostly integers. However, there's now the "Tremor" reference decoder which uses purely integer math.
It's not really that difficult of a format. The only real oddity is that you have to buffer in the first few Ogg pages quickly in order to set up the codebook and other Vorbis headers, whereas MPEG uses discrete frames; but, once you've got the headers parsed, Vorbis is a relatively straightforward format.
From the article:
"AeroPlayer presently runs on Palm's Tungsten T handheld."
The Tungsten is pretty beefy. It's got both a high speed ARM925 processor and a high-speed DSP in it.
There are two answers to your question. First, the new Palm OS v5 was designed to run on much more powerfull processors. Second, there was a problem for a while with ogg not having a integer only decoder algo. Lots of pdas aren't equipped with a floating point unit, so that was a real show stopper. Well, not anymore, since the integer version of the decoder is now also available with an open license.
But as the author's website clearly states, this program is intended for Palm Tungsten T (PalmOS5) devices. The Tungsten T utilizes a 175mhz (clocked down to 145mhz) enhanced ARM-based CPU called the OMAP from Texas Instruments (I believe), and compares to a PocketPC device running PocketPC2002 on a 200mhz StronARM or 400mhz XScale processor.
;)
It is plenty good for more than "spoken word stuff"
NO NO NO NO NO NO NO NO NO NO NO
Do NOT convert mp3s to oggs, or oggs to mp3s, or any lossy format to any other lossy format. All you end up with is super crap, with super crappy artifacts from both encoders. Only encode from originals. If people start doing this, there will be tons of horrible ogg files and ogg will get a bad reputation.
If you mean reencoding from the original source (CD's) to ogg, well then ogg should be as good or better than mp3's.
If you mean reencoding your mp3's to ogg's, well then you're going to degrade them by a huge amount. The artifacts you had from the mp3 encoding won't magically dissapear just because you reencode to ogg - you lose information with every pass. So in the best case you'll have lost all the info that the mp3 and the ogg encoding throws away. But it's probably going to be even worse than that.
It's taking a jpeg and compressing it again in your favourite photo editor. It'll look like shit.
So, if you do it, be aware of it. And don't give those oggs to other people, since that way they'll get the impression that oggs sound intrinsically worse than mp3's.
Let's clear up some things to stop the inundation of amazingly stupid posts. This software DOES NOT work on Palm's running OS 4 or below. It only runs on the new Tungsten T, which uses a 200Mhz ARM processor, and runs OS 5.0. The Tungsten T also includes expansion for memory cards, and has a headphone jack, making it quite useful for music. In fact, Palm is expected to release some sort of MP3 player for the device, but did not include one because it was not something "the target audience wanted."
So please no more of the "wow, decoding music with a 33Mhz processor would never work," "wow, I can hold two songs in my 8MB of RAM," etc., etc. comments. You are right, the old Palms WILL NEVER play music files; it is simply infeasible.
"Average palm" doesn't count, since an "average palm user" wouldn't give a damn about OGG support. Those who do give a damn, though, probably have 128MB or 256MB MMC or SD cards on their Tungstens (note: the beta supposedly only works on Tungstens for now), so they can fit quite a few OGG files on those :)
I'm guessing that the deal is that Sony isn't releasing the specs of its Clie line, so the author can't make his application run on them. We're probably supposed to mail Sony to complain about this.
-Enfors-
Three fair questions. Answers, respectively, are "a small collection of Palm OS and Vorbis enthusiasts", "yes", and "by submitting it here".
Free bonus information:
The memory space in palms, even from the early days, was based on 'cards'. The memory built into the palm unit is all addressed as card 0 (even though you could not remove this 'card' of memory without some soldering!) Palm did this because they envisioned a day when additional memory or other resources would be added to a palm.
With the 500 series, that day finally came. With the 500 seris, an additional card slot is available, card 1. (The same holds for the *VASTLY* superior Sony Clies, which use their memory stick technology.)
These cards in the M500-series can be up to about 32MB for the expensive ones. A recent break through in memory production might double this. (This is the same old story about memory!)
For the clie line, the memory stick cards can hold up to 128 MB. This of course will double in a short while.
This compares with about 16 MB max on card 0 for the M500 and clie NX series. Why is memory so limited on card 0? Well, it's all about battery life. The reason people like palm so much is that they sip batteries (or at least used to before color screens). You used to be able to go weeks between recharging. Even with color screens, you can go a week or so before a recharge becomes critical.
Since palms use trickle DRAM to keep memory fresh, 16MB of memory means that you need to keep draining the battery EVEN WHEN THE UNIT IS TURNED OFF. (The processor, however, is not using significant power in sleep or doze mode.) Not much power is used, but it adds up. Now, if you had 128MB of ram in a palm unit, all with trickle DRAM, the unit would have a fraction of its current battery life--enough to make the device a real nuisance! Some people might like much memory, but they probably would be using their battery to refresh unallocated parts of memory anyway.
So, palms tends to have small memory card 0, and have long battery life. Palm made the judgment that people need about 16MB. Sony came to the same conclusion. Somewhere, the marketing people talked to the engineers and UI folks about how much memory is needed, how often recharges would be needed, etc. etc. In fact, Palm is so strict about this that for the Zire (their $99 'entry' palm), they downgraded the memory to just 2MB (what they estimate you'll need for its intended uses) and nixed the color screens. The result: a unit that guards Palm's tail end market from competition from the cheapo Franklin pda-units.
Is this important? It is for many people. I know plenty of friends who own an iPaq, and they can only use the device full-out for part of a day. (If you are chained to an outlet, why not just cary a small vaio or something?)
So, yes, there's not much dram on a palm unit. But, there are non-volatile memory cards available, and they're getting cheaper.
That being said, it should be noted that palm is, in my opinion, a f*cked company. They've lost market share, from 90% to 50% and falling. And now, there's actually competition from many players. They actually did a _reverse_ stock split to avoid delisting.
Plus, they *ROYALLY* pissed people off with the M505-->M515 bug, and by failing to issue a recall on the 505s. Palm's only chance, in my opinion, is in the Palm OS 6. They promise that Palm OS6 will be for Palm what OSX is for Apple--revolutionary.
If it's not, they've got jack sh*t to offer, and will have to compete with Microsoft. They're toast!! Oh, one more thing. Why does *every* damn story have to link to even the most basic URL. Like when the link to a story in the Register, there's a link to the story.... and in case you have bricks for brains, they also have a bonus link to the Register home page. Moronic.
Ok, my pizza is finally here. I'm done babbling.
It's true that traditionally Palm's own PDAs have been associated more with "productivity" than "multimedia", but that doesn't mean that adding in multimedia features makes it a toy. For me and for many others PalmOS is simply the superior platform to PocketPC2002 because of speed, speed, speed.
A month or so ago I contemplated upgrading from my Palm m505 to either the Tungsten T or a PocketPC. I borrowed a PocketPC from a (generous) friend of mine since I hadn't used a PocketPC device before and wanted to know first-hand what it was like. Suffice to say I wasn't blown away.
Sure it was nice to play DivX videos while commuting, but for REAL use - the stuff *I* do every day with my PDA - PocketPC simply felt too.. weird. At times it was slow and most of the time I had to go through more loops than on Palm to get something simple done. I used third party PIM software, mind you, just like I do on my Palm.
For ME, Palm simply works better. And if in the end both PocketPC and Palm devices can be used for the same things (PIM, multimedia, games), why would I choose the platform that gives ME less satisfaction?
Hell, that goes for EVERYONE. If Palm devices don't "do it for you", would you still buy them? I wouldn't. I'm just glad I got to try the PocketPC first hand, because before that the only information I had on the platform was what I had read elsewhere. NOTHING beats hands-on experience. Even if that experience isn't quite what you had imagined.
Please tell me, when you say "converted," that you did not transcode from mp3 to ogg.
As an experiment I converted a 320Kbps mp3 to 160Kbps (Q5) ogg. They both sounded exactly the same through my crappy speakers.
As soon as I hunt down an old pair of walkman headphones (for the mini plug) I'll cobble together a mini-plug to rca patch cord and hook up to my stereo. Maybe then I'll hear a difference.
'Intellectual Properties' are uncontrollable in the wild. To base an economy on them is just stupid.
any jackass could have done this port in, oh, 5 minutes.
the palm tungsten t uses a texas instruments omap cpu. the omap is not just an arm. it is an arm-9 and c5500 dsp core on one die (what they call a dual-core). they share memory and dma channels and a special message-passing bridge, which makes it much easier to program and debug.
an omap can decode mpeg 2 at 640x480 at 30 frames per second. the arm 9 itself is fast enough to run the ogg tremor integer decoder without the dsp (i've seen it run on an arm-7 @74mhz, although it eats the entire cpu on that one).
the only thing it needed was user interface/io code and recompiling the tremor libraries. this is not much of a story, as any palm programmer could have trivially done this port.
Well, the answer is: you shouldn't.
.OGG file into internal memory and use it as you normally would. You put these files on memory cards such as SDs and MMCs or with Sony devices, Memorysticks, and then use a program to access the files.
And you couldn't even if you wanted to. Palm's internal memory is used through a Palm-specific file system (PRCs and PDBs), and it can't handle "regular" desktop file formats. Hence, you CAN'T put an
not totally true. it will run native arm code but as of yet the build chain hasn't been release.
According to all the information I have seen from Palm, PalmOS 5 will not run ARM-native apps ever--there simply are no ARM-based system call entry points in the kernel. What it will let you do is put ARM subroutines into 68k code, and the only build tools Palm has promised for that is for ARM assembly.
There's your problem, right there. RC3 had a shallower bitrate curve for the lowpass filter setting because it screwed up the SBR a bit (a bug, since fixed).
Ogg Vorbis 1.0 (xiph.org libVorbis 20020717) is dramatically better than the previous versions, right across the bitrate range.
It handles low bitrate (q0 - nominal 64kbps) often better than anything else (mp3pro is sometimes better for classical music, but that's it, aac and wma9 blow goats in comparison - mpc is a contender only at high bitrates). Medium bitrate (q3-4 - nominal 112-128kbps) is the best of breed, too, for many people and sources it is CD-transparent (though not always) - the difference isn't as big but Ogg still wins out.
Vorbis 1.0 hits CD-transparency for virtually everything at around q5 - nominal 160kbps. q6 (192kbps) provides a safety margin for extremely difficult material according to the plots, but I totally fail to hear the difference in ABX tests. I've got diskspace, so I rip at q7 - Ogg Vorbis audio is "peelable", so you can reduce the bitrate, without transcoding, to the quality it would have been had it been encoded at that bitrate, and no less (something no other widely used audio codec can do, and possibly the start of a revolution in bandwidth-adaptive, buffering-free streaming, beyond Icecast).
Please always use the quality mode, not the managed bitrate mode unless you are actually streaming. You shouldn't have any quality complaints with Vorbis 1.0 unless you want to encode 6 channel audio (i.e., AC3 transcoding)... and that will be fixed in time, too.
Ogg 1.0 contains many improvements over RC3, not only in terms of quality but speed. The hi-fi forum hydrogenaudio.org has a running poll which shows most Ogg users encode at -q 6. This averages out at ~192 kbps and generally is indistinguishable from the original [unless you are of the monster-ear audiophile species.] You certainly won't miss anything with your sound setup.
Get the optimised win32 binaries [and OggdropXPd] from John33's website.
Use ISO 8601 dates [YYYY-MM-DD]
PceNativeCall()
you might want to check your documentation again. we have successfully written a number of native ARM code chunks in our palmos applications.
In theory, once you've got a floating-point PCM or ADPCM value, you can cast that out to any precision of integer you want -- the same blackbox decoder would work whether you were creating an 8-bit signal for a basic DSP or a 24-bit signal for a studio-quality DAC. (The latter is particularly relevant since Ogg can support more than two channels and can chain multiple segments in a single Ogg bitstream.) In theory you could even design a DAC to directly accept an IEEE 724 floating point number.
.sos into /usr/lib!!)
Decoding using the FP decoder and casting to, say, 16bit unsigned bigendian, should sound no different than decoding to the same point using Tremor. I haven't looked at any comparisons of algorithmic complexity for the two decoders, since the one project I'm working that uses Vorbis is using libvorbisfile.
(Or rather, the Mac OS X Framework version of it... the OSX-specific source in CVS is broken at present, but you can coax it into compiling with a bit of elbow grease. It also needs to have a Mac-specific gcc flag added to change the base address for the relocation table to allow prelinking. If anyone out there from vorbis.com is reading this, take those UNIX libs off the damned download page and get the Frameworks working -- most Mac users are NOT mentally equipped to su root and copy a bunch of
> but as of yet the build chain hasn't been release.
wrong.
prc-tools 2.2 was released a few weeks back, it has an arm compiler included in the distribution. the 'mainstream' compiler (codewarrior) has arm support as of release 9; and, has been mentioned publically in developer forums and is currently in beta testing (some developers have that luxury). i also posted arm-gcc building instructions to my website on August 05, 2002. so, its not "impossible" to build stuff - if you are a developer, and, you have the desire to program armlets; you have had a chance to do this for months. its not news; palmsource showed arm units at PalmSource 2002 in february.
This is for Palm OS 5 and currently is targeted for the only OS 5 PDA out right now--the Tungsten. The Tungsten has a 175Mhz processor and can handle mp3s and OGG fine.
Wow, does anyone bother to try software before ripping on it? Here's my $0.02
I do in fact own a Tungsten T. I pulled down the PRC, (134k nice size) Dropped it on my Palm then tried dropping various songs on a tiny 16M SD I have from work. Found out quick that encoding with -b 64 was a no-no (crashed every time, but reset nicely by tapping 'reset' button on error window), but -b 96 works fine. Given this is a beta I can't say too much about the interface (could be a little sleeker)It read the Song title/artist OK. There is an option to blank the screen after 10 or 60 seconds (good) although once it blanks, I can't quite figure out how to get it back on (without stopping it, no so good) For those who don't know, the Tungsten T does have a headphone jack. The stereo worked fine. My only qualm is that the audio is rather muffled. (Not sure if this is Palm or the software.)
All and all, a nice first try. Fix the audio. Add an equalizer. Spiff up the look, and ship it! It is important to note that as an early Tungsten user/developer (I had a demo unit weeks before release) Palm has not, to date, been extremely easy to deal with when it comes to specs and the like. Working with ARM native code is still not very developer friendly. This is the first app I've seen that stresses the audio hardware (and the chip for that matter) and I think credit should be given where credit is due. Bravo for making this an OGG decoder and bravo for the early release. Keep the betas comming! (I myself have a reason to buy that 64M SD now!)