Hello!

I am experiencing some slight problems with the usage of tags and I thought you might help.
ID3v1(.1) tags should always be the last 128 bytes of a MPEG Audio file. That means that if a program would add an APEv2 tag, it would have to delete (or overwrite) the ID3v1 tag, append the APEv2 tag and finally append the original ID3v1 tag back. Same would apply for ID3v2.4 tags placed at the end of the file.
The problem is with ID3v2.4 and APEv2 tags... APEv2 is written at the end of the file (before ID3v1 begin), but ID3v2.4 tags can also be written at the end of the file. 10 bytes fefore the ID3v1 identifier (or 10 bytes before the EOF if no ID3v1 tag is present) you should find the string "3DI" followed by size information and flags. Now, if the player is not capabile of reading ID3v2.4 tags, it would place the APEv2 tag AFTER the ID3v2.4 tag, causin a "corruption" to occur.

The main question is: what is the correct priority of the following tags: ID3v2.2, ID3v2.3, ID3v2.4 (BOF), ID3v2.4 (EOF), APEv1, APEv2, ID3v1(.1), Lyrics3v1, Lyrics3v2.

Thank you,
Sebastian Mares

This is how Frontah saves tags:

[ID3 v2.2/3/4] [..audio data..] [ID3 v2.4][APE v1/v2] [Lyrics3][ID3 v1]

Lyrics3 must always be placed directly before ID3v1.

ID3 v2.4 can be placed anywhere, you should search the last 1K or so in the file for the identifier "3DI"/"ID3".

BTW, while you're here.

It seems that Frontah running on Win98SE doesn't save vorbis tags in vorbis files. When encoding some APE2-tagged wavefiles the resulting ogg-files ended up tagless.

I hope you don't mind "refreshing" this thread...

I have looked a bit inside the documentations of the various tag formats and found out the following things (I knew most of them already):

ID3v1 is placed in the last 128 bytes
Lyrics3 is placed right before ID3v1
APE is placed right before ID3v1
ID3v2.4 is placed right before ID3v1 (when used as "footer")

Now, I have several questions...

It is possible that a file contains more ID3v2 tags. Example: you tagged your file with an ID3v2.4 tagger and another person adds an ID3v2.3 tag using software not supporting ID3v2.4. The same thing applies to APE and Lyrics3 tags. Should I keep reading the file until I detected all ID3v2/APE/Lyrics3 tags, or should I quit the parsing after finding one ID3v2/APE/Lyrics3 tag?

