iTunes 9 was released today, and the big question on everyone’s mind (ahum) was: will it break webOS sync once again? Well, yes, it does. In other words, webOS devices can no longer sync with iTunes. Luckily, the webOS 1.2 update is right around the corner, so big chance it’ll be fixed quickly.
I have a new 2010 Camaro and it has a USB port.
I can plug in a thumb drive with music on it and the car’s computer will find it, index it, and present it to me via artist, genre, album, etc.
The problem is that it stops at 2,500 songs either because of memory constraints or because it takes forever.
I have a 60GB 5th gen Video iPod. I used RockBox on it because I hate iTunes and I want to store my music in a folder hierarchy.
I was forced to use the original iPod firmware and load my music using Rythmbox. I hate it.
What is the solution? Having the car index the songs every single time is ridiculous. Why do that when an iPod or Zune have the songs indexed already. The problem is that people making cars, home theater receivers, or anything else you’d plug your portable media into stop after iPod and Zune and never get to Archos, or Creative, or Sansa.
What we really need is a standard for indexing songs stored on storage devices. Something like an sqlite database file (since it is public domain) of a specific name that sits at the root of a partition that has music on it.
Anyone else think that such a standard is painfully needed?
Sqlite may be open source, but that doesn’t mean the format is easy to parse, and you can’t fit sqlite into every device. Besides, we need a format that’s easier to read than to write, since you’ll read it a lot more than you’ll write it. We need something simple, compact (but not TOO compact), and something which you can parse with a few lines of Perl.
I can’t think of any case where a Perl interpreter would be smaller or more efficient than Sqlite on an embedded device.
No, of course, not. But that wasn’t my point. But if it takes 10 lines of Perl, we should get it to work in maybe 100 or so lines of C, which when compiled would CERTAINLY be smaller than either a Perl interpreter or an Sqlite server.
Perhaps if device manufacturers and software vendors started shipping devices that used a file system from somewhere in this century, and—oh, I don’t know—actually made use of extended attributes to store that data, then we could have perfect interoperability without the need to index.
But since FAT32 and database-based monolithic media apps rule the roost we will forever be stuck with the current state of play; that is until iPods become a 100% monopoly and everybody is forced to copy the iPod way.
It isn’t that simple. Extended attributes – especially on a flash style drive – have a big trade off of convenience vs performance. The MP3 file format already has a adequate method for describing its own metadata – why is repeating this information needed?
Also – with iPod, you need to separate the two issues –
1) File management
2) File storage
I hear people scream that they want to “manage their files manually”, and to be honest, Apple could develop a filesystem presentation layer that did this and still stored the data in its own format internally. In fact – this is exactly what iTunes is doing – the issue is not that iTunes exists, its that iTunes is not integrated in to the presented filesystem. I’m guessing that the processor in most classic iPods wasn’t powerful enough to support this, and by the time we got the more modern iPhone OS based devices, iTunes was here to stay. You only need to look at how the Pre works (raw USB and emulated iTunes Media Sync) to see that it would be possible for Apple to do the reverse.
As for file storage (as the above is purely access), the format that your data is stored in (as the device level) is completely irrelevant to anything in the whole iTunes debate. Whether the files are stored in some hierarchy or in a proprietary format, such as the current iPod scheme, or a bespoke file system as Kroc suggests, the presentation to the user could still be one that emulates the experience they desire. I say “could” be cause I’m sceptical as to how practical the mapping really would be and as to how easily it could be broken.
Because the duplication is cheap, whereas dynamically fetching the data is not. If attributes are stored alongside inodes (pointers to file data), you get the data for free when you do a dir lookup.
If you dont have attributes, you’d have to read data from the file – thats a seek (very slow), a read, a parse – and rinse and repeat for each file.
No, no no. That would make too much sense. The solution is for the big tech giants to battle it out and whichever one wins, it’s proprietary solution becomes the standard. Gee, don’t you know anything? 😉
Edited 2009-09-09 21:57 UTC
Well, every player could just store their own index cache and be done with it.
That being said – why can’t this iTunes crap just go the way of MCA bus, Itanium and Betamax? I guess the time of educated consumer is long gone already…
I stopped reading there…., and started drooling
But “An Itunes Store account is Required to use Home Sharing”
Talk about them wanting you to be their bitch..
…may be a bit harder for Palm to get around. There is more than just the USB code that can be used to determine if it’s an iPod connected…
I remember owning a non-Apple MP3 player that worked with iTunes (Creative Nomad II) a few years back. Has Apple broken that compatibility in subsequent versions of iTunes?
If not, it seems that it would be fairly simple for the Pre to emulate a discontinued-but-iTunes-compatible device.
Haha it was the first thing that ran through my head (before I wondered “so what’s new?”) as I saw that the new iTunes had come out: “does the iTunes – Pre war continue?”
Had expected Apple and Palm to have come to a resolution/agreement behind the scenes by now. Oh well, Palm Pre users are obviously best off not upgrading their iTunes for a while.