-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
2.13.2
-
None
-
Windows 10 x64
Hi all,
I have Picard set to 'clear existing tags' but 'preserve these tags from being cleared':
Comments
comments
It works fine usually but I have found a case where if the Comment tag contains brackets Picard will interpret this as a new type of tag. This means the tags are no longer seen as 'Comment' tags and no longer preserved.
Example:
Comment: From Humble Bundle IndieGala 11 (2012-12-05)
Loaded into Picard becomes:
Comment [2012-12-05]: From Humble Bundle IndieGala 11
Right-clicking the tag and editing it shows 'comment:2012-12-15' has become the tag type:
I've tried working around this issue by adding additional 'preserve these tags from being cleared' entries, but they have not made an impact:
Comment*
Comment:
Comment:*
comment*
comment:
comment:*
I can at least prevent the tag being removed on this release by right-clicking and selecting 'Add to Preserve Tags' list, which adds it as 'comment:2012-12-05'. But this is obviously not ideal as it would need many thousands of 'preserve' tags to catch every possible comment date.
Thanks for your help.
![2025-02-18 13_54_33-Q__!Music - FLAC_80s_Stallone-2012-Hotline-[2012,XWW]-16BIT-44KHZ-WEB-FLAC-Offic.jpg](/secure/attachment/17038/2025-02-18%2013_54_33-Q__%21Music%20-%20FLAC_80s_Stallone-2012-Hotline-%5B2012%2CXWW%5D-16BIT-44KHZ-WEB-FLAC-Offic.jpg)
- has related issue
-
-
- Open
-
[PICARD-3035] A Comment tag containing brackets is treated as a unique tag in Picard
Ah I see. Well with the added context that this is a feature, then your plan to pursue resolving wildcard matching for preserve tags definitely makes more sense - no need to reinvent the wheel to fix what I presume is a fairly uncommon edge case.
Thanks for taking the time to explain.
Picard stores the tag "comment:description" with value "some text" as a Vorbis tag "COMMENT" with value "some text (description)", and also loads it accordingly again. This is not a bug but intentional behavior.
Storing the comments differently would be a breaking change. I don't think we can change this without breaking things for other uses.
I could be considered for a major version change (e.g. Picard 3). But what would be the proposed alternative to store and load "comment:description" tags without loosing information?
Thanks for the quick response and suggestion, that would solve the issue for me.
But I think the root problem is that Picard should not be interpreting 'comment' tags that contain brackets in their text field as a new kind/variety of tag entirely. If that was resolved my specific issue would also be resolved.
I presumed this to be a bug - why would Picard interpret it as a 'comment:2012-12-05' tag, is it intentional?
This is what an example raw file looks like, it's just a standard 'COMMENT=' tag:
So looks like we need some possibility to specify wildcard matching for preserve tags. At least for the case of tag names with additional description.
PICARD-2938 is essentially the same, but for performer.