TagLib Problems

[Manfred Schwind]

Hi,

I recently looked deeper at some problems related to taglib that summed up. Most of them are due to non-standard-conform audio files that are out there.

My question is: how is the general policy for taglib in these cases? Is taglib simply ignoring non-standard-conform parts, or should it try to interpret and preserve as much information as it can?

Concrete problems I have found:

1. Sometimes strings in MP3 files are lost, e.g. lyrics. I have sample files where the USLT frame gets lost when a file is read and saved by taglib. The reason: The string is tagged with "UTF16" encoding, but has no byte order mark. Taglib just ignores that string in this case, so it is lost! Other parsers (e.g. eyeD3) just assume UTF16LE in this case.

2. WFED frames (containing the Feed URL of Podcasts) in MP3 files are lost when a file is read and saved with taglib. Reason: iTunes seems to put a nullbyte at the beginning of the feed URL. Taglib can't read the URL string and therefore discards the WFED frame. The result: Podcast episodes processed with taglib suddenly show up all as separate covers in the cover flow view of iTunes, because iTunes seems to group them by the WFED frame. Before, the podcast with all its episodes was just shown as one single cover, as it should. Even worse: iTunes seems to expect this nullbyte at the beginning of the WFED URL, so to solve this problem, taglib has to ignore the nullbyte when reading the WFED frame, but it must also preserve this nullbyte when writing the WFED frame back to the file.

3. taglib sometimes loses atoms in MPEG-4 files. The reason: The atoms are organized in taglib in a TagLib::Map<String, Item> structure - but I have some files where multiple atoms with the same name are present! Mostly these are "free form atoms" with "----" as name. One effect that I saw: iTunes stores some information like bitrate mode in such an atom, so the file shows e.g. "VBR" in the bitrate information in iTunes. After being processed by taglib, this "VBR" information is gone. But it's just coincidence that _this_ "----" atom was discarded and not the other. And I don't know what that might have stored. And I don't know what else type of atoms might be affected by this problem. I think one solution might be to organize the atoms as TagLib::Map<String, TagLib::List<Item> > or something like that (I haven't tried that yet).

Have these "real world problems" any chance of being fixed in newer versions of taglib? Or do you say this is all non-standards-conform and will not be fixed in taglib?

If you need any sample files for the problems above, please contact me.

Thank you for TagLib, by the way, it's a very nice piece of software.

Regards,
Mani