![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
"Despite the failings of the ID3 format, some developers consider MP3 files with APE tags to be invalid files." Which developers, exactly? — Slicing ( talk) 16:29, 19 December 2005 (UTC)
The tagging string APETAGEX signals the start of an APEv2 record, and the string TAG signals the start of an ID3v1 tag.
The notability of this technical detail is unclear in this version of the article. I can guess the author intended to point out that if the length of the APE tag is such there are exactly 125 more bytes in it until the end of file, this tag might be interpreted as an ID3v1 tag by players that don't support APEv2, and cause them to display truncated fields and control codes as the metadata. This is a non-issue in practice.
1. The primary reason APEv2 is (was?) used was to record more information than an ID3v1 tag could hold, thus being longer. One could still craft a tag containing "TAG" in one of its fields, or, indeed, the last MPEG frame. There is no reason to do so.
2. Foobar2000 can be configured to also write a compatible, valid ID3v1 tag after APE, and this was the default choice around version 0.8. Legacy players thus always see a good, but limited capacity tag.
APEv2 is still a superior format, because the tag can be transferred without data loss between files that support it (most streamable files, such as mp3, mp2, ac3, dts), mpc, ape, wv, tak, and is fast to write. The key/value structure also means that, with few exceptions, all players display and use the "key" literally. This is not the case with ID3v2 or MP4, where players expand the four character codes to field names following what appears to be a vague standard followed at the time the player was written. Older players may fail to see certain entries such as "album artist" or "composer", or update them in a way that a newer player can't see them.
Data contained in APEv2 is also safe from modification by poorly written players, which could attempt to automatically "fix" tags or automatically insert statistics like ratings.
It is not the only "extra data" that can occur in mp3 files; incorrectly written remainders of "standard" tags do occur (such as RIFF Wave chunks). Good MP3 players can recover and resync past this data or end playback upon encountering it. Winamp can even play MP3 contained in packaged files, such as video game data. I've yet to encounter a case where a (regular size) tag forms a valid decodeable MPEG frame.
/ original, opinionated research
Informally collected thoughts of a few developers about APE vs ID3v2.
-- J7n ( talk) 00:42, 28 March 2015 (UTC)
I have added a section called "Essence" that - hopefully - fulfills the need for a summary. I gues the contrast with ID3 (version 2 and above) tags is part of the essence of APE tags. Rbakels ( talk) 11:00, 10 May 2017 (UTC)
![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
"Despite the failings of the ID3 format, some developers consider MP3 files with APE tags to be invalid files." Which developers, exactly? — Slicing ( talk) 16:29, 19 December 2005 (UTC)
The tagging string APETAGEX signals the start of an APEv2 record, and the string TAG signals the start of an ID3v1 tag.
The notability of this technical detail is unclear in this version of the article. I can guess the author intended to point out that if the length of the APE tag is such there are exactly 125 more bytes in it until the end of file, this tag might be interpreted as an ID3v1 tag by players that don't support APEv2, and cause them to display truncated fields and control codes as the metadata. This is a non-issue in practice.
1. The primary reason APEv2 is (was?) used was to record more information than an ID3v1 tag could hold, thus being longer. One could still craft a tag containing "TAG" in one of its fields, or, indeed, the last MPEG frame. There is no reason to do so.
2. Foobar2000 can be configured to also write a compatible, valid ID3v1 tag after APE, and this was the default choice around version 0.8. Legacy players thus always see a good, but limited capacity tag.
APEv2 is still a superior format, because the tag can be transferred without data loss between files that support it (most streamable files, such as mp3, mp2, ac3, dts), mpc, ape, wv, tak, and is fast to write. The key/value structure also means that, with few exceptions, all players display and use the "key" literally. This is not the case with ID3v2 or MP4, where players expand the four character codes to field names following what appears to be a vague standard followed at the time the player was written. Older players may fail to see certain entries such as "album artist" or "composer", or update them in a way that a newer player can't see them.
Data contained in APEv2 is also safe from modification by poorly written players, which could attempt to automatically "fix" tags or automatically insert statistics like ratings.
It is not the only "extra data" that can occur in mp3 files; incorrectly written remainders of "standard" tags do occur (such as RIFF Wave chunks). Good MP3 players can recover and resync past this data or end playback upon encountering it. Winamp can even play MP3 contained in packaged files, such as video game data. I've yet to encounter a case where a (regular size) tag forms a valid decodeable MPEG frame.
/ original, opinionated research
Informally collected thoughts of a few developers about APE vs ID3v2.
-- J7n ( talk) 00:42, 28 March 2015 (UTC)
I have added a section called "Essence" that - hopefully - fulfills the need for a summary. I gues the contrast with ID3 (version 2 and above) tags is part of the essence of APE tags. Rbakels ( talk) 11:00, 10 May 2017 (UTC)