Patch for APE tags on MP3s?

[lee321987]

   I read in one of the Archived threads that there was an patch to view Ape tags on mp3s. Is or was there such a patch?  (I tried Flyspray)

[Llorean]

http://www.rockbox.org/tracker/task/792

[zajacattack]

Question:
What does APE even stand for? Are there any advantages to it? Will it ever be accepted into rockbox?

[Chronon]

http://www.monkeysaudio.com/

Rockbox does support this codec already.  This patch would add support for APE tags in mp3 files.  It would be a change to the metadata parser.

[saratoga]

Question:
What does APE even stand for? Are there any advantages to it? Will it ever be accepted into rockbox?

They're monkey's audio tags.  They're like ID3v2 but much simpler and have to go at the back of a file (ID3v2 can go front or back).  Since the patch was rejected, I don't think they'll be supported.

[zajacattack]

For what reasons was the patch rejected?

[Llorean]

The task says who rejected it, and what he said his reason was.

[saratoga]

For what reasons was the patch rejected?

It wasn't implemented very efficiently, and a lot of people here were opposed to supporting non-ID3 tag formats.

[soap]

Does anything outside Foobar 0.8.x write APE to MP3 by default?

[saratoga]

Does anything outside Foobar 0.8.x write APE to MP3 by default?

I think mp3gain does, or at least it did.

[Llorean]

Yes, I think mp3gain still does unless you explicitly tell it not to.

[Lear]

It wasn't implemented very efficiently, and a lot of people here were opposed to supporting non-ID3 tag formats.

Hrmph, what was so inefficient about it, may I ask (other than needing extra file seeks and such)?

[saratoga]

It wasn't implemented very efficiently, and a lot of people here were opposed to supporting non-ID3 tag formats.

Hrmph, what was so inefficient about it, may I ask (other than needing extra file seeks and such)?

The extra seek wasn't combined with the seek for the ID3v1 tag (which would be only a few hundred bytes away).  That was the main problem as I recall. 

[zajacattack]

The extra seek wasn't combined with the seek for the ID3v1 tag (which would be only a few hundred bytes away).  That was the main problem as I recall. 

Were it to be implemented this way, might it be accepted?

[preglow]

The problem is how APE tags might interact with ID3 tags. We've already removed the ID3v1/ID3v2 priority option, so the first thing we look for is an ID3v2 tag, which is located at the start of a file. APE tags are located at the end of a file, so what to do if a file has both ID3v2 and APE? Also, what do we do if the APE tag is appended to the file before an ID3v1 tag? Look for both? We're not going to add an option for tag parsing again, so some way to handle this automatically in a way that makes sense needs to be found, and I'm not convinced there is one. People should just stick to ID3 :>