I’ve been searching for a solution for a while now but I didn’t really find any that fixed the issue for me.
The folder and files aren’t set to read-only.
Options>save tags is checked. Rename and move are not since I do not want to do that.
I’ve tried running Picard as admin and not, and no permission errors seem to be happening.
Picard does a wonderful thing where it only wants to use the first 4 digits for the Date automatically, which was exactly what I wanted to change in my tags. Upon hitting save it seems to have correctly saved:
But the file isn’t actually affected and still has the previous tags (checked in musicbee).
Upon quitting and restarting Picard, if I were to load the same song back, it would also state the the tags are still the original ones (i.e. picture 1). This happens with all songs, not just that particular one.
Any help in resolving this issue would be greatly appreciated.
While it does do what I want (although I think Picard has that functionality built in? at least it seemed so, the plugin didn’t seem to really stand out from what Picard did on its own) the overall problem still remains - I can’t save the changes to the tags to the file, with or without the plugin
Have you checked with e.g. MusicBee’s tag editor to see if there are perhaps duplicate date entries?
Have you set up Picard and MusicBee so they both match using id3v2.3 or v2.4?
Just to test it i tried to change it to v.2.4 (utf-16) and it worked!!
So thank you for mentioning the id3 I wouldn’t have ever thought to change that. You’d think Picard would that up and tell me something.
Also, the whole thing of it changing the Date to only the first 4 digits automatically was specifically an 2.3 thing it would seem.
ID3 is quite a mess in regard to uniformity and implementations.
It’s mostly a rather loose recommended standard, with no active or legal body of authority that controls or forces any ‘correct’ implementation.
In principle the 'D’s and 'Y’s in frames such as TYER, TORY, TDAT, TDRL etc. were likely intended to be Year vs Date, but most software will not enforce that, and will allow and use all sorts of variations of yyyy, dd-mm-yyyy for them.
It looks like Picard takes the ‘Y’ from e.g. the TYER frame literal (for v2.3 at least), so only populates it with yyyy.
Other software may use it more loosely, and allow and write variations such as dd-mm-yyyy.
Do you have any strange characters in your path?
Looks like you have a star character in the folder name and that may be causing problems saving the file.
Can you rename the folder and try again?
For ID3 2.3 Picard saves the year to TYER and day and month to TDAT (as DDMM) (which is how it is specified in the ID3 2.3 standard( . But in order for Picard to do this you have to specify the date as YYYY-MM-DD (that’s also how it is returned e.g. from MusicBrainz).
When Picard does not recognize the date format it just saves the first characters to TYER. So if you would have had “2016-06-19” instead of “20160619” Picard would have saved the day and month and loaded it back accordingly. How MusicBee deals with TDAT I don’t know, though.
For ID3 2.4 you don’t have this trouble, since there is only a single field TDRC. Btw, the ID3 2.4 standard would still specify the correct format as YYYY-MM-DD, but software usually does not care and displays and saves this as is. Still if you use some software that is able to display the date formatted, e.g. automatically as “June 16th 2016” , you would probably want to store the date as specified in the standard.
I don’t know either, since I have always set it to use use v2.4.
I know that for compatibility sake MusicBee is still able to read it when present, but I have no idea about how it writes it (D or Y) when in v2.3 mode.
To the OP: be aware that some hardware (portable) players will not be fully compatible with v2.4.
