ID3: Find tags at the end of the file

[lazka]

Originally reported by: Christoph Reiter (Bitbucket: lazka, GitHub: lazka)

---

From goduck777 on December 12, 2010 02:57:47

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: http://code.google.com/p/mutagen/issues/detail?id=78

---

• Bitbucket: https://bitbucket.org/lazka/mutagen/issue/78

[lazka]

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

---

From joe.wreschnig@gmail.com on December 12, 2010 02:31:12

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.

Summary: ID3: Find tags at the end of the file
Status: Accepted

[lazka]

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

---

From joe.wreschnig@gmail.com on December 12, 2010 13:08:01

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.)

[lazka]

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

---

From goduck777 on December 12, 2010 03:19:19

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.

[lazka]

Original comment by Christoph Reiter (Bitbucket: lazka, GitHub: lazka):

---

From joe.wreschnig@gmail.com on December 12, 2010 13:08:37

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

[lazka]

I'm struggling to find any file tags at the end. If anyone has one..

Also we should support the footer flag, which can also be used for prepended tags

[lazka]

a59c0ef added some test files tagged with the only known tagger writing such files in an older version.

Let's consider this part of the spec dead (for now..)