TDRC tags in id3v2.3 in wave files

I am having some trouble with the id3v2.3 model being a bit too restrictive.

The files are any ones exported from Audacity v2.3.1 where a date field has been added using its standard metadata input field. It is saving it as TDRC which apparently is not valid in ID3v2.3:

x = audio_metadata.load(“test.wav”)
Ignoring TDRC frame with value ['2020'].
TDRC is not supported in the ID3v2.3 specification.

I have not checked yet if it is adjusted in later versions. It might be prudent to have the option of more lenient processing of that field, or something. I have not checked what taglib is doing, but it doesn’t have a problem with it. Do you have suggestion for how to fix it or a workaround? I am happy to do a pull request.

I suggest suggesting that Audacity follow the ID3v2 specs properly. Also, suggesting to other audio metadata libraries that they shouldn’t silently ignore spec-breaking data no matter how common those cases might be. Even if they still loaded it, warning users is important. Many, like you, never knew their files were actually breaking specs. Some, mutagen specifically, would actually present an ID3v2.2 TYE or ID3v2.3 TYER frame as an ID3v2.4 TDRC frame, which has caused confusion in the audio-metadata issue tracker and elsewhere. These are among the reasons I wrote my own audio-metadata library.

In the future, I plan to have a CLI tool using audio-metadata with a command to automatically fix/upgrade these kinds of things. And that might include a flag in audio-metadatato still load these frames in some way. But I haven’t gotten around to that yet or decided on how exactly I want to do that.

The best way would probably be update the file to use ID3v2.4. But music tagging software also often does weird things with the specs. I’ve seen ID3v2.3 files with empty TYER frames and TDRC frames with values. I don’t know what tools misbehave and which don’t, to be honest. So many just don’t care to do ID3v2 right.