iTunes Windows/Mac interoperability issue
Howdy from Fort Worth TX,
I have an iTunes interoperability issue that I’ll outline as follows:
For awhile I’ve been trying to implement a basic music server system. I have a Dell Inspiron (Windows Vista SP1), to which I’ve added an extra internal HDD (NTFS, 320GB, which I call G:), where my audio is stored, mostly in Apple Lossless (ALAC). I also have a iBook G4 which runs 10.4.11, which AFAIK is the latest pre-Intel and pre-Leopards Tiger OS.
I’m using iTunes client software mainly because of its ubiquity; I haven’t as of yet played with any hi-res files, which would require other software clients anyway. My goal in all this is to eliminate the CD player from my stereos, building them around the music server and an Internet connection, and having LP playback in the main system. At that point, I would only use the silver disc for archiving.
The SMB client in the iBook’s MacOS works like a charm. From the iBook, I can login to G: either from Finder or from within iTunes itself. I can also rip from or burn to either of my computers’ optical drives, and get a respectable ~10-20x speed across the network on my iBook. I’ve even done simultaneous rips, simultaneous burns, and burned on one and ripped from the other. So my network works.
Now for the problem. From either system, sometimes I can’t find some of the files. Sometimes it’s entire albums; sometimes it’s certain songs within an album. This is denoted using an exclamation point icon next to the index number of the file on the iTunes desktop. If I click on the file, it gives me a dialog box to locate it. Then I have to drill down to find the files. I have to do this for each file, one at a time. Alternately, I can drill down G: (from WinEx or Finder) and do a drag-and-drop of the offending file or folder to the iTunes desktop. This creates duplicate aliases, which I must then remove manually.
When I’m on the Dell and I try to sync the files with it, then my Mac can’t find them, and vice versa. But by analyzing the metadata (Artist, Album, Name), I think I’ve isolated the bug to the Windows version of iTunes.
I don’t know much about iTunes, but apparently it consists of the GUI, a Library file which holds and organizes the metadata, an XML file which populates the GUI with the metadata, and, of course, a media player. As well, it includes an ebusiness client that’s the whole reason for its existence, but I won’t get into that.
Contemporary versions of Windows can accommodate foldernames and filenames of 256 bytes, certain characters excepted. But iTunes for Windows, for some reason, truncates these names to 40 bytes. This can be a real problem, especially in the classical repertoire, where wordy descriptions (say, artist credits or symphonic movements) are often the norm. Also, the Gracenote CDDB used by iTunes may have names with characters that the Windows version doesn’t allow in its syntax. The MacOS with its UNIX-derived kernel is more permissive.
Whether one uses Windows or a Mac, the metadata is parsed, string-literally, into the iTunes library. Either version creates an alias on the desktop, which allows it to find and process the file. On a Mac, the alias and the target names match; on Windows, due to the field size limitations and input masking, they don’t. That seems to be the reason I have to resync back and forth. One would probably never have this issue with just Windows boxes or just Macs.
So, if I haven’t bored y’all with the above, what I’m looking for is a workaround that would allow more interoperability. Winamp may be an option for the Dell, as AFAIK it now supports Apple Lossless. Also I understand that the payware version can support hi-res (>44.1/16) files. RealPlayer can be run across both platforms, but I don’t know if it supports ALAC. But I’d rather stay with iTunes on both machines at least for now, and I don’t know whether or not implementing either non-iTunes client on the Windows machine would solve the naming or location issues.
Also, looking for a workaround to the much-maligned CDDB issue parsing classical metadata, but I’ll save that for another post.
Thanks, John