Support and General Use > Audio Playback, Database and Playlists

Patch for APE tags on MP3s?

<< < (4/4)

Llorean:
Don't forget to mention there's not a particularly compelling reason to support them, since nobody's come forward with an "well I can't do this with ID3v2 and need to" story (as far as I've seen). I think the biggest complaint about ID3v2 is simply that it takes longer to tag the file, since it's added to the beginning of the file so taggers must rewrite the whole thing if it's being newly tagged or the padding isn't large enough. But converting ApeV2 tags to supported formats is something that can be done on the host side without the additional complication support for them would bring, and without loss of information.

saratoga:

--- Quote from: preglow on April 25, 2008, 05:54:06 AM ---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?

--- End quote ---

Generally software goes ID3v2 then APEv2 then ID3v1, since people with ID3v2 tags are unlikely to have APE, but the reverse is not always true.


--- Quote from: preglow on April 25, 2008, 05:54:06 AM --- Also, what do we do if the APE tag is appended to the file before an ID3v1 tag?

--- End quote ---

Its always appended before the ID3v1 tag.  The reverse order isn't allowed.


--- Quote from: preglow on April 25, 2008, 05:54:06 AM --- 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 :>

--- End quote ---

I don't really see this being a problem.  You check for an ID3v2 tag at the front of the file.  If its there, you're done.  If not, check for an APEv2 tag.  If not, check for an ID3v1 tag.  The problem is doing this efficiently to avoid excess reads, not deciding the order to do it in.  And I'm not sure how easy it would be to do that.

Just wondering, do we support ID3v2 tags at the end of files?

preglow:

--- Quote from: saratoga on April 25, 2008, 03:45:10 PM ---Generally software goes ID3v2 then APEv2 then ID3v1, since people with ID3v2 tags are unlikely to have APE, but the reverse is not always true.

--- End quote ---
Are you sure? I've seen bunches of files with all kinds of metadata clustered onto them, including both ID3v2 and APEv2.


--- Quote from: saratoga on April 25, 2008, 03:45:10 PM ---Just wondering, do we support ID3v2 tags at the end of files?

--- End quote ---
Source seems to indicate a no.

saratoga:

--- Quote from: preglow on April 26, 2008, 05:33:28 AM ---
--- Quote from: saratoga on April 25, 2008, 03:45:10 PM ---Generally software goes ID3v2 then APEv2 then ID3v1, since people with ID3v2 tags are unlikely to have APE, but the reverse is not always true.

--- End quote ---
Are you sure? I've seen bunches of files with all kinds of metadata clustered onto them, including both ID3v2 and APEv2.

--- End quote ---

Thats what I'm getting at.  If you intentionally use APEv2 tags, you almost certainly do not have ID3v2 tags since  most programs that can tag APEv2 are smart enough to clean up the tags too.  If you intentionally use ID3v2 tags, its not that hard to accumulate additional tags like APEv2, since most ID3v2 software does not merge APE and ID3 tags.  Therefore in practice its typical to assume that if someone has ID3v2+APEv2 they want the ID3v2 tag parsed and are unaware of the APEv2.  Foobar now does this, though it has an option to override the behavior too.

Navigation

[0] Message Index

[*] Previous page

Go to full version