Whamb Audio Player Shares Via Rendezvous 14
Stéphane Thiell writes,
"I just released an update of Whamb, a little shareware CD/MP3/OGG player for Mac OS X 10.2. It's not as advanced as iTunes, though it now has playlists sharing using Rendezvous.
A friend even wrote a tool in Perl which allows to run playlists
server on POSIX systems." Nifty. It's still in development, but works pretty well. I've got the Perl daemon running too, with some local modifications. The Rendezvous support has some scalability issues with my 25GB of MP3s, which maybe why iTunes still doesn't have it ...
My Quick review (Score:2)
No offence to the author of this app, but I don't see why anyone is trying to charge people money for such an application ($12.50 USD in this case) for a replacement of an excellent tool Apple gives away for free.
Re:My Quick review (Score:3, Insightful)
Posting this from a 650 iBook, I can say that if it will play the same tunes, and save 30% of resources over iTunes, I might actually go download this. I run iTunes hidden almost always, so looks aren't important. Free the resources, skip the GUI. MHO.
Re:My Quick review (Score:2)
To each his own though.
How'd Steve do it? (Score:1)
How did HE do it?
Re:How'd Steve do it? (Score:1)
Nice. (Score:3, Insightful)
Still, it's got OGG, so good on ya.
Re:Nice. (Score:1)
Re:Nice. (Score:1)
hooray! (Score:1)
though i would still like to see this in itunes, *dream*, there's always macworld expo
-krel
install (Score:3, Interesting)
Interesting (Score:2)
The primary problem in systems like Freenet is a reliable way of obtaining an index of all the information available. e.g. *this* SHAsum is *this* mp3.
What if players could share playlists, which contained SHAsums of each file (or series of chunks in the file, whatever). This data is lightweight, and free and clear to distribute. Fine to put on an out-in-the-open sharing mechanism. Then the actual audio files are shared via Freenet, looked up using the SHAsums.
Second, there's a great quote from the article:
The protocol used here (WHSP), similar to HTTP for requests, and using XML data for responses, is light and efficient.
I didn't think I'd ever see "XML" and "light and efficient" in the same sentence.
Re:Interesting (Score:2, Informative)
For the scalling problem, I just discovered it's a limitation to CFStream's API (can't send more than about 256K of binary XML). It's gonna be modified in 1.1.1 to use a less specialized way but without any limitation, until this is fixed in CoreFoundation...