A release candidate for Picard 2.10 is now available. Please give this pre-release some testing. If everything goes well we will release the final Picard 2.10 shortly after next week’s MetaBrainz Summit 23.
Important changes are Python 3.12 compatibility and the move of translations to the MetaBrainz Translations Weblate instance. More details in the blog post:
Is it intentional that all types of ReplayGain tags are kept when ‘clear existing tags’ is enabled?
And I think this is also an issue, but I will probably need to dive in deeper to be sure what’s going on there.
At least it is not unexpected currently. One thing we changed is that replaygain tracks are treated as calculated data based on the audio and are handled the same as the AcoustID. For the calculated data the values stay with the file even if you move it around between tracks. They are essentially treated like preserved tags.
I need to explain a bit how metadata and clear existing tags actually works in Picard.
A file in Picard has two sets of metadata, original and new. The original is always as loaded from the file. Upon loading a file and having it in the left pane the new metadata originally is identical to the new one. If you change the metadata in Picard in any way, e.g. manually or through scripting, this changes only “new”.
If you load release data into the right pane the loaded tracks also have metadata (they also have original and new, but that’s for this discussion irrelevant). This metadata is essentially the data from MB plus anything being set by plugins or scripts or manually by you.
Now if you attach a file to a track the entire “new” gets replaced by the metadata from the track. That means any other changes to this data gets lost. One exception to this are preserved tags: If a tag is on the preserved list the data from the file’s “new” metadata gets set again after “new” was updated with track data, so preserved tags always stay a part of the file’s new metadata.
But for some data that is not part of the track but created from the files this feels odd. If you just did an AcoustID lookup and assign the file to a track you want the AcoustID to stay. Likewise it was confusing that when you calculated the replaygain for a file and changed the release version this data was gone again. Hence as the second exception these tags are categorized as “calculated” and treated essentially the same as preserved.
When saving a file all the metadata from “new” gets written to the file. If “clear existing” tags is off then new just gets written to the existing metadata (meaning all data in the file but not in “new” just stays). If “clear existing tags” is set then the metadata from the file is emptied first and then updated with “new”, meaning only “new” gets written and everything else is lost. But since preserved and calculated tags are always in new they get always written.
I’m really not sure how to change this without making other cases work worse. One thing we maybe could do is remove the “calculated tags” and instead set those tags by default into the preserved tags list. That way it would at least be more transparent how these tags are treated and the user could change them. But before we do that we must check whether this has any unintentional side effects.
One way for you to make sure the existing tags are always cleared would be to set a script that does delete those tags, e.g.:
$delete(replaygain_track_gain)