I have noticed in iTunes the ability to convert ID3 tags to 1.0, 1.1, 2..2, 2.3, and 2.4. The default for filescreated with iTunes-LAME seems to be 2.2. Is this the best version? If not which version is best? And I am NOT interested in APE tags becuase A) I have no way to create them in iTunes, and B) I do not think they work with an iPod.

I do not think the version 1 tags are acceptable either as they do not offer enough different data fields and have a short length.

Any advice?

BTW - hats off to Blacktree for creating iTunes-LAME which kicks butt over Apple's awful MP3 encoder!

EAC to ALAC (for archival), ALAC to MP3 APS for portable play.

I think ID3v1.x is the best. The 2.x version seem to disagree with some of my
players. They skip that songs sometimes even a flat serface keeping the unit still.
fist noticed this on my old sony NE-1. It was something to do with the lenth of the
padding ?. That said, It if you use an ipod using EphPod it dose not seem to make
a differance what tags are used

iPods don't read tags from files at all...they just read them from the iPod's database. So when you transfer a song to your iPod, iTunes will read ID3v1 or ID3v2 Tags and store them in the database. However, since iTunes can't read APE Tags it won't work...that's why you'd need a program that is able to read APE tags and therefore adds your song information to the database...

For that reason I tag my files using ID3v2.4 (I think...how do I know what Verson of ID3v2 I use?) + APE...maybe one day iTunes will be able to read APE-Tags...probably not However, I use APE-Tags anyway, because of mp3Gain...

In general, I would say that if you want to use ID3v2, use v2.3 and avoid v2.4. Only for the reason that a lot of software, including XP, does not fully support v2.4 yet, and your tags won't be as universal.

Everything under the sun can deal with v2.3 though. Or at least, if it can't deal with v2.3, then it's likely not something you want to use anyway. Good tagging programs like The Godfather and Tag&Rename tend to default to v2.3 tags. iTunes will use whatever tag it finds there already. When ripping in iTunes itself, it defaults to v2.2 tags.

For me the best version of ID3V2 is no ID3V2!
I fully agree with the cases mentioned in the infamous r3mix site:

This is not meant as big do-not-use-ID3 campaign. I just feel people should be made more aware about the downsides of the format. Strangely there is not too much information around comparing the pro's VS the contra's for the ID3 tag and yet there is a fair share of people that do not wish to use ID3 for the very reasons that are listed here. For the cause of objectivity, let's live by the ID3.org motto: ' T h e a u d i e n c e i s i n f o r m e d '.

First, let me refresh your mind what ID3.org says about the ID3v2 tag:

Some main features:

* The ID3v2 tag is a container format, just like IFF or PNG files, allowing new frames (chunks) as evolution proceeds.
* Residing in the beginning of the audio file makes it suitable for streaming.
* Has an 'unsynchronization scheme' to prevent ID3v2-incompatible players to attempt to play the tag.
* Maximum tag size is 256 megabytes and maximum frame size is 16 megabytes.
* Byte conservative and with the capability to compress data it keeps the files small.
* The tag supports Unicode.
* Isn't entirely focused on musical audio, but also other types of audio.
* Has several new text fields such as composer, conductor, media type, BPM, copyright message, etc. and the possibility to design your own as you see fit.
* Can contain lyrics as well as music-synced lyrics (karaoke) in almost any language.
* Is able to contain volume, balance, equalizer and reverb settings.
* Could be linked to CD-databases such as CDDB.
* Is able to contain images and just about any file you want to include.
* Supports enciphered information, linked information and weblinks.

Let me say why, not disregarding all these handy features, I choose not to use ID3 on any of my mp3s:

1. Most applications that say "ID3 compliant" don't even support a fraction of it's full functionality

I don't know a single program that even supports half of what is listed above, program A supports this program B supports another feature of ID3. This is no problem, but you can expect only a few of these many features to be functional in your favorite progam. Most mean by "ID3v2 compliant" meaning they can only read the "Title" and "Performer" (and a few extra) fields.

