I rip all CDs, vinyl and cassettes to flac for easier listening, but I also convert the files to mp3 for listening in the car, which has an mp3 CD player. This is what the display normally looks like:
I’ve been assuming that my vinyl ripping tool chain just hasn’t been inserting id3 tags into the mp3 files for years, and that the car mp3 player was just displaying random data. But yesterday I finally remembered to check the tool chain, and it does insert id3 tags into those files, too.
So, while pondering this deeply serious and puzzling issue, I started looking at id3 tools. I wanted one that could just output all the id3 data in a machine-readable format, so that I could, perhaps, figure out what it was about certain files that made the car stereo not like them.
And I couldn’t find a single one. I installed at least five different ones, and they were all so charmingly human oriented. Phooey.
If I managed to discover what the problem was, I was going to have to re-tag all the problematic mp3 files, and I wanted that to be a process that could be automated, so I need machine-readable output.
Instead of continuing down that rabbit hole, I just wrote an id3 parser in Emacs instead. And what the problem was because obvious on the first file I parsed:
Interpreted as the iso-8859-1 Latin-1 charset, that would just be “ÿþM”, because it would think the string terminated at the first nul byte.
So the version of the Lame mp3 encoder on my vinyl ripping computer writes utf-16 tags, while the CD ripping computer writes iso-8859-1 tags. And my car only understands the latter.
But when I’ve written the id3 parser, I thought I could just finish the job and write an id3 mode, too, to allow viewing and editing the id3 data. It’s a bit scary, altering the mp3 files themselves, so I’d handle this with care. In fact, I would recommend not actually testing this mode for writing data. But it kinda seems to work for me. Slightly.
Here’s what it looks like on an mp3 file that has an embedded image inside: