Mp3tag writes and modifies WWW fields (ID3v2 WXXX frames) without being asked to

If a user edits any piece of metadata in an MP3 file
(e.g., ALBUM, ARTIST, YEAR, etc.),

and the file contains WWW tags (WXXX ID3v2 frames),
Mp3tag rewrites WXXX frames to spec-conformant values,
although the user did not modify these WWW fields.

For example, an MP3 file may contain a multi-valued WWW tag:

After changing only the ARTIST field, maybe directly from File List, not the Extended Tags Dialog, the tags become:

Regardless of Mp3tag’s commitment to spec conformance (see [you can only one WWW field to an ID3v2 tag with an empty description]), the software must not alter data that the user did not ask to modify.

mp3tag is concurrent development: v3.32c, Nov 19 2025 12:36:00 (64-bit)
This is a followup to the [Can’t add more than one WWW tag into WMA file]

The question is: what did the user ask the program do alter? IMHO it is: modify the (whole) tag. And that should be written according to standard.
And the standard varies from file format to file format AFAIK.

Good for you. As for me, when I ask a program to change year, I mean literally: change year. And not to renovate embracing data according to the program taste.

This is not how tags look like. A tag is no table with cells to be filled in (and therefore cannot be addressed individually).
Instead, it is a data section of an accumulation of pieces of information that starts with a certain identifier, some householding data followed by the user data of variable size.
So, if you add/remove/edit a single piece of information, the whole tag part has to be rewritten - this could even lead to a completely new file if the orginal space for the tag part was not large enough.
And in the course of writing the whole tag anything non-standard gets corrected.

I do know what ID3v2 tag is, how the information is structured and organized, how it changes, gets serialized and written to file. Please stop convincing me that you have the right and, how I may conclude from what you are writing, even a duty to fix what you were not asked to fix.

Respectfully, you have already engaged a discussion directly with the developer, and were provided a reasonable explanation of the design decisions that were implemented. It seems to me that no further changes are planned for what was discussed. Breaking out separate new topics won't change that.

1 Like

Indeed, I have already asked

but didn’t get an answer. It is not unusual to miss some question, if many related are discussed at the same time. That’s why I isolated this one and 3 others as followups.

I'm treating this as a duplicate of your other post Silent data loss when saving recurring WWW/MP3 or certain/WMA tags which is basically on the same topic (here the data is already there and vanishes on write, there you enter the data and it disappears on write).

The slight difference is probably the change of the description text to uppercase, which you haven't mentioned in this post and which I'm treating as not a bug (as already mentioned elsewhere as a reply to one of your other posts).

Respectfully, no. “Silent data loss …” is about WWWs, that the user just manually added to the metadata list in the Extended Tags dialog.

This topic is about the WWWs that already exist in the file, as a matter of fact, whatever they are, and regardless of Mp3tag attitude to their structure.

Yes, I understand you. This is why I wrote

Am I missing something?

Oh, maybe, it’s me who missed the point. To me that’s absolutely different matters.

To fix this topic you should carefully copy all WXXX frames from old tag to new tag, as-is, untouched, like you do with PRIV frames.

To fix “Silent data loss …” topic you should tell the user that you refuse to construct repeating WXXX frame w/o description.

This is unfortunately only possible with frames that are unsupported by Mp3tag. Others, like WXXX, are parsed and made available to the internal metadata system, from which they're written back on rewrite.

I'm keeping this open for now, maybe there are indeed two different solutions for the problems described in each of the topics.

I've just released Mp3tag v3.32d, which follows the approach you suggested.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.