None of the mp3tag views matches vlc view.
I looked into the mp3-edited file with the hex editor, and the Title in the vlc view and the Cover are really continue to live inside mp3 file.
I admit the original file may be incorrect. But after editing (-cover, +tags) mp3tag is responsible for tags correctness. vlc and mp3tag views mismatch after editing with mp3tag looks like a bug in mp3tag.
vlc is concurrent, 3.6.5.
mp3tag is concurrent development, v3.31k, 2025-11-07
This would mean to me that VLC has to update its display. AFAIK vlc has a cache that needs either to be cleared or updated.
Does the file show the updated data in VLC if you rename it before you open VLC?
You would have to check the settings which tags you read and write
I See APE tags in your file. So it could be that you still this data if you have not updated these tags as well
In addition to the potential caching issue, please also note that the file contains an APEv2 tag alongside the ID3v2 tag, including metadata and cover art.
This means that unless you also update this tag version with your changes, VLC might display what's found in the APEv2 tag.
I don't have VLC for Android to verify this, but you can check your tag reading and writing settings in Mp3tag:
And if you don't need the APEv2 tag, you can remove it via right-click Utils → Remove Tag Types...
So, mp3tag works as documented, thank you for pointing this out.
But now I have a problem. I have never recognized the fact the mp3 file may have 3 different sets of tags. Files, obtained from 3rd parties, may legitimately keep tags in any set, and even unevenly (and incorrectly) distribute tags between sets, like the file above.
To ensure I am not missing some information, like I just did, I have with mp3tag:
No.
In general, you would get hits more or less for every file that has V1 and V2 tags as e.g. V1 tags do not have a picture and no ALBUMARTIST. There are a number of other fields that do not exist V1.
Another problem could be the maximum length in V1 tags that truncates tag data. There is almost no effective size limitation in V2 tags.
And if you finally find real differences then it is not clear which data to keep.
I would assume that the V2 data is mainly correct.
I would check if there are special tag fields in the APE tags to adjust the volume (GAIN fields). If so, I would undo the gain information and see if I really need and if so, use a program that writes it to V2 tags and not APE.
If this approach is too dangerous, you could load the files, display the data for one Tag version at a time and export the displayed data to a text file that you could use to feed into a third party program for comparison.
OK, and what would you do until the feature is implemented?
There threads that date back to 2006 or see e.g. this thread:
and that nothing has changed in the meantime.
So far, the philosophy is that tag data from different file type and tag types have to be accumulated in an internal field variable. After that accumulation, there is no way to trace back which data came from which tag version.
I am not too confident that a change of the basic handling will come very soon.
Interestingly, in the span of 17 years between this and your prior post, the problem you experienced is virtually the same.
In theory one could load all of their files, select all, then blindly copy/paste/save the tags to have them all copied to your default write choice (I.e. id3v2.3). Then go back and remove all ape and even id3v1 tags. However this is a dangerous solution as potentially you could end up overwriting more current and more correct tag data already existing in the id3v2.3 fields.
Ultimately there is just no way that mp3tag can accurately guess which fields should stay and which should go. I suggest breaking your library down into batches, perhaps by alphabetical Albumartist, and go through each Album over time. It may take a while but at least you can be confident you made a conscious choice about the data you keep.
Indeed Good observation. I have firmly forgotten what I wrote in this forum and when. But my password keeper carefully preserved the login/password that better be forgotten
Good idea, and, you are right, it won’t work, because Mp3Tag does not merge or appends tags on paste, instead, it blindly replaces eponymous tags. Controversial decision.
It shouldn't. This is not a software job to decide, but a human job. But Mp3tag could assist it.
Thank you for suggestion. I am acting nearly as you suggest. Happily, I do not have too much mp3 files with ape tags.
Thank you for pointing this out.