Every person has their own idea of how an "ideal" tag looks like. Some like to add pictures of the artist, the cover scans, maybe booklet inlay, or all lyrics in english, french or maybe finnish. Or some just use it to advertise or "TAG" ( in the not-always-nice-grafitty-way ).
There is no conformity and everyone adds just what they like.

I once downloaded a track which contained over 3 MB ( three million bytes ) of tag! And I couldn't even find out what was in there because it must have been some alien-binary-format unsupported by any of my tools around. (Maybe a short video of the artist?)

But I'm sure the person that added this probably thought all ID3v2 compliant tools could read what he put in there.

Objection: mp3s are supposed to contain and compress musical content. That's the only thing in the "MPEG1 - Layer 3" standard. The more tag, the less relevant music content.

2. Adding an ID3v2 tag to a VBR (or ABR) mp3 file makes it nearly impossible to get these files to play correctly

VBR and ABR mp3s contain a "VBR Header" in the first frame of the file. If you add any data (eg. ID3v2) in front of this even the best players, like winamp, don't find the VBR information. Hence, you get a wrong track length indication and no accurate lookup of a random position in the file. If you have to use ID3-tags for a reason, use the ID3v1 tag which, at least, is attached at the end of the mp3 file.

( In response to this page, some people wrongly claim this is not the case. Most of the time, not always, winamp behaves as such. If you get shown a bitrate converging to some average number (eg: 157-162-163-163-...) instead of the valid ...128/160/192... framesizes alternating then winamp did not read the VBR header. )

Expect some hardware players not to support this at all. I know the KENWOOD car series only plays ID3 v1.0 and v1.1 tags. I don't know if it'll play mp3 files that contain random data at the start of the mp3. Probably not, as it's no valid mp3 data.

Internal layout of an ID3v1.1 tagged file and example of the internal layout of an ID3v2 tagged file:


3. Adding ID3 tags means farewell to "gapless play" of mp3s

Mp3 decoders are constructed so that when they encounter invalid data, as the ID3 tag, they will play this either silent or not al all. It doesn't need much imagination to understand that there are no players (software or hardware) around that flawlessly handle all versions and all fields in any ID3-d mp3 file. Best case scenario, this results in short silences being added to the start (ID3v2) or the end (ID3v1) of the file during playback.

4. Removing ID3 tags is no easy task, sometimes nearly an impossible one

Admitted these probably aren't valid ID3 tags, I've had mp3 files which had extra data added to it of which I had no idea what it was. None of the "tag removal" programs I know of could remove it automatically for me. Good thing I had the time and technical knowledge of the mp3 structure so was able to manually remove all added data manually with a hex editor.

It can be annoying to remove all this clutter, of which someone else thought it handy, every time you download a music clip.

5. There is no like-mindedness of correct application or acceptable use

Linking up with the first point. If an ID3 user downloads an mp3 with ID3v2 tag from the net, very likely he or she will only find the 'basic' (composer/title/album/...) fields useful. All the possible additional information is subject to too much personal preference. One will find it justified to add lyrics in his local language, another will find small cover scans a must while another wants big cover scans, booklet scans, inlay scans, cd label scans, and someone else just wants the composer and title fields.

someone sent me this funny anecdote which he'd read on a messageboard as reaction to this page:

"I love r3mix, but sorry - until you give me a better way to store: album information, track numbers (with zeros before the numbers below ten,) and long song names or show to me how it's reducing the sound quality of my mp3s I'm sticking to id3v2. (No, file names are not an option, since I burn to cdr.)

People who put lyrics and images in their id3 tags on the other hand DO = evil."

Mind the last line. ;-) This illustrates the randomness of personal preferation perfectly. I'm sure any MusicMatch user adding the cover scans of their albums to the ID3v2 tags thinks of this as normal or preferred behaviour.

Aside the first four (imo big) practical issues this is also one of the reasons why I myself opted to find a decent way of organizing files not using ID3, because you can't ever get it right for everyone anyway. As an artist sharing mp3 files, at least you'll save a lot of your fans time spent cleaning up what you found useful and they might find clutter.

I think these points affect the quality of mp3 files, and thus found it not unappropriate to raise a few critical points regarding. It could help form a more well-considered idea on the use of ID3 tags.

