I noticed some odd behavior after installing 2.90e. On OGGs that I converted from MP3s, every time I make an edit and then save the tags, duplicates of the YEAR field appear. I don't even have to do anything except hit Ctrl+S on a highlighted song to save the tags, and the duplication happens. And if I keep hitting Ctrl+S, the YEAR tag literally multiplies, from 2, to 4, to 8, to 16, etc. Anyway, in my settings, I have a VorbisComment mapping of DATE to YEAR, and another from TDRC to YEAR. I don't remember if those mappings came default, or if I customized them, or if it's even relevant to this issue. But, I'd hate to see this issue persist in the next release version of MP3Tag.
With mappings from two different source fields to one target field, you're essentially writing the same data back to those two different fields whenever you're performing a change.
you're reading the data from the two different source fields, but also writing back any content of the
YEAR field to those two mapped source fields.
Until v2.90e, I was dropping identical values for mapped fields, so that only one
YEAR field was displayed in Mp3tag. This resulted in the bug report Identical multivalue tag won't be written if mapped
Now with v2.90e, I've made the following change
- FIX: multiple occurrences of a mapped field with identical values were displayed as one. (#11432)
so that on reading mapped fields which have the same value, I'm not dropping duplicates anymore. This also means, that a file with both
DATE filled with the same value, are now displayed as two
YEAR fields. When writing back the change to the file, the two-valued
YEAR field gets mapped to both
DATE which are then also multi-valued and so on.
It's clear that this is not optimal and will probably result in headaches for those affected by this behavior. I'm open for feedback. At the moment it seems to me, that the decision is living either with this issue or the referenced issue.
Identical multivalue tag won't be written if mapped
Thanks for the reply. I had a feeling my issue would be related to that other referenced issue. I'll see if I can adjust something in my workflow to where the new fix won't be a problem for me. I'm hoping I could adjust my audio converter to map my needed tags there directly instead of relying on MP3Tag for the mapping, so then I shouldn't have any issue. I'll let you know in a few days, or as soon as tomorrow, what I figure out.
I think I've worked out a solution for my issue. First, I deleted my mappings in MP3Tag related to the DATE/YEAR fields, and then investigated what my audio converter does. My audio converter writes a DATE field by default to my output OGG files. So, I then changed my MP3Tag settings to display the DATE field in the Tag Panel and Columns, and I added an action to run as a final step, that converts the DATE field to a YEAR field, to satisfy my media player software. I'll be testing out these changes with a large batch of music I'll be converting and processing today and into the weekend, and I'll post another comment if anything goes wrong. But so far, I think I'll be fine with 2.90e as is.
The changed mapping sounds good to me. This way, you're also not writing those
TDRC fields on every change.
However, I've decided to revert the change. Mainly because some users might intentionally map two fields to one field in Mp3tag and would observe the same behavior you've described above.
I think I manually added the TDRC mapping a few years ago because an earlier version of my audio converter software wasn't playing nicely with MP3s that have ID3v2.4 tags; it was literally dumping TDRC fields into my output OGGs, instead of a proper YEAR or DATE field. So, that's what that mapping was for back then. Fortunately, my audio converter has since improved, and no longer does that. Also, my final action step in MP3Tag all along has been to strip all fields (such as iTunes junk from using an iTunes web source to fill in missing data) except the handful I need, and merge any duplicate-value fields.
However, before my adjustments a few days ago, I was still having a duplicate YEAR field even at the very end, I guess because I had more than one mapping for the YEAR field. Well, I guess my adjustments were unnecessary given you've reverted the change in 2.90f, but hey, at least this incident has given me a reason to audit my settings, and I still benefit from deleting mappings that are no longer needed in my case.