Preserve all existing tags

New to mp3tag, as of today. I'm using it to convert ReplayGain tags to ITunNorm (Soundcheck) tags, using a custom action found here on the forum. It seems to be working so far. But mp3tag is also making other changes - it's adding ID3v1 tags, deleting TXXX Style tags when there are multiples, and possibly some other stuff.

Is there some combination of options that dictates, "Don't change anything, except what I explicitly edit" ? My collection is large and the tags have not been standardized, and I don't want to make any global changes now, since I don't have time to weed through and make individual decisions. All I want to do is add ITunNorm tags, and leave everything else as-is.

Turning off all three boxes under Tags->Mpeg->Remove, and turning off ID3v1 under Read and Write is close... but it still seems to mess with TXXX Style tags. (Which I guess is correct for ID3v2.3, but it's still losing information, and again, I'd like to just avoid changes rather than having to exhaustively hunt down everything that's being changed.)

How do you know?
If you add replaygain data - there are a couple of cases where this data is added as APE tags. Is that also true for your files?
If so, it could be that you now see the contents of the APE tag as that has priority over ID3 tags in MP3tag.
And generally: MP3tag does not modify untouched fields, it rewrites the tag, though.

Thanks for the reply. I know that the TXXX "Style" tags are being changed from comparing copies of the files before & after editing with mp3tag, using another program. The default behavior seems to be to remove all but once instance of TXXX "Style". Which is a reasonable default for ID3v2.3 - and I've discovered that I can also combine them with slashes via Merge Duplicates, which is also fine.

The larger point is that I don't want to have to discover all the instances where mp3tag is going to modify something by default, over a collection of 40000+ files. I just want to add a single tag, and leave everything else alone - even if mp3tag isn't happy with the existing tags for some reason.

So what I'd like is a configuration that says "preserve everything, modify nothing" (except ITunNorm). What I've currently got doesn't seem to do that.

w.r.t. the replaygain data - it exists as ID3v2.3, not APE. That's the one thing I know is consistent about these files, because I processed them all to generate the replaygain info over the past week.

Again: MP3tag does not remove fields - unless you tell it to do so.
Please check the extended tags dialogue and see how many fields of the user-defined type STYLE there are before and after saving.
Or to put it in another way: I just created 2 STYLE fields, saved the data and both were still there, nothing got deleted.

Please note that the double-backslash is the default character for MP3tag to show multi-value fields and also treat them like that.

Mp3Tag only writes ID3v1 tags if you enable this in
Tools->Options->Tags->Mpeg->Write

Thanks for the instructions. I did that same test on a file with multiple Style tags, and mp3tag does indeed show that the extra values are being preserved, as you suggested. Using Beyond Compare, however, shows that the tags are being combined into a single one. (I confirmed this change by using a hex editor.)

So anyway, that's good news. And as I mentioned above, I believe it's the correct behavior for v2.3 tags. But it is a change, nonetheless. Since this collection is large and unstandardized, I suspect there are other instances where mp3tag will read a tag and write it back in some "more correct" way - or maybe a tag is malformed and it doesn't know what to do with it at all.

I was hoping to disable such behavior, but it sounds like that's not an option. As an alternative, is there any way to get warnings when the file is read about data that are being reformatted, or are malformed or unreadable?

(poster: I also confirmed that turning off everything but Read ID3v2.3 and Write ID3v2.3 indeed preserves existing ID3v1 tags, but doesn't any new ones. Thanks.)

If you suspect that files are corrupt in some respect, run mp3diags and/or mp3val to check them first.
Then use MP3tag.

Yes, I have been using mp3diags, to diagnose files for which the replaygain calculation failed. Even though that was less than 10% of the collection, it took me about a week. It's an incredibly thorough program, with dozens of error codes. Even the author suggests "it's a good idea to delay any changes until they seem to be needed", which is my philosophy for the project. I'm not going to take a month to get everything "right" now - I'll just listen to the music as usual and fix any problems as they come up. Hence my desire for minimal changes.

Anyway, thanks for the replies. It sounds like mp3tag has a policy of retaining information by default, but doesn't provide a way to quickly scan for the few changes that it does make. Good to know. It may still be the right tool for the job. I guess I'll try a few dozen different files and compare the results manually to see what other changes might pop up.

One last follow-up for anyone who might come here looking for the same answer I was. I compared about 1000 files script-o-matically by using mid3v2 to dump the tags, and found the following changes:

  • Some TXXX tags were converted to explicit tags (TCMP, TSRC, TDAT, etc.)
  • COMM language codes were changed to "eng" for tags that were previously "xxx".
  • In a couple cases, COMM language was changed from "spa" to "eng". This seems to be the only available choice under Options->Tags-Advanced, and I guess it forces the change rather than preserving the original language. In any case, it was rare for my collection.
  • In one case, a POPM tag had a 0 (zero) changed to None. Strange, but doesn't bother me since I don't use ratings tags.

For about 150 files, I compared them manually using Beyond Compare, and found a couple other changes:

  • The combining of multi-valued tags (e.g. Style) as mentioned above. Again, this seems like a reasonable thing to do.
  • In a couple instances, some tags that showed up blank in BC (TOPE, TENC, TCOP, WXXX) were removed.

I did a further (but not exhaustive) comparison on about 60 files by dumping the raw tag data and comparing that. The biggest change I found is that most, but not all, tags were re-encoded from LATIN1 to UTF16. Again, it looks like the option you choose forces the change, rather than preserving what was there. Tags that remained LATIN1 included TYER, TPOS, TRCK, TDAT, iTunNORM, APIC. This doesn't seem to be an issue - it didn't increase the file sizes (surprisingly?), and reading the tags back out proved that the conversion didn't introduce any problems.

So overall, a non-trivial number of changes, but the substance of those changes didn't seem to be significant for my collection. It was not a particularly exhaustive test, given 40000+ files in the collection, but it was what I had time for. I'll most likely batch-run mp3tag on the entire collection to add iTunNORM tags, and just assume that anything else that it changes constitutes improvement / fixes.

You can write any language code in this field. You are not restricted to eng.
The language code you write there ist written to all files if you save files again.
In former times there was no option in MP3Tag to write this code. The code was retained from the language-version of MP3Tag.

If you want to get rid of ID3v1-tags and you are sure that there is no information stored that you have not preserved in an equivalent ID3v2-tag just mark only ID3v1 in options to delete and say Mp3Tag to delete tags (Red cross or edit->delete).

Did you check if the original file really showed multi-value-tags in the extended tag-view (ALT-t) of Mp3Tag?

All this looks to me that some wild taggers that write non-standard tags were used previously.
I would only be too glad if I had program that rectified all these invalid entries instead of claiming that everything should stay as it is.
Perhaps there is a misunderstanding: the modification of a single field always leads to the whole tag being rewritten. And I doubt that a policy which writes back invalid data would be a wise one. MP3tag does not do such a thing.
I still wonder why old, partially invalid data would be worth so much more than tidied-up tags.
If I were in the position to clean

I would first of all take care that the files are ok in respect to consistency. And this usually cannot be checked by

because hardly ever tag problems are audible.