Looking at the tag specifications confused me a bit. If I understand correctly, an ID3v2.4 will be rendered as unusable if an APE tag has been added (because there is no more "3DI" string before the ID3v1 tag identifier). Same thing applies to APE, if I add an ID3v2.4 tag after adding the APE tag (the "APETAGEX" string won't be found before the ID3v1 identifier), and Lyrics3.

Also, what should I do when there are more ID3v1 tags? I know that iTunes has this bug (writes an additional ID3v1 tag if modifying an ID3v2 tag).

Regards,
Sebastian Mares

From ID3.org:

That's BS, id3.org can of course make any arrangements they like, but such as placing would break compatibility with many programs searching the last 128 bytes for id3v1 tag.

Mea culpa, didn't notice that.

But when there's a lyrics3 tag, all the things go wrong then.

No one gives the id3.org right to dictate such standards, AFAIK.

Well, that is my problem. Too bad there wasn't (only) APEv2 from the beginning.

In my experience, the only things that is clear are that ID3v1 must be at the very end of the file. The rest is a whole mess of concurrent standards attempting to improve upon ID3v1, and since they all consider themselves the ultimate tagging standard there's usually no official documentation on what to do if there are, for example, 3 concurrent tags. The order in which multiple tags should appear is roughly related to the order in which they were invented:

1. ID3v1
2. Lyrics3
3. ID3v2
4. APE

So ID3v1 must come at the end of the file, always.

Lyrics3 must come immediate before ID3v1, and if no ID3v1 was present then a new one must be created - Lyrics3 can never appear alone at the end of the file. Any tags between Lyrics3 and ID3v1 will break most (if not all) Lyrics3-capable software.

APE appears near the end of the file somewhere, and because APE is the most recent tagging standard, most implementations are pretty flexible, so the APEtag can usually appear at EOF, before ID3v1, or before Lyrics3+ID3v1.

ID3v2 usually stays out of the mess by being at the beginning of the file, but if it's appended then as madah said it'd probably be best to stick it immediately after audio data and before APE/Lyrics3/ID3v1. Few (if any?) tag reading/writing programs (other than Frontah) support appended ID3v2.4 anyhow, so it's unlikely to be much of an issue.


The best thing would be to extract all possible tags, and then decide (either your software or the user) what data should be kept, discarded, etc.

Take the data from the one at the end of the file. Ignore any/all that come before. Flag the file as broken. Better yet, remove the last ID3v1 tag, and overwrite the second-last ID3v1 with the correct data. Repeat until there's only one ID3v1 tag present, at which point you'll be able to detect any additional (Lyrics3/APE/ID3v2.4) footer tags, if present.

OK getID3(), thanks for the tips.

By the way....
Sometimes the official side for something is a good entry point if it comes to specs and information

So for Id3v2 this would be -> http://www.id3.org/

P.S.: As by looking through this board and seeing how many people are believing that Unicode is not within V2.3 specs... whereas in the specs for it it clearly is mentioned... sigh, so I was glad about this thread to place the link somewhere

Unicode (specifically UTF-16) has been around since the beginning of ID3v2. ID3v2.4 added optional support for UTF-16BE and UTF-8. Who told you otherwise?

Was just that I searched for ISO-8859-1 in this Forum as I tried out Foobar and its build in replay gain yesterday & it messed up my ID3 Tags when they contained special german chars.... and in most of those threads there were always people who said something alike to that they (believe) UTF16 is not spec.... ok, that was my problem FooBar & Tags and luckily I solved that through to this Forum (I am still having some "trouble" with my various PCs right now in deciding on ISO without BOM or UTF with BOM (if I have understood the V2.3 specs correctly) in regards of "compatibility" to standalone devices (wich I may possess someday)... - but that would be another topic).
The search just produced a little evil grin on my side - as through that search (going from oldest to newest) one could easily understand how urban myths are born... and how the information becomes all mixed up through time
(I for myself know how easily I just give an answer out of memory without the actual reference to wichever topic it may be & by using own - non spec written words - are introducing some kind of misinformation.... but well as I noticed that the link for id3.org was never mentioned I thought I could throw it in somewhere that people still see there are actually specs out there (even if most programms seem to find their way around them) one can read - and not that they are a form of whitepaper that lies burrowed&forgotten somewhere

foo_id3v2 had some bugs, but they're fixed in 1.11. (check this and this thread).



If all characters is ISO-8859-1 then there's no point storing it as UTF-16.

Otherwise use UTF-16LE (little endian) with BOM (encoding $01).

Some players refuses to load tags if UTF-16BE (big endian) is used, even when there's a correct BOM present. An example is Windows Media Player 9, which refuses to even play the file.

Never use UTF-16BE without BOM (encoding $02) or UTF-8 (encoding $03), as they're ID3v2.4 only.

Thanks madah,
it may have been not clear in my above message, but with " ok, that was my problem FooBar & Tags and luckily I solved that through to this Forum" I ment to have learned about that too (Sorry, no offence ment.... &yes the major part of the problem was that as I installed the latest Foobar special download I only had the V2.3 tag 1.10 plugin installed along with it )
And with in mind of standalone devices and problems it is me now thinking about those messages in regards to IPod and varios other players and in sorting it out for myself what my best choice to my (future) needs will be ok, my best guess is at the time where I will buy myself a transportable (insert codec here) player will be the time my MP3 backups and with it the tag decission (wich of course would include 2.3.4 if it would be supported ... (EAC is the only prog that comes to my mind and in addition that the programmer of MP3ext (no argument please for my needs it is the best mp3 tag tool I had found so far) had stoped working on it since MP3Ext 3.4.22 and so no 2.3.4 tag support by it ever)... but that is another story too But as I like to do have my backups along a one concept for all principle and FooBar is rewriting the tags to the choice I made (So ISO or UTF/BOM) I want to cover the worst case within MY needs situation (So I just have to scann all those tags I have now to see if all characters fall into the ISO range (strictly speaking have to check that norm out again as for an example with the double dotted y in Queenryche i am not sure and neither am I on old mediaval titles that include some strange characters... (and I am not going to troll kode54 about the possible option to just copy all old tags and including a second ID3 2.4 tag (wich is possible within specs to add just a new entry (if I remember it right) or with 2.3 parse the existent tag, add in your values and write back the same type that was read in.... (sadly the replay gain value doesn't correspondend to the "Relative volume adjustment" field of 2.3 (or am I wrong - as this value is only one and the replaygain.org adjustment would need 2 fields (for radio(track)/audiophile(album)) for its info) & i dont know anything about the id3lib that the foobar plugin uses (based on?) & the programmer of it seems to dislike mp3 tags in general... so I am just thankfull for the things I can get (for free) ;D Grmpf... ok, way of offtopic (all I wanted to say thanks for the information & without patronizing you to say that I already figured it out )