Slashdot Mirror
iPod on Linux... with GPLed software
Anonymous Coward writes "gnuPod 0.2 has just been released.
It's the first GPLed program that allows you to use your iPod under Linux.
It has support for playlists and stores information in a XML file, so it's very easy to edit the data or write a frontend.
Still a bit 'beta' but its ready for every-day-use and it works well together with iTunes.
A mac-ipod2win-ipod howto is also included."
They didn't seem to make too much of a fuss when people successfully plugged them into their Windoze boxes, but will Apple get angry at this?
Probably not, Apple seems to be pretty nice about people messing with their stuff.
Help I'm a rock.
There's a great review of the iPod on Jesusgeeks.net from the founder (gregday). He uses the iPod under linux and has a list of the programs he used, how he used them, and how it all worked out. To see the iPod review/howto, go here.
Personally, I can't wait to get an iPod. For a while I've been dealing with a crappy mp3-cd player, but after reading so much about the iPod, I'm ready to make the switch as soon as I have the cash. 299 doesn't sound too bad for 5 gigs of mp3 storage. And it runs under linux! woohoo.
The anti-salmon
I was afraid I might have to spend a couple of dollars so that my 500 dollar toy could run. Yeah, I know you said GPL and not just free, but I think it is funny considering that there will be many that will say, "Damn straight! Why should I have to pay for it running on my OS? Word"
Considering that Apple, uh, "requested" that MediaFour rename the XPod software (now XPlay), and that the developers rename the xtunes jukebox (now "sumi")... I don't think "gnuPod" will be long for this world.
four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
what's up with all the images changing? I like it! Very pretty slashdot!
I started a petition at Apple's Discussion board for people to "sign" (reply to) if you support Ogg Vorbis decoding on the iPod. The CPU the iPod uses is based on an ARM7 core, and will work nicely with Xiph's integer based decoder, Tremor. Anyone who supports it, especially those for whom Ogg support would be the deciding factor in an iPod purchase, are invited to add a comment here.
The only reason the iPod software revision 1.20 has Calendar, Contacts, EQ Presets, and track scrubbing is because users asked for it. So let's show Apple what it would take to convert all of us Freedom loving geeks! Support Ogg!
How long until Apple decides it only wants GOOD iPod software on the Mac (So people buy a new mac to compliment their brand new iPod) and sues the developers using the DMCA?
Shouldn' you be coding critical business apps instead of hanging around on Slashdot?
----
--
[insert witty one-liner here for your own pleasure]
I'm using 'SyncPOD'. Form the homepage:
This script syncs a local directory with your iPod. If the directory is larger than the space on your iPod you can sync this larger directory with a master playlist: SyncPOD - Syncs a local folder with your iPod
Features:
* Syncronisation with
a) a local directory
b) a master playlist
* Optional playlists
* On the fly created playlists
* Mp3 info from
a) mp3 tags
b) filenames
* Creation of iTunesDB file from all files on you iPod
stores information in a XML file, so it's very easy to edit the data or write a frontend
Or so goes the conventional wisdom. As a Linux user, most of the software I run now uses XML for storing configuration and data. Of course, none of them can exchange data with any others, so it ends up just adding weight to everything. For example, why does the ogle DVD player require libxml2? Are DVDs in XML now? I must have missed the memo. In my experience, XML's supposed benefits are primarily vapor. At least binary formats save on storage space and network bandwidth.
Karma: Good (despite my invention of the Karma: sig)
Now that the software is free, all we need now are cheaper iPods, production-wise. $500 for 5GB? You've got to be kidding me!
Apple could save a fortune on labor expenses if they followed Walmart's Production Strategy, and probably have competitive prices.
I'd pay $100 for an iPod, but not $500 -- all they have to do to get me to buy one is cut labor expenses.
Coding an linux interface for cheap entertainment gadget which is produced by a company which is well known for their insecure future perspectives ?
One could argue that this "cheap entertanment gadget" is superior to the current offerings on the market. ( I for one feel that is true). In addition, Apple has been around for quite some time. It is doubtful that they are just going to disappear anytime soon.
Their switch campaign has been working somewhat well. And I do believe that they are slowly regaining market share. If I wasn't such a poor college student, I would be using a MAC right now.
Won't it be better to code much more useful stuff like education applications or scientific libraries? ... But instead these guy waste their time with such not very useful music player things.
True, scientific code would be more beneficial to one area of society. But people do need to be entertained. Also, the people who code programs such as this do it because they want to have the ability to have a certain functionality or use a certain piece of hardware. Thanfully, they have the freedom to pursue the projects they feel would be a meaningful contribution
I am happy that such a program has been written. The main reason I haven't purchased an iPod is because it was only supported on a mac. But now that other options are available, I will be more likely to buy one.
neurostarI agree!
Now back to my Xbox running Linux emulating Win2K.
Apple coded up a WIndows-compatible PC because people were screaming for it - it really is a truly breakthru MP3 player. Yes, others have the same capacity. But NO OTHER PLAYER ON THE MARKET combines superior capacity, style, battery life, skip protection, xtras (calendar, contacts, etc.), size, and weight into one package.
If you don't think so, I encourage you to go to an Apple retail store and use one. You will be blown away, and I can say that without hesitation.
its fantastic that there is now a way for linux users to use iPods - believe it or not, many Mac users actually use LInux as a secondary OS - myself included. Sure, I want the Mac's ease of use and stability and combination of Unix core w/ common everyday productivity apps, but do I NEED a Mac for all my ventures and projects? Hell no. And now I can use my iPod when I'm sitting at my Linux box.
See, Apple is about possibility. I doubt they'll have any problems w/ this because it will equal MORE HARDWARE SALES, which is their bread and butter. AND they didn't have to code it up themselves. Even better.
Horray linux! Horray Mac! Working together towards a beautiful co-existent future devoid of M$!
You need a FAT32 iPod, Linux, Firewire support and Perl5 to run the software. License: GPL V2.
Form the SyncPOD homepage:
This script syncs a local directory with your iPod. If the directory is larger than the space on your iPod you can sync this larger directory with a master playlist.
Features:
* Syncronisation with a local directory or a master playlist
* Optional playlists
* On the fly created playlists
* Mp3 info from mp3 tags or filenames
* Creation of iTunesDB file from all files on your iPod
The Archos Jukebox 6000 is a $199 6gig MP3 player and USB harddisk that has an open source linux driver and
open source firmware.
This is really cool. If Apple added ogg support to their iPod I would chuck my very old 32MB flash mp3 player and buy one of these in an instant. However, this kind of notice, "First program to do task X under linux!" kinda frightens me. I mean, it's good that it's being done and I'm sure a lot of people would get a lot of use out of it, but what happens when the second program comes out, and the third?
;) ). It may be an app that uses qt widgets and integrates really well with konqueror. I can see KPod coming now. It may be one based on gtk2 that snuggles up next to nautilus. That would be GPod. Let's say that there are two backends: backend1 and backend2. Let's further say that the designers of the textual and gtk2 frontends decided to build on backend1 because that's the one that they could get to work on their home boxes. The KDE designer is using backend2 because it's easier to write on top of.
In an open market where physical goods are being sold, competition is good and improves consumer choice.
Don't like product A? Try substitute product B.
Think B is too expensive? Try product C.
And so on...
Same thing to a lesser extent with commercial software, except there might not be two packages that do *exactly* the same thing but could still be substituted for eachother. Example: Dreamweaver and GoLive. Both are site design tools, but they don't have exactly the same function sets. (PLEASE no flames to the effect of "How DARE you compare Dreamweaver and GoLive?! ABC is OBVIOUSLY superior to XYZ! They're not even in the same class of products!" It's just an example.)
However, with open source software, <sweeping generalization>multiple "substitute" goods can hurt choice and the end user's experience.</sweeping generalization> Why? Well, many times, like this one, a piece of OSS doesn't perform a complete function that the average user can take advantage of. A backend is great, but unless you love the command line to death and can't get enough of long technical manuals, readmes, and errata, and don't really care if it takes you an hour or mode just to get started, you're going to want a frontend. It may be a textual one with a nice menu system. Undoubtedly someone will produce one of those (not everyone likes mice
At first glance it seems like the user has a lot of choice - two backends and three frontends are available to let him access his iPod under linux. Except he's a KDE user and he can't get backend2 to work. Or he's got his GNOME desktop all set up the way he likes it but the only way he can get the feature he needs from backend1 (which he has to use because there's no GNOME frontend for backend2) is by using the latest alpha build of backend1 which tends to crash when doing large file transfers. He could try using the console frontend or reading up on the backend, but the last time he tried that he borked his iPod when he tried to convert its built-in HFS+ partition to FAT32. The "simple" task of getting his linux box to talk to his iPod is turning into a headache. "Hmm," he thinks, "I heard Windows DRM 2005 has a nice iPod app that just works...maybe I should try that out."
Ok, ok, I'm aware that this is an obviously constructed scenario, but I think it illustrates my point. Wouldn't we be better off with ONE backend that WORKS rather than two that are lacking? Just like closed source software development has its strengths and weaknesses, so does open source. I've just described one of the weaknesses - the tendency to have multiple projects that try to do the same thing and end up splintering the user base. Take advantage of the corresponding strength of OSS: that you can work together on a SINGLE project with another developer even if she's halfway around the world (as long as you speak the same [programming] language). Please, developers, please - if you despise the way a particular backend works, don't just start your own. Unless the first one goes away, you'll only end up hurting users. Find out if there's a way you can contribute to the backend - fix the bug that's really bothering you or add the feature you desperately need to a project that's already started. Work together with other developers - it's better for everyone involved.
Perhaps you're not understanding that this isn't a "hardware mp3 decoder" chip - it's a general purpose CPU with approximately the processing power of an Intel 486 66-100MHz (depending on what you're doing). Provided the codec you want isn't too MIPS (or memory) hungry, you could software upgrade to support it.
Call me nitpicky, but it should be made clear that this software lets you sync your iPod with the Linux platform, as opposed to running your iPod under Linux which implies a new firmware for the iPod that replaces the iPodOS.
With all the Linux PDAs and open source Linux replacements for existing PDA firmware, this kind of clarification is necessary.
Actually, the confusion is a testament to the versatility of Linux. What other OS could be used so easily in both desktop and digital appliance environments as to make necessary the clarification? Nobody assumes the Windows iPod runs Windows, after all...
Kevin Fox
Check out this HOWTO for using a Win-iPod under linux:
http://www.cs.duke.edu/~geha/ipod/
Executive summary:
1. Build a kernel to support IEEE1394
2. Mount the iPod as a vfat filesystem
3. Use Wine to run EphPod.
This is how I update my iPod, and it works, but it has some problems:
* The linux ieee1394 drives sometimes don't recognize the iPod, and sometimes generate kernel Oopsies.
* Some functions of EphPod don't work, must notably the "Add Directory" function. This is probably a Wine limitation, but it's still irritating. EphPod doesn't check the id3v2 Composer tags, so your iPod's Browse->Composer menu is empty. EphPod has the feel of an app with a lot of maturing left to do -- but it's better than nothing.
* In general, the process is pretty klunky and needs lots of by-hand coaxing and prodding. I expect this to improve as the ieee1394 drives and Wine both improve.
That said, it's really cool to see that someone's making native linux support for the iPod. If you check around, you can find that there are several efforts to do this underway, some more half-assed than others... a guy here who's written a perl script to dump the database, a guy there who's got a python script for the same. But it's pretty obvious that there's a lot of interest in seeing real linux support for the iPod, so I expect to see those disparate efforts coalesce pretty quickly. It'll be nice to have.
By the way, I just love my 20GB iPod. 150 albums downloaded so far, and still 8.5GB left. You've just gotta get one of these things!
--Jim
The 5002 is a dual ARM7TDMI processor.
At what clock rate? The Game Boy Advance has a single ARM7TDMI at 16.8 MHz, and it's generally accepted that the GBA can't decode MP3 without extra hardware on the cart.
Will I retire or break 10K?
Not really, according to Sect. 1201 ((f) Reverse Engineering exception) of the DMCA.
17 USC 1201(f), which the judges have ignored in the past (MPAA v. 2600 DeCSS case) and may ignore in the future.
Will I retire or break 10K?
Well, XML is bloated and binary formats suck because they aren't human parseable. Why not use HDF5 (Hierarchical Data Format version 5). It can even gzip files on the fly to save even more on storage. Perhaps it might be a bit overkill for a tiny little configuration file, but it does have everything you want. :-)
All editorial writers ever do is come down from the hill after the battle is over and shoot the wounded.
I'd also recommend looking at YAML
-- Sorry, I can't think of anything funny to say here.
Another option is the PJB-100 from http://www.mp3factorydirect.com. It has an open source API that's fully supported under Linux and battery life that's even better than the iPod. What it lacks is the style of the iPod, though it's user interface is very functional and easy to use.
Since this was the first HD-based MP3 player and was available long before the iPod ever existed. I'd call this the true innovator, not the iPod.
You can shake the c**p out of an iPod and it will just keep playing fine. I run over three-five miles with mine--no problem.
Just a year ago when the iPod was announced the slashdot post was full of comments about how it sucked, was too expensive, was inferior to what was already out there, how firewire was uneeded, how it was "Yet another overpriced toy with less features", and all kinds of other ranting and raving.
Now everyone seems to love it. Interesting.
This leads me to further conclusions: People hate/whine/complain about MAcs/OSX/Apple because they have not USED them. now that people have heard a friends iPod, they know the iPod rocks (and have gotten over the knee jerk reaction of a year ago).
So we see people adding support for it to Linux-- notice Apple didn't make it proprietary, they just made it convenient for *THEIR* software and others have been able to hack together software compatible with iTunes and not a peep from apple (Except when they name it xPod) No custom FireWire protocol (and trust me, they could have easily- there are dozens of proprietary random fireWire protocols that some hardware manufacturers use to lock you into their software. Fortunately that trend is on the wane.)
So, maybe Apple's strategy is working. Maybe some people have or will now experience the superior joy that comes with the iPod and realize that an iMac delivers the same quality differential... and stop looking at price and faked performance claims so much.
After all, inside of a year this crowd has gone from whining and complaining about the iPod to asking for Ogg support.
Yeah, and you guys panned the ipod too: http://apple.slashdot.org/article.pl?sid=01/10/23
* You can validate/verify them with DTDs, etc. This is for free once you write the schema/DTD. If it's your own config file, you've got to make that stuff yourself.
* You can view them pretty easily (although I dev. on linux/solaris, sometimes I use IE or xmlt2html to view the config files).
* You can change things quite easily, and not harm existing applications. Adding another field to a song record won't mess up other applications that aren't using those XPaths,etc. Similarly, you cna have an element, say, called NetworkConfig, with all sorts of unknown stuff in it that you pass to a library routine, and it'll just read the stuff for you. You don't need to make it into any fancy structure.
* You can transform documents from one type to another type with XSLT, etc.
* The weight difference really isn't that bad. What's another 10k to a config file? Esp. if it's readable? Would you prefer XML-RPC/SOAP, or some random Corba stuff/compiling stubs? Even if it's 10 times as big, is the cost that bad on a 40G hd? Only data that a human wouldn't be able to understand (i.e. raw image data, compressed) has to be binary formatted.
I guess I find it hard to believe that people would prefer countless different types of config files, writing their own parsing code and validation routines, binary formats for non time-critical data, and the general chaos that used to exist.
Sure, there is a plethora of XML libraries out now, but I'm sure the numbers will continue to drop down as the best/easiest implementations make themselves known... In the mean time, people are developing a very capable set of tools to deal with a very expressive document structure. Sounds nice to me.
there is no thing
what else could you want?
I stopped using gnuPod since it didn't support ordering (i.e., if I added all the songs in an album, they'd show up on the iPod in alphabetical order, rather than the proper order determined by the track numers in the id3 tag. gnuPOD also doesn't do synchronization, and the hoops you have to go through to remove files from the iPod are rather cumbersome.
SyncPOD seems to work better for me. It has its own limitations and bugaboos, but it knows how to do correct ordering. I threw together a script which select albums from my collection at random to fill 5GB of space and makes symlinks to the selected mp3 files inside SyncPOD's synchronization directory. It works, after a little debugging (be warned that SyncPOD in its present release doesn't escape spaces or any other characters in filenames which might be interpreted by the shell.)
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
....We're not talking about the same situation here. It's not like the designers of the CSS routines sued 2600, it was the MPAA. Apple can't claim that reverse engineering is doing anything other than what it was allowed to do, making the hardware interoperable. The MPAA was able to claim that DeCSS could be used to make illegal copies as well. That's the difference.
Now, if this software allows people to easily copy songs off of the iPod (which Apple prevents by using hidden folders, easy to counteract, I know), I could see the RIAA having something to say about that.......
A sentence you'll never see on an Internet discussion board: "You know what? You're right."
In addition to asking for iPod Vorbis support, I also asked that they supported Vorbis in iTunes and bitrate reduction.
Now that iTunes has music rating, imagine a feature where you could say "Take all of the music I've selected to sync to this small device, and compress all music (starting with the lowest rated songs) until it all fits.
Since Vorbis has great bitrate reduction features I think this would be pretty easy to support and would really increase usability of small devices, in that you wouldn't have to think so hard about how to choose what would fit - just what you want.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
... from the man who pronounced it lame.
People who disagree with you are not automatically evil, greedy, or stupid.
Ok, a late post, but what the heck.
... but they are not sharing how they did it. Anyone have a guess? Does the ipod perhaps have some hidden protocol to write files via raw i/o ???
The gnuPod is nice and all put for me at least the real problem is that linux cannot write to the ipo d (linux can only read hfs+ partitions). Switiching to a Fat32 partition is not praticial for me since I want to use my ipod on my mac as well.
However it appears that the folks at tex9 figured out how write to the ipod (with hfs+ partition) via linux. http://www.tex9.com/software/xpod/
Has anyone else been underwhelmed by the sound quality of the iPod?
.wav file -> load .wav onto iPod and play back. Result: perfect. .wav file. Use lame to encode to MP3 at 320kbps. Load MP3 onto iPod. Result: very disappointing. .wav. Load this wav onto the iPod. Result: As good as (1).
I've found that at 320 kbps, classical music sounds *dreadful* in the quiet parts - as if it is being played by a Jamaican steel band! It has the characteristic "gargling" / "underwater" sound of low bitrate MP3 (perhaps only 128k).
I've done an experiment which proves the point:
1)CD -> rip to
2)CD -> rip to
3)Take MP3 from step 2. Descode on pc back to a
This only shows up in the softer parts of the track (there is a very large dynamic range), and it is far more obvious on classical music. I'm ripping/encoding on linux and syncing using XPlay on WinXP with a 20GB Mac iPod.
Let me know what you think?
Am I guessing correctly that the decoder is short on CPU power, and discards some of the data?
Here is another informative site on using Ephpod with Linux/wine. Ephpod is arguably one of the best iPod on windows apps, and has so far proven very stable under stock wine.
hmm... use the magical powers of google to find what you are looking for...
ohci compatible firewire ipod card...
Large print giveth, and the small print taketh away
Does the ipod perhaps have some hidden protocol to write files via raw i/o ???
Maybe.. it also looks like mac os X can set the iPod clock..
But: Your FAT32 iPod works well under OSX.. After reformatting OSX will tell you that it doesn't know the format of the plugged in device, just hit 'cancel' and startup iTunes.. after this the iPod works fine again..
According to the mayans the end is on Dec 21, 2012.
Choosing the lesser of two evils is a choice for evil.
AAAAAHHHHHHHHHHHH!!!!!!!!!!
If you think you can go from an (compressed) MP3 to a (uncompressed) wav and have it sound as good as the original wav from the CD, you're whole experiment is moot, because it shows you don't know what to listen for, and/or don't have an ear for music whatsoever.
You should EASILY be able to hear the difference between 1 and 3. Don't try any more tests please.
Thanks
What's wrong with being gay you queer bashing homophobe?
Won't it be better to code much more useful stuff like education applications or scientific libraries ?
Which you are no doubt doing yourself, when you're not posting insightful comments like that one.
Christ, let people have their fun.
Well, whether their ear is bad or not, the fact that it sounds horrible for them when still in mp3 form implies something is definitely wrong.
your statement hardly invalidates their experiment