Hi, I've strong doubts that my request will be heard as I must be in violation of the id3v2.3 (or is it 2.4 ?) regulations, but I have to ask anyway because it looks messy.

The thing is I tagged my classical stuff with birth/death dates of composers, therefore being YYYY-YYYY format, and I have "Unknown" dates too. Now in .9 the date string seem to be truncated after 4 chars. So I have only "Unkn" and "YYYY" as the birth date showing up.. I don't know why this has been added exactly, but I would certainly like this feature to be removed or optional. Now if you can't or don't want to, I'll move it to a custom tag but that may force me to rewrite my whole tags which wouldn't please my HDD.

I stated my point, thanks for listening, you can give me the go for the HDD kicking now

My date tags in ID3v2 aren't cut off after four characters. Maybe you're using ID3v1?

I have a tagtype = id3v2|id3v1, so I don't think I am.. And considering the length of some titles, it's simply impossible.
And everything was tagged using & was displayed perfectly in .8.3.
By the way, I just noticed that one album is correctly displayed as it was in .8.3, showing 1632-1687, and I must say I have absolutely no clue why this one does and not the others.

Edit:Ok I found out, it has been retagged post-0.9 change.. And indeed when I tag something with a more than 4chars date, it works, then I tried removing it from the db and reloading it, it still works.
I tried to remove/reload an older file and it still doesn't work. So there must be something different in the way .8.3 tagged the files that .9 can't read ?

I've read a lot of tags talk on this forum and begin to understand it, but there is so much people saying things they are not sure about that it's very hard to get anything out of it.
Isn't there a tool that could read any version of id3v2.x and rewrite it as valid id3v2.4 with custom tags (I use origin/altsearch/onetrack which I doubt are valid especially the 2 last) being moved to some valid tag ? So everything is nice and everyone's happy..

Well as I understand it everything I did is "valid" but had to be rewrote in id3v2.4, which could only be done with .9.. So I retagged all my classical stuff (one selection per composer wasn't too long to do) and the few Unknown I had.. Origin/Altsearch tags didn't get truncated so I guess I won't have to retag everything..
If someone could confirm that what I have said is accurate I would feel better though.

In foobar 0.8.3 two ID3v2 frames were displayed as DATE field. TYER (the official field) and TDAT

The TYER field is supposed to have only 4 digits, and when you entered i.e. 1777-1808 in the DATE field, the follwong was saved in the file itself:
TYER = 1808
TDAT = 1777-1808

In ID3v2.4, both TYER and TDAT were removed from the list of official frames and replaced by TDRC

In foobar 0.9 it seems that the support for reading the old TDAT frame was dropped/forgotten, it can only read the old TYER frame, that's why your tags are truncated.

you can try converting your tags using the current Development Build of Mp3tag that supports id3v2.4. i never used it but it might help you

http://developer.mp3tag.de/

Thanks a lot, that's a clear explanation. Now TDRC is supposed to be filled with a timestamp, which as described in structural documentation of id3v2 can look like: yyyy, yyyy-MM, yyyy-MM-dd, yyyy-MM-ddTHH, yyyy-MM-ddTHH:mm and yyyy-MM-ddTHH:mm:ss
Therefore my YYYY-YYYY format is still in violation and could eventually be invalid in foobar someday, right ?
If I put it like DATE(as TDRC)=YYYY (only birth date for example), then FULLDATE(as TXXX I guess)=YYYY-YYYY and display FULLDATE or DATE depending on availability in my playlist/trackinfo/... That would be valid ?

Edit: (That was in answer to dano's post)

ssjkakaroto thanks, I'll have a look at this.

So TDRC is what foobar 0.9 is using for the DATE field name now? That doesn't seem completely right to me. TDRC is supposed to be used for the recoring time, TDRL for the release time.

ID3v2.3:

ID3v2.4 Deprecated ID3v2 frames


AFAIK all ID3v2.4 applications write to TDRC. Maybe it could be considered wrong, but it's already common practice.

'common practice' isn't realy an excuse that foobar can use if you look at the ID3v2.4 unsynced integer tag writing changes made (for the better) in foobar 0.9

With your setting I think FB 0.8.3 wrote into v1 and v2 (2.3).

Now, FB 0.9 don't understand 2.3 (yours) but 2.4 instead so it ends up showing only v1 (2.4 are not there).
But your 2.3 are not lost: they are still into the file and you can try to "port" them into 2.4.
I think one way could be that, in FB 0.8.3, you select APE 2 and ID3v1 instead of v1+v2 (this setting refers only to writing) and then use Database/Rewrite files from database. In this way. FB should copy your v2.3 into APE 2 and then back in FB 0.9 you should be able to see your precious tags again.
My personal opinion is to get rid of ID3v2 and keep using APE 2 instead.
As far as I know there are no reasons not to do it (but I'm not an expert).
If you still want to use v2 (2.4) I think in 0.9 you should select your files and then choose "Tagging/MP3 tag types" and uncheck APE 2. FB should then copy your database content (v1 and APE 2 by now) into v1 and v2.4.

PLEASE BACKUP YOUR FILES BEFORE TRYING THIS AND ALSO TRY IT ON A FEW FILES, FIRST!

I've already seen you posting that elsewhere and just want to tell you that I disagree. All id3v2.3 tags were and are still read fine by foobar2000 0.9 and 0.9.1 here. I don't know the specific roots of your and other people's problems with id3v2 tags but I think that your statement isn't generally true.

I agree, ALL my files were tagged using id3v2.3 and the only issue I had when going to 2.4 was the date stuff discussed above, I retagged everything (I did a huge cleanup while I was at it "remove all tags except...") and they are now all using v1 or v2.4, I've had no problem since then.