ID3: Find tags at the end of the file

[GoogleCodeExporter]

Some applications (for example, audacious 2.4) write id3v2 tag at the end of 
file. According the the official document 
(http://www.id3.org/id3v2.4.0-frames), it is correct to append the tag (see 
"Tag Location" part) to the file. I think mutagen and quodlibet should follow 
this rule and add support for this kind of tag.

Original issue reported on code.google.com by goduck777 on 12 Dec 2010 at 1:57

[GoogleCodeExporter]

This has been in the TODO forever, we just never found a program that wrote 
one, so we didn't care.

It's a bit sad they did that - now data is just going to ping-pong between the 
front and back of the file when using any other writer, and take forever to 
write, I bet.

Original comment by joe.wreschnig@gmail.com on 12 Dec 2010 at 10:31

• Changed title: ID3: Find tags at the end of the file
• Changed state: Accepted

[GoogleCodeExporter]

So glad it is accepted. I am also a little annoyed about audacious's behavior. 
Although it can read id3 tag written by quodlibet, other applications 
(including quodlibet, totem, etc) cannot read the tag written by audacious. I 
have also posted a bug report to the audacious' tracking list 
(http://jira.atheme.org/browse/AUD-277) but the author insist that there is no 
problem with audacious's behavior.

Original comment by goduck777 on 12 Dec 2010 at 11:19

[GoogleCodeExporter]

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.

For reference, here's what we need:

3.4.   ID3v2 footer

   To speed up the process of locating an ID3v2 tag when searching from
   the end of a file, a footer can be added to the tag. It is REQUIRED
   to add a footer to an appended tag, i.e. a tag located after all
   audio data. The footer is a copy of the header, but with a different
   identifier.

     ID3v2 identifier           "3DI"
     ID3v2 version              $04 00
     ID3v2 flags                %abcd0000
     ID3v2 size             4 * %0xxxxxxx

Where 'size' does not include the header and footer. ("If a footer is present 
this equals to ('total size' - 20) bytes, otherwise ('total size' - 10) bytes.")

There are some tricky cases to deal with:

1. "3DI" appears at -138 and -10 into the file; "TAG" appears at -128.

This is most likely an ID3v2.4 footer with an ID3v1 tag after it. However, it 
could also be an unlucky ID3v2.4 tag by itself. We should try to parse it as 
two tags with the 2.4 footer at -138; if that fails, because we can't find the 
header, try parsing it as one 2.4 tag with a footer at -10. If _that_ fails, 
parse just the ID3v1 tag.

2. "3DI" appears at -10; "TAG" appears at -128.

This is most likely an ID3v1 tag with an unfortunate value. However, we should 
try to parse the size out of the 3DI footer and see if we can find a matching 
ID3 header.

3. "3DI" appears at -10; "TAG" appears at 128 bytes before the start of the 
footer.

This is ridiculous, but while I was reading Audacious's code I suspected this, 
and just verified it (with 2.4.0 in Ubuntu 10.10). If you have a file with a 
v2.4 at the start and a v1 tag at the end (like every file Mutagen outputs), 
and save in Audacious, it will move the v2.4 tag to after the v1 tag, and not 
remove the v1 tag. Good thing they care so much about the spec, right?

4. "ID3" appears at the start; "3DI" appears at the end.

This is what's going to happen to everyone tagging with both Audacious and 
other players. There is no very good solution here, but I'd prefer truncating 
the end tag and using only the start. (Certainly, this is no worse than 
Audacious throwing out every frame it doesn't understand, which is most of 
them, including really common ones like TPOS!)

This will probably repeat ad nauseum as long as you keep adding ID3v2.4 + v1 
tags. On the other hand, I feel vindicated that the default Mutagen/QL behavior 
is not to do this, despite many requests otherwise over the years.

(I am not very excited to do any of this myself. A patch with plenty of tests 
would be appreciated.)

Original comment by joe.wreschnig@gmail.com on 12 Dec 2010 at 9:08

[GoogleCodeExporter]

(Case 4 is actually: "ID3 appears at the start; any of the above appear at the 
end".)

Original comment by joe.wreschnig@gmail.com on 12 Dec 2010 at 9:08

[GoogleCodeExporter]

mutagen has moved to Bitbucket: https://bitbucket.org/lazka/mutagen/issue/78

Original comment by reiter.christoph@gmail.com on 4 Jul 2014 at 3:39

• Changed state: Duplicate