Having just updated, I find there is a newly introduced issue with tag renaming.
I have been going through my library and changing the year tags to reflect album year and single year, where single year had a previously defined '-' value.
Changing the 'Year' value to 'SingleYear' value in the 'Extended Tag' popup does not update the '-' value, instead I now get two listings, see attached.
The customised column indicates I only have the one SingleYear' parameter set (the one used for some time) with no similar named second entry; for instance a newly introduced blank.
As renaming does not override the '-' column value with a previous year value, say '1991', if I then delete the entry '-' in the column then neither 'SingleYear' tags remain listed in the 'Extended Tag' popup and the tag value is lost.
How do you change the YEAR to SINGLEYEAR?
As these are FLAC files - do you have a mapping for YEAR?
What does the definiiton for the column look like?
The tag 'Year' is the the one that comes pre-configured/mapped with MP3Tag which is viewable on the provided image. So, I do have a mapping for year, or how else would I be able to change it?
The definition, is below: and is the one provided by MP3Tag.
The 'Year' tag is not file dependent, MP3Tag can modify flac file tags!
As previously advised the 'Year' value is changed to 'SingleYear' in the 'Extended Tag' popup.
You appear to have missed the fact this method has been used for some time without problem, updating each new version as it becomes available, but is now a problem on this latest version; nothing else has changed from working to not working.
The "mapping" for tags is defined in the options > Tags>Mapping.
I tried to refer to the definition of the column for SINGLEYEAR as you say
There is something causing two similar fields to be created. Either this has become a multivalue tag under the exact same name, or there are two fields being defined possibly with a space or other "hidden" character or space at the end of the field name causing this? Note it doesn't have to be a defined column for there to be a different field.
Maybe try the action Merge Duplicate Fields for your SingleYear field to see if these two do become one, or if they remain two distinct fields. This would mean there is a definite difference in the two names.
Just to illustrate how to find a tag name with a (invisible) space at the end of its name:
If you click on the "Edit Field"-Icon and then select the Field-Name, you can see if there is a (unwantend) space at the end of the tag name.
But maybe it is really just a multivalue tag as @MotleyG mentioned and the two tag name are identical in this case.
If you click on "Add Field" and open the drop down box, you can see the problem too:
One entry is with a space at the end of its tag name, the other has no space at the end.
If you have ever used such a tag name, it remain on the drop-down list.
You would have to remove such an unwanted entry manually:
You're probably referring to changing the YEAR field name to SINGLEYEAR. If so, having then both instances of SINGLEYEAR fields listed is expected behavior. It's possible to have multiple of those and you'd have to manually remove the one with the - value.
It looks like the parameter definition already includes a trailing blank, i.e., %singleyear % instead of %singleyear% but I might be wrong. Can you double-check?
I can and have repeatedly changed other fields using this method and have never had a problem, so I do not believe I am doing anything wrong.
Changing the name from Year to SingleYear by using the drop down menu, only lists the one entry, so that cannot be the issue.
I cannot merge as when you close the 'Extended' Tab' popup the second Single Year is not listed. Reopening then displays the one Single Year so the second one, the one I am trying to overwrite, disappears and the value is lost. There is no additional value with any version of Single Year I can find. I had to restore my backup file to get the values back, then had to copy and paste each one individually rather than by batch.
I have tried this on several files and the result for Single Year is always the same, but only for Single Year.
Changing back to version 3.20 allows me to do what I have always done without this problem.
The MP3Tag default requested is shown below.
I will create video of the process and post later.
A suggestion while we await your video:
Perhaps you should not be so sure. Other posts in this thread have pointed to possible field naming errors. But regardless of what Mp3tag version you use, the larger and more important issue is that renaming fields is an unusual and risky way to copy data. You say that you just want to "do what I have always done", but what if there are better and far safer ways that work in ALL versions of Mp3tag?
For example, you could do a Tag to Tag Conversion. First you would apply a filter to show the set of files to process and you would select those files. Then you could copy values from their YEAR tags into their SINGLEYEAR tags with one operation, as discussed here: First Steps – Mp3tag Documentation and as shown in the screen shot below:
Next, if you want, you could clear the now unneeded YEAR field in the found set by using the Extended Tags dialog.
You have found that renaming fields to copy data can be perilous. Minor typos and invisible errors can cause weird problems, including the data loss you experienced. By contrast, when a Tag to Tag Conversion fails, it makes no changes. Furthermore, Tag to Tag will show you the changes it will make before making them. Just click on the Preview button.
So please experiment with Tag to Tag Conversion. It is easy, reliable, and much, much safer than mucking about with field names.
So where is the definitive instruction set for MP3Tag that defines how something should be done?
If software has been written that allows you to do something then that is a valid method, or else why bother writing it?
You complain about a result that you did not expect but
if not by you then at least by the one who has programmed it.
The forum participants are then friendly enough to show you a way to get to the result that you seem to expect.
There is no definitive instruction set as there are so many ways to skin a cat.
A good way in general would be to try to find a different approach if the original idea does fulfil not the expectations.
And if all that is not satisfactory for you: No-one forces you to use MP3tag.
You are absolutely right, of course, which is why I am sticking to 3.20 which does not have this problem.