i'm back to fooling around with Mac::iTunes again. i took a week off after the Mac OS X Conference because i had been thinking about it too much. [ side note: never trust an audience. i let them access (through Apache::iTunes) my iTunes (on the G3 projecting the fancy powerpoint on the screen and hooked up to the house sound). i asked them to take turns, but alas. ]
tonight i want to get a Perl version of iTunes Publisher off my to-do list, so i start mucking with the parsing bits again. some of the MP3s now live on another partition, and that partition name is a different length than the old one. this means that the 20 fixed bytes between the volume name and the date, which are \000 in every case i looked at, is really 27 - (length of volume name). i can name partitions with names up to 27 characters, but if i go past that it look like it initially works but then gives a warning. what's the deal? what is magic about 27? why not 31? i assume that these are C strings somewhere so the null bytes makes them a nice, even number. i took me quite a while to actually find this problem. Perl is not the best language for bytewise manipulation of binary data. all of that auto-stringy stuff gets in the way. however, C doesn't have hashes out of the box. i'm stuck somewhere in the middle of two equally annoying solutions. :)
