-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'Record date' writing unwanted month/day/time info #86
Comments
I can look into it if I have time. I suppose only ID3v2 is affected as otherwise it is just stored as one string (which can be arbitrary and is not validated or otherwise messed with). Did it had to convert from one ID3v2 version to another? (The annoying thing is that different ID3v2 versions use different fields; in fact ID3 versions older than v2.4 spread this information over multiple fields so the underlying library needs to do a little bit more work.) |
I think no, it happens often, if not always. I didn't change tagging related settings. My files that were tagged with MusicBee are ID3v2 2.3.0. |
This little detail is annoyingly a bit more involved than expected. I've already changed the timestamp parser to keep track of the parsed parts (Martchus/cpp-utilities@f20d596) but I still need to use it in the tag parsing library. |
This should be implemented on master. Now it only adds the ID3v2.3 fields that are present in the specified timestamp. Note that some parts of the date/time are still tied together because that's what the spec requires (e.g. if you have a month you also will have a day) but the use-case of just specifying the year should be covered. ID3v2.4 is more flexible about the format so you can also have everything as mentioned in the spec. |
Thanks! |
I get mpv and mediainfo showing
2002-01-01 00:00
as record date.Is there a way to always only write the year
2002
?month/day/time
01-01 00:00
is generated by Tag Editor, I would prefer Tag Editor not writing month/day/time info, or at least not when the value is01-01 00:00
, possibly nobody really wants it since it's not correct.The text was updated successfully, but these errors were encountered: