[F] TDAT incorrectly written in v2.58

writing ID3v2.3 tags
using %date% in an action now writes the non-compliant tag "TXXX/date" instead of "TDAT"

Yes, as %date% creates a user-defined field. The standard fields for dates are YEAR and/or RELEASEDATE (edit: oops: it should be RELEASETIME, sorry.).

Also see
Mp3tag v2.58 released

Whose standard? Mp3tag or ID3?
In ID3v2.3 DATE is the standard frame name for TDAT.
If I use RELEASEDATE, it merely writes a TXXX/RELEASEDATE frame instead of a TXXX/DATE frame.

So when Florian said:

it's not entirely correct, as DATE or %date% worked as per ID3v2.3 standard in v2.52

RELEASEDATE or RELEASETIME ?
See also ...
http://help.mp3tag.de/main_tags.html

DD.20140105.1058.CET

If I use RELEASETIME a TDRL tag will be written. Despite what the linked table states, TDRL is not a valid ID3v2.3 tag, it was introduced in v2.4 and as such should actually be written as TXXX/TDRL when saved as an ID3v2.3 tag.

If I use another application to write a TDAT value, Mp3tag will actually read it as DATE when using Extended Tags panel. At this stage I can find no way to write the TDAT tag with Mp3tag as I used to be able to do. If it can be done, I'd really appreciate anyone telling me how.

Using MusicBee to write TDAT in the above example. If tags are saved with Mp3tag after it reads as DATE, the TDAT tag is replaced by TXXX/DATE and still reads as DATE in Mp3tag, but not in MusicBee. This a definitely a Mp3tag bug.

I see the same thing; "Date" is definitely reading TDAT and TXXX/DATE and writing TXXX/DATE. Using mp3tag to set Year to 2012 and Date to 2302 causes "2013; 2302" to show as the Date in Foobar2000. Using both mp3tag and Musicbrainz Picard, at one point I wound up with two lines labeled "DATE" in the Extended Tags dialog. (I did try just creating a field named "TDAT", but that doesn't work, either.)

Since there were complaints about the 2.53-2.57 behavior, perhaps this could be an option?

[ X ] Merge ID3v2.3 Year (TYER) and Date (TDAT) fields
What that would mean:

Unchecked: Year=TYER; Date=TDAT; each can contain arbitrary text, but text is marked in some way (e.g., yellow background) if non-compliant (Year not four digits, Date not DDMM).

Checked: Year and Date are aliases; if in YYYY-MM-DD format, compliant TYER and TDAT are written; if in YYYY format, compliant TYER is written and TDAT is removed if it exists; otherwise, text is marked in some way (e.g., yellow background) and written unchanged to TYER, and TDAT is removed if it exists.

When reading an mp3v2.3 tag with "Merge ID3v2.3 Year (TYER) and Date (TDAT) fields" checked:

  1. If TYER is compliant and TDAT is compliant or does not exist, the mapping is obvious (YYYY-MM-DD or YYYY).
  2. If TYER is non-compliant and is not of the form YYYY-MM-DD, and TDAT does not exist, the mapping is obvious (Year=Date=TYER).
  3. If TYER is of the form YYYY-MM-DD and TDAT does not exist, the mapping is obvious (Year=Date=TYER); but it is not obvious what should happen if the tag is saved but the Year/Date field has not been edited. Should it be left unchanged (as usual for unedited fields) or re-mapped to TYER+TDAT (since it looks like it is compliant, and if it were changed and then changed back to the same text it would be compliant)? Either could be confusing... personally, I'd say re-write as compliant TYER/TDAT: if you want to preserve non-compliant TYER tags, you should probably not have Merge checked.
  4. If TYER is non-compliant and TDAT exists, it is not obvious what should happen: possibly set Year=Date=TYER\\\\TDAT. (It would be confusing to set Year and Date to different values when "Merge" is checked, so that would not be a good solution; better to put some ugly string in the field so that any user who goes to modify it is bound to notice something is odd, and non-compliant.) If the field isn't edited, write back TYER and TDAT unchanged. Hopefully, this case would be quite rare.

I know that over at MusicBee we are spoilt by Steven's fast responses to bugs, but seriously, it's over 6 months since the release of v2.58 and there has not been a development build or even a simple response to confirm this or other bug reports.

I can now understand why several sites have reported that Mp3tag is no longer being actively developed.

I seriously hope that is not the case :frowning:

I've fixed this with Mp3tag v2.59.

[2014-04-13]  FIX: ID3v2.3 TDAT was read to DATE when reading but not stored as TDAT when writing.

Thanks for reporting!

Kind regards
Florian

Sorry for not responding earlier to your question :frowning:

A big Thank You for implementing this in v2.59 :smiley:

Great, thanks for your patience.

Could you also post an update on your topic at the MusicBee forums so that Steven and the rest are aware of the problem being resolved?

I have downloaded Podcasts using Media Monkey:

As recommended by the MM forum I have set the following in the ini file of MM.

[MP3Tagging]
DisableFrames=TDAT;TDRC
EnableFrames=TYER

Now this enables me to 'SEE' the full date in MM's date field.

However in MP3Tag my YEAR field JUST has the 4 digit YEAR e.g. 2014 BUT if I have a look at the Extended tags I can see TWO fields in the metadata named YEAR

  1. 2014
  2. 2014-06-15

Obviously the first field is mapped to %YEAR% but for the life of me cannot see how to 'read' the field with the full date. I ultimately wish to populate all my 'date' field to releasetime which also coincides with that which iTunes uses..Phew...standards !!!

Any help appreciated...Cheers,

Desmond.

Extra info on my previous post...

I opened up the MP3 with a VS code program and found that the TYER frame had the year only whilst the TDRC frame has the FULL Date !!!

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.