Don't know if it rather should be a bug report so post it here.

Recently I've tried to add the following tags to some of my mp3s:
DATE = 2010-01-28
YEAR = 2010
(which is pretty logical and consistent from my point of view)

I've edited the tags via 'Extended tags' to be as specified above and saved. But then I opened Extended tags again and discovered the following:
YEAR = 2010-01-28
YEAR = 2010

I was suspicious about 'mappings' and checked them. There was indeed DATE => YEAR mapping. But it was for VorbisComment and I was updating mp3s. Nevertheless deleting that mapping, updating the tags and saving them again did not change anything - both values are still saved to YEAR tag.

What makes it even funnier is that after updating tags from foobar2000 (e.g. after ReplayGain scan) you see the following:
DATE = 2010-01-28
DATE = 2010
And Mp3tag does not show either of these values in Year column and Year field anymore.
(I know I can customize columns. But it doesn't work for Year field. And besides these 'mappings' if they are present should apply here transparently)

I tend to trust Mp3tag more in terms of tags manipulations. And usually do all my edits in it.
But in this situation it shows itself as

  • inconsistent: it knows that DATE should be saved as YEAR but fails to display DATE value in Year column/field
  • and 'too smart': preventing me from exact control over which tags I save without any obvious reason
    (having foobar2000 saving DATE tag instead of YEAR makes me think DATE is not so 'wrong', is it?)

Strangely enough, tracks I ReplayGain-scanned before still have YEAR tag.
So it might be foobar2000 1.0 'tricks'. Or it can be due to having two YEAR tags. Or just because '2010-01-28' is not a year but rather a date. This still needs to be investigated.

But I'm interested in any comments and opinions. :slight_smile:


Don't change the mappings unless you know that they do. :slight_smile:

I suggest you don't use DATE in Mp3tag for the complete release date and find another tag for it.


I didn't! Only after I've discovered this 'issue'.
Afterwards I've returned everything back and do not plan to change it anymore. :slight_smile:

But the problem (question) still remains: DATE vs YEAR ?

Why not to use DATE? Isn't it the most appropriate tag for ... umm date?

And then having foobar2000 replacing YEAR with DATE makes ReplayGain a pain :frowning:


Which tags do you use? ID3v2.4, I suppose.

From my understanding DATE (TDAT) is only available with ID3v2.3 tags (the frame was discontinued in ID3v2.4). So if you try to set it Mp3tag remaps it to YEAR (TDRC) and you end up with two fields.

Mp3tag tag field mappings:

ID3v2.4 frames:


YEAR is a timestamp field. You can enter the whole information in it (don't know how it works in practice with software players/portable devices, I've never tried it but Mp3tag is able to save it)

REQUEST: Tag Panel new Size Of Field - micro

Thanks for the clarification!

I have Mp3tag configured to save ID3v2.3 UTF-16
And just discovered that my foobar is set to save APE + ID3v1
But the files updated with ReplayGain did NOT have APE tags, for sure.
(I've just re-checked with foobar and ReplayGain - it saves ID3v1 + ID3v2.3)

And still the question remains:
If Mp3tag is smart enough to recognize that DATE should be replaced with YEAR when saving to ID3v2.4 (but I'm saving to ID3v2.3!!!) - why doesn't it show DATE value in the Year column/field?

Well, MusicBrainz Picard finally convinced me to stick to YEAR.
So now it's mainly a matter of understanding why ReplayGain was saved to ID3v1 + ID3v2.3 while foobar is set to write ID3v1 + APE and finding out how to make it save YEAR not DATE...


You see when foobar shows you DATE it is usually the same as what Mp3tag shows as YEAR.

For example the year in ID3v2.3 is saved in the frame TYER
Mp3tag shows you YEAR for this and foobar DATE because it has chosen DATE as its name for the "year" tag.

For vorbis comment tags, DATE is the standard for the usual year (like TYER at id3v2.3)
So foobar just shows and writes DATE
But Mp3tag shows you DATE as YEAR (hence the mapping) so that the field YEAR works for both mp3 and ogg/flac files.

It seems when you do not check [x] Force preferred tag writing scheme ...
foobar will not change the tag types.


Probably it was not clear enough - but it's Mp3tag where I checked 'extended tags'.
And it's Mp3tag that was showing me DATE tag after updating tags in foobar and YEAR tag after re-saving them from Mp3tag.

So conclusion is:

  • for some reason foobar (sometimes? in v1.0?) writes DATE tag, not YEAR tag
  • and Mp3tag tries to be consistent and always writes YEAR tag
    (however it is not smart enough to show DATE value as Year in it's UI)


When you enter more than 4 characters in foobars DATE tag on ID3v2 it writes a TXXX:Date field.
Only when you use 4 digits it's written to the correct year tag.


Well, that clarifies a lot. Thanks.

But it still seems not completely true.
After adding DATE = 2010-01-28 and YEAR = 2010 in Mp3tag and saving it I ended up with two YEAR tags.
And after updating tags in foobar later I came to two DATE tags.
While, according to your description, after foobar it should have been one YEAR tag and one TXXX:Date.
But that's too deep into details. It actually does not matter that much. :slight_smile:

Should I submit a feature request to make Mp3tag show DATE tag in Year column/field?
Or do you consider it a 'bad thing' since the user will not go and 'fix' tags then?


After thinking about it again, I still must say that it won't work with foobar if you use YEAR and DATE in Mp3tag.

Use YEAR=2010 and maybe DATE FULL=2010-02-02 in Mp3tag,

then you can use DATE and DATE FULL in foobar.


No-no. I'll stay with just (one) YEAR :slight_smile: (As complete as possible?)
And where needed I'll use something like $year(%date%) in foobar (and will be extra careful when updating tags from foobar)