Besides having a good file-naming logic, it's best to store additional cover scans or lyrics in the conventional .jpg and .txt formats in the mp3 dir rather than insert them as invalid data in mp3 music files.

Since there are some hardware players that can use ID3 tags handily (eg. KENWOOD car mp3-cd-player), I'd recommend only to add ID3v1 tags if you decide to tag your files for such a purpose. These are added at the end of the files and relatively easy to remove.

=======

Maybe some of that information is a little-bit outdated but I agree with the vast majority of the arguments and that's why I'm using (and sticking with) ID3V1.1 because I need some tagging...

So once iTunes reads the ID3V2 tag and stores the info in the iTunes database, is it there to stay unless manually changed in iTunes - no matter what happens to the original ID3V2 info?

Then, can one convert all of the ID3V2 tags to ID3V1 and not lose any of the info stored in iTunes (for example grouping or album art or a song title that exceeds 30 characters)? This would seem to solve the problem of using ID3V2 tags but still allow the iTunes database to record all of the ID3V2 info. iTunes provides a conventient way to convert ID3 tags from one version to another.

@ k.eight.a:



You should find a program called "tidymp3", it can remove all invalid data from mp3 files, including ID3 tags.

@k.eight.a
you are paranoid.

@ezra2323
2.3 enjoys wider and better support.

k.eight.a sounds pretty right too me, but there is one thing that's bothering me : what about long song titles (and album titles) ? id3 v1 doesn't allow much space for these, any way to getting around that ?

correct


incorrect

a standard-compliant mp3 decoder must treat id3 tags as garbage and just skip them

incorrect, see above


incorrect, unless you are using v. retarded software


correct

The combination ID3v1 + APEv2 (supported by fb2k and possibly others) is your best bet. Compatible with everything and yet as flexible as you want it to be thanks to APEv2.

not exactly. If iTunes notices that your file has changed it wil transfer it to your iPod again and therefore also update the iTunes library with possibly new song information.
But that sounds like a lot of hassle to me. Don't worry about ID3v2 Tags! I use them too without any problems so far. Get a decent program to tag your files like mp3Tag -> http://www.mp3tag.de/en/index.html it's free and offers everything you can imagine. In addition, I was wrong, I probably tag my files using id3v2 - 2.3 - since this is what mp3Tag writes...(I think). However, it's not 2.4 for sure

2 All: As I've written in the beginning:

The source of this article is r3mix.net which is nowadays out of order, unfortunately there were many helpful hints about audio compression and other related things...

As I've written in the end:

Maybe some of that information is a little-bit outdated but I agree with the vast majority of the arguments and that's why I'm using (and sticking with) ID3V1.1 because I need some tagging...



That's right... but tell me how many MP3 decoders are there...? And how many of them works the way you've written?



See my quote above...



I don't think so... Many people including me, rip to MP3 by EAC and tag at once and then they only play files through their MP3 player (WinAmp, the most wide spread)...

The only piece of SW I use for tagging is Monkey's Audio which is able to tag my files from directory structure and has many other useful features, you all already know...

So with this standard equipment of programs... are you able to remove all the garbage from the ID3 tags? I don't think so...

Not with everything. For example, I have an old MP3 CD player (the original AVC Soulplayer), and it has problems with MP3 files containing APEv2 tags. For example: it shows "[EXTD]" (or something like that) on my display instead of the track name, and - I don't know exactly why - it also drains the batteries extremely fast.

Yes, I know: blame the player. But I don't think I'll see another firmware update for this one (the last update was released more than 3 years ago). So I have no choice but to use ID3v1 (for my mobile phone which only supports ID3v1 ) and ID3v2 (for my MP3 CD player).

Are you sure you are using APEv2 and ID3v1? My iHP-120 shows a similiar behaviour when using only APEv2.

I cannot begin to express how wrong this is. Anybody who thinks metadata that does not change frequently should be separate and independant of the data itself is so wrong that I cannot even find where to start arguing with them.


