On Tuesday, October 1, 2002, at 01:30 PM, Mark Malson wrote:

When libid3tag reads in a TYER tag (and other date/time tags) it coalesces them (at least when writing a v2.4 tag) into a TDRC tag. It appears that iTunes does not read the TDRC tag and prefers TYER, even in v2.4 tags. The comments in libid3tag say that TYER et al. are obsolete, but I'd like to go ahead and write them out anyway.

Has anyone encountered this problem and maybe coded a workaround? My initial try was unsuccessful.

It seems an implementation of ID3v2.4 that still uses obsolete frames is broken, but here's some information that might be helpful:

When libid3tag reads a tag with obsolete frames, it stores them in the tag with a frame ID of ID3_FRAME_OBSOLETE ("ZOBS"). This frame type has two fields, ID3_FIELD_TYPE_FRAMEID and ID3_FIELD_TYPE_BINARYDATA. You can find the obsolete TYER frame by walking through the ZOBS frames until you find "TYER" in the first field. (ID3v2.2 used the 3-character ID "TYE" for this frame, but libid3tag prepends a "Y" to all ID3v2.2 frame IDs, so you may also look for "YTYE".)

Since libid3tag sets both the ID3_FRAME_FLAG_FILEALTERPRESERVATION and ID3_FRAME_FLAG_TAGALTERPRESERVATION flags in ZOBS frames, obsolete frames are not rendered when the tag is written again.

You can, if you want, create a new TYER frame either from the ZOBS frame or by parsing the composite TDRC frame. Frames created this way *will* get rendered as long as the frame flags above are not set, but they'll be considered obsolete again the next time the tag is read.