Periodically, I go through my albums and refresh the metadata to collect any edits that may have been made.
On many of the tracks, though, the will never clear the changes, even following these steps:
Start Picard
Drag/Drop Album
Save Changes (pending goes to checked, as expected)
Remove files (leaving album)
Drag/Drop Album - Tracks show changes to be saved again
After looking at the metadata spec and the binary files, I see that the tags are being saved in a different order! Is there some way I can get these to consistently save so that I will stop seeing changes?
Can you give a concrete example? Do you mean the order of the tags in general or the order of values for a multi-value tag? The first thing should not matter and can depend on different factors, the second one would be an issue. Usually loading a file should show the values for a multi-value tag in the same order as they were saved, if not I would consider this a bug. Another possibility is that the order loaded from MB server is not consistent.
Thanks for the info. I dumped the tags with metaflac and they are in a very different order, but they do all match (no diffs after sorrting). I don’t have any multi-value tags in this track, so I suppose Picard thinks something else is different. I was seeing something with the cover art - maybe that is the cause. I will look into it further.
Ok, the problem seems to be from the cover art. If I disable all the cover art sources, the track shows as matching. I enabled just the CAA and it shows differences. Showing the track info Artwork, I see that it is scrambled:
Indeed, cover art is the usual suspect here. There is an open issue PICARD-1001 about cover art and the changed status of releases. But this is a tricky issue and I wouldn’t be surprised if there is more than one root cause for this. But I haven’t looked into this myself in detail, yet.
Could you share some information on your setup? The following would be helpful to reproduce this issue locally:
Your exact settings in Options > Cover art and subsections there (a screenshot of the cover art related option pages and dialogs “Cover Art”, “Cover Art Archive”, “Cover Art Archive” > “Select types” dialog and “Local Files” would be great)
I could actually reproduce the issue. There are at least two causes. In general things seem to work very well as long as you only use front images and set Picard to only embed front images into the file. But as soon as you use something else it starts breaking. This was tested with MP3 files, other formats might result in different behavior.
Case 1: Picard is configured to load front images + other types (booklet in this case) from CAA. In Options > Cover Art all of “Embed cover images into tags”, “Only embed a front image” and “Save cover images as separate files” are set. This lead to Picard only embedding the front image, but save the booklets as files. In this case the files will always show up as changed, since the comparison compares only the images in the tags are compared against all the images loaded from CAA. This case is also mentioned in the above ticket. Probably not your issue, though.
Case 2: Same CAA settings as above, but “Only embed a front image” is deactivated. In this case all images get embedded into the file. Now all the images are present in the tags and from CAA, and they are the same. But they still don’t compare right, it seems to be some issue with sort order.
I assume this is the issue you encounter, below is a screenshot of the whole list of cover art. Interesting part here is the my file manager also shows the track listing as the preview image for the tagged files. It probably just uses the first image in the file (independent of type), which happens to be the booklet.
I need to check how the actual file looks. But the images loaded from CAA in Picard have the same order as on Release “Inside the Sky” by Steve Haun - Cover Art - MusicBrainz , but they seem to end up in a different order in the MP3 files. That’s bad, we need to save files in proper order . And likely always front images always first.
If you are indeed saving MP3 or other ID3 based format then the most likely cause for your specific issue is the image reordering I described above. Unfortunately it turns out this is a problem/feature of the Mutagen library we use to write the tags. It will sort all the frames written to ID3 by size, meaning the order of the images in the file depends on their size.
I opened bug reports for both Picard and mutagen, see
Ultimately I think we need to get this fixed in mutagen. What we could in Picard is actually ignoring the order of images when comparing, but I’m not sure this is a good idea in general. Maybe do this only for ID3 and possibly other formats where there is no stable order.
I am a heavy art downloader, and download everything available, but I don’t embed. I also don’t change the file times when tagging. Nearly always working with FLAC and sometimes MP3. Only use the single source of “Cover Art Archive” but there are always local files sitting in the folder too. I am very used to the purple star always being there.
Thank you for all the research! You have the correct release - I usually start with one I am familiar with and I know the cover art is well organized.
I am only embedding the cover image, the rest are kept in files with the release, so I believe Case 1 is the situation I am seeing. I am attaching my settings for reference in case it helps. I usually enable all the cover art providers, but it didn’t change anything. I also though the resizing of the images might affect it, but it didn’t appear to make a difference. I usually pull the full sizes.
Edit: Yes, I preserve existing tags (mostly to preserve replay gain and ratings). It doesn’t seem to be a problem, though.
All 5 tracks are showing the same change in the Producer tag: Original Value: Ronald Whitaker; Robert Woods; Elaine Martone New Value: Elaine Martone; Ronald Whitaker; Robert Woods
Looking at the first recording, here are the relevant relationships:
My original order doesn’t make sense, so I can see that it might want them in the order shown, and if so that’s good.
Is there any logic to put the producer first, followed by the assistant producers?
No, currently the people are taken in the order they are returned in the Webservice, and that’s currently Martone, Whitaker, Woods. But would make sense to introduce some order here, at least for things like additional, assistant etc. to be put later. You should open a feature request at https://tickets.musicbrainz.org
I had notice that change to “alphabetic order” in the credits. And it is a little worrying.
For example, Composer credits are in an order for a reason. With the Beatles, some tracks are “Lennon and McCartney” and others are “McCartney and Lennon”. This is due to who wrote the words and who wrote the music.
I can see occasions where people will have edited their tags manually using something else like MP3Tag to let them see these details in their files.
It seems wrong to me for Picard to ignore the order already in the file and say it is “wrong” and has “changed” even though it is the same list of artists. IMHO Picard should maintain the order already in the file. If there are five names in the tag, and the web service returns the same five but in a different order, then it should not be called “changed” data.
. And likely always front images always first.