No. iTunes will update it's own database from the ID3 tag itself in several circumstances. When it tries to display the album art, when you play the song, when you modify some part of the metadata (it rereads before allowing you to make any changes), and when you specifically force it to via a new COM command they added in 4.7.


If you remove the ID3v2 tag, it'll notice that eventually and get the new ID3v1 tag instead. And then you'll have that 30 character limit.

In any case, I have never had a problem with properly formed ID3v2 tags. I rip my files with EAC, tag to ID3v2.3 with Tag&Rename, they work everywhere. In every player I've tried, in every decoder I've tried. YMMV of course.

Yes, I'm sure. I verified this with Case's tag. Also, my mobile phone (Nokia 6230) properly showed the ID3v1 tag (it didn't show the tag when I tried it with only APEv2). So at least this player ignored the APEv2 tags, as it should.

But please remember that my MP3 CD player is quite old. It's entirely possible that all modern hardware players do properly ignore APEv2 tags.

I'm still waiting for a player with gapless playback and enough capacity, so I can finally ditch the old thing.

Seems like it's not using the usual last 128bytes == ID3v1 tag method, but looking for the TAG keyword by seeking through the file.

I'm not sure if I understand you right... but no-one can vindicate over me the purpose of storing pictures and lyrics in the tags!

Edit: I think that viewing (and editing) the pictures and text files through common programs is much more easier and "ergonomic" than doing it through ID3 tags...

I really don't want to fully get into it, but to give you a simple example: The iPod Photo will display album art when playing a song if the album art is stored in the file's tag, where it should be. So will Windows Media Player.


Yes, it is easier if all you want to do is stare at album art or do it manually or something.

I prefer integrated solutions. That is, when I play a song, the album art should appear on whatever screen I have hooked up automatically. Lyrics should scroll if I have them in there, etc. All this is much, much easier if you keep the song data and it's related data together.

Until we achieve the relational database filesystem to more easily handle related data like this, the current best solution is to integrate the data and its metadata together into one conceptual object. This is why we have container formats.

Let's try a similar example: Should subtitles be a separate text file or should they be integrated into the same container as a video file itself? There's arguments to be had for both, and in fact both are used in the world. I say that the fact that you rarely edit this data argues for putting them both in a container. You can extract/reinsert the data from/into the container when you need to edit it. Keeping them together makes it harder to take them apart by accident.

If I suddenly decide to reformat my music naming system to a wholly different schema, then my renaming program must take album art into account if the art is in separate JPG files. With it in the file tags, the renamer needs know nothing about my art, my lyrics, anything along those lines.

And so on.

Windows Media Player will also show the album art if it's saved as "Folder.jpg" in the same folder with the MP3 files.

Yes, it will, and that is where it's own lookup functionality stores the art. But look at which one it picks to display if you have both art in the ID3v2.3 tag and art in folder.jpg.

ID3v1 should not be used anymore!

1) only 32 characters per field.
2) limited number of fields
3) ambiguity in string encoding: no unicode support - all strings are ansi and each app assumes a different encoding when reading/writing ID3v1 tags.
4) unsafe: there is not a 100% reliable test to check whether a file has an ID3v1 tag

K, here's another question: What are the differences between ID3v2.3 and 2.4? I think I read somewhere that one of the chief differences is that 2.4 puts the tag at the end of the file while 2.3 puts the tag at the beginning for streaming purposes. IMO putting the tag at the end seems far better because it means you don't have to re-write the entire file when you want to add a tag, or want to add more data than has been padded for beforehand. Of course, I could be wrong.

Smells like bullshit to me. Sure, there is a chance that a particular format may have a literal "TAG" at -128 bytes offset from the end of the file, but the chances are slim.

No worse than APE or ID3v2.

1) ID3v2 is 100% safe (with unsynchronisation)
2) I have found many files with two ID3v1 tags.


According to the official specs you can put the tag in the end but there is no app that yould read this tag. This is true for both 2.4.0 and 2.3.0.

@kode54: i just read you're developing foobar's ID3v2 plugin and i was wondering what correspondence between ID3v2 frame id's and field names (e.g. TIT2 -> TITLE) are you using. I am currently writing a tagging app and i would like to make it compatible to fb2k.