Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES

Nevermind. I can tell that I'm pissing in the wind here, because even three years ago, a developer came to the exact same conclusion that I guessed at:

Well, the author is wrong - just because it follows the spec doesn't mean there's no problem - but it doesn't seem like he'll be convinced of that.

https://code.google.com/p/mutagen/issues/detail?id=78

So consider this thread a huge warning. Don't tag your collection with Audacious unless you want to redo a bunch of work later.

I'm deleting your forum account since you are not able to discuss this in a civil manner. This is a privately-run forum, and if you simply want to rant, you can do it somewhere else.

For those actually interested, the issue here is simply that mp3val hasn't been updated to read ID3v2.4 tags written to the end of the MP3 file, which is perfectly legitimate and has some advantages over writing the tags at the beginning of the file. Anyone who wanted to know that only needed to ask.

Originally, this had been my reply to the "Tagging Question" topic that has been closed meanwhile.

In short, I would have liked to get to see some concrete hexdumps of the files in question. As I've fiddled with ID3v2.x as well as taglib before, here are the results of a small experiment:

I've started with an ordinary MP3 file from my personal collection. In a hexdump, I can see an ID3v1 TAG at the end and an ID3v2.4 structure at the beginning of the file. The two frames TPE1 and TIT2 appear to be okay and specify UTF-8 encoding.

mp3val reports +ID3v1+ID3v2. id3info (from id3lib) displays both TIT2 and TPE1, but truncates the title at 30 characters. Dunno why it does that. Only ID3v1 was limited to 30 chars. mpg123, totem and taginfo display the tags.

Next I loaded the file in Audacious, added album "test" and saved the metadata. Afterwards, in the hexdump, I see the ID3v2.4 structure was moved to the end of the file. The old ID3v1 TAG was preserved. I see the added TALB frame, specifying UTF-8 encoding. I also see the footer flag set to 1 and the 3DI footer at the end of the file, which is a MUST according to the specs when putting the ID3 structure at the end of the file. So far so good.

mp3val reports "Garbage at the end of the file", but the offset it prints points at the ID3v1 TAG. Apparently it gets confused, if ID3v2 is appended to the end of the file. Its manual.html claims that they "must be at the very beginning of the file", which is wrong. So, mp3val no longer recognises any tags. id3info doesn't recognise any tags anymore. mpg123, totem and taginfo also don't display any ID3 tags anymore either.

On to EasyTAG. It loads the file and recognises the tags, but it marks the file red, because it wants to "fix" something. Let's see, what would it modify? I saved the file. In the hexdump, the IDv2.4 structure is at the start of the file, excluding the footer, of course. And what a surprise at the end of the file! It didn't "move" the ID3v2.4 structure as created by Audacious, it copied (!) it. At the end of the file, the structure is left untouched, including the footer. But EasyTAG appended another ID3v1 TAG at the very end (with the added Album filled in). Not only invalidates that the footer, the MP3 file now contains two competing ID3v2.4 structures (no SEEK frame in the prepended one) and even two competing ID3v1 TAGs. WTF? EasyTAG has a checkbox where one can disable writing the ID3v1 tag. I find it strange that it didn't replace the existing tag.

One immediate thought is that several implementations don't support appended ID3v2 tags, perhaps not even the 3DI footer. taginfo (a tiny C++ file) relies on taglib to do everything, but still fails. That's odd. I've thought that taglib would handle footers as well as appended tags.

One thing that Audacious probably is doing wrong is leaving the ID3v1 tag and appending the ID3v2.4 tag after it. If it's even legal to have both types at the end of the file, the v1 tag should probably come last for compatibility reasons.

The trolls would have you believe otherwise, but I actually can see the arguments on both sides of the beginning-vs.-end debate. The best behavior, at least in the case of existing tags, would probably be to leave the tag wherever it was before editing. I would accept a well-written patch to do this, but I'm not interested in writing it myself, and so far no one else has shown interest in doing so either.

I can't find any documentation/specification about what to do with an existing ID3v1 tag. libaudtag expects it at -128, so if an ID3v2 tag gets appended, that moves and effectively overrides the v1 tag.
TagLib also expects a v1 tag at -128.

If inserting the v2 tag before the v1 tag, hmmm, the v2 footer would not be at -10 anymore but at -138, and implementations would need to search for it (the footer doesn't add any benefit to tags with small frames anyway). TagLib searches the file for "ID3" from the beginning till the end, not looking for the footer magic. It can write a footer, however.

It might be best to just delete the v1 tag.

I vote turf the v1,
except if othersystems can't read the newversion.