GNOME Bugzilla – Bug 689432
Optionally delete unused/unknown fields from a file
Last modified: 2021-05-26 09:51:32 UTC
EasyTAG should optionally delete tags that are not shown in the UI. From the original bug: https://sourceforge.net/tracker/?func=detail&aid=3530633&group_id=5216&atid=355216 I'd like a way to delete any tags in files that aren't displayed/editable in the GUI. Right now I understand they're simply saved without modification. See this mailing list thread: <https://mail.gnome.org/archives/easytag-list/2012-May/msg00001.html>. The obvious way to solve this problem might be a button next to "Remove Tag(s)" that scrubs any tags from the file that aren't visible in the GUI. If that's hard to do, perhaps easier would be an action to scrub ALL tags from the file, but leave the GUI fields filled in. That way I could perform this scrub action, then simply hit save with the data I'd already filled in, to end up with the same minimal set of tags in the file.
Hi David, great to see easytag getting more attention. Since the old bug report seems to be unavailable, I'll add my workaround here. Until this feature becomes available, I've got a simple script that accomplishes the same thing: <https://github.com/chazomaticus/cleantags>. Cheers
Created attachment 278780 [details] [review] TRY to delete invisible ogg tag fields This patch just ignores unsupported fields when adding FileTag from vorbis comments during the reading file period. And a save-to-disk operation is needed but I don't know where and how to do this for now, do you have any idea about this?
Review of attachment 278780 [details] [review]: This looks like a good start. It should work fine for saving files with non-visible tag fields, because (if the setting is disabled), those tags will never be loaded. I do not think that a separate Ogg_Del_Invisible_Tag() function is needed for this reason, but can you explain why you think it would be needed? A useful thing to do when the in-memory tag data is different from the on-disk tag data is to set the "saved" field in the File_Tag structure to FALSE. This has the effect of marking the file as modified, so that it is displayed in bold (or in red) in the file list. Then, saving the modified file would remove the ignored tag fields. This same technique is used when changing the cover art format in Vorbis comments (search for "saved" in ogg_tag.c) and when converting between ID3v2.3 and ID3v2.4.
Thanks for your review! (In reply to comment #3) > Review of attachment 278780 [details] [review]: > > This looks like a good start. It should work fine for saving files with > non-visible tag fields, because (if the setting is disabled), those tags will > never be loaded. I do not think that a separate Ogg_Del_Invisible_Tag() > function is needed for this reason, but can you explain why you think it would > be needed? > hmm. because if user doesn't change any tags of a file (no save-to-disk operation will process), the invisible tags will not be deleted. > A useful thing to do when the in-memory tag data is different from the on-disk > tag data is to set the "saved" field in the File_Tag structure to FALSE. This > has the effect of marking the file as modified, so that it is displayed in bold > (or in red) in the file list. Then, saving the modified file would remove the > ignored tag fields. This same technique is used when changing the cover art > format in Vorbis comments (search for "saved" in ogg_tag.c) and when converting > between ID3v2.3 and ID3v2.4. so when del-invisible-tag setting is active and invisible tag field is not blank, we set the "saved" to FALSE.
(In reply to comment #4) > Thanks for your review! > > (In reply to comment #3) > > I do not think that a separate Ogg_Del_Invisible_Tag() > > function is needed for this reason, but can you explain why you think it would > > be needed? > > hmm. because if user doesn't change any tags of a file (no save-to-disk > operation will process), the invisible tags will not be deleted. Ah, that is correct. However, EasyTAG only does explicit saving, so it makes some effort to not modify files while reading them, only changing the file when the user activates the save feature. > so when del-invisible-tag setting is active and invisible tag field is not > blank, we set the "saved" to FALSE. Correct. That would have the effect of marking the file as changed in the EasyTAG UI, so that the user can initiate an explicit "save" action, which will then remove the extra tags from the selected files. This fits well with the "explicit saving" idea that I mentioned above. However, the original bug report mentioned a feature where non-visible tag fields could be removed from all selected files with the click of a button. Even though your suggestion would work well as that feature, this could be strange to most users, as it would act differently to the rest of EasyTAG. The feature could be added at a later time, but initially, I think that marking the file as changed when loading it (and ignoring the non-visible tags) will work well.
Created attachment 279057 [details] [review] invisible tag filed will be kept by default
> > (In reply to comment #3) > > > I do not think that a separate Ogg_Del_Invisible_Tag() > > > function is needed for this reason, but can you explain why you think it would > > > be needed? > > > > hmm. because if user doesn't change any tags of a file (no save-to-disk > > operation will process), the invisible tags will not be deleted. > > Ah, that is correct. However, EasyTAG only does explicit saving, so it makes > some effort to not modify files while reading them, only changing the file when > the user activates the save feature. > yes, I think we can keep the invisible tags by default and add a option in Preferences dialog to let user toggle this option, so if user use default setting nothing strange will happen and if not a explicit saving will occur only once for each location.
Review of attachment 279057 [details] [review]: Great, that looks like it should work well. I will push the patch to master once all the other tag formats have a similar level of support. Would you like to investigate a similar approach for ID3 tags? In the case of ID3 tags (at least for ID3v2.4, in Id3tag_Write_File_v24Tag), all the tags are read at the point of writing the file, so you would need to change the logic so that the tags were not loaded if PRESERVE_INVISIBLE_TAG_FIELD was set.
Great, but I think, replaygain fields should be kept, or they should be shown.
Patch has been in "accepted-commit_now" status for >200 days now. Anybody willing to push?
Review of attachment 279057 [details] [review]: Drop this to needs-work, as all tag formats should have the same level of support before this is merged.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new enhancement request ticket at https://gitlab.gnome.org/GNOME/easytag/-/issues/ Thank you for your understanding and your help.