and then clicks OK, the dialog closes without indicating any error.
However, only the last WWW tag is saved.
All other entries are silently discarded, without giving the user any chance to notice that their data has been lost. After saving the tags become:
It also occurs for any custom WMA tag, regardless of its name.
It also occurs for any built-in WMA tag (WMA attribute) that does not support multiple values.
This bug report is not about the validity of the design decision,
but about the fact that the software discards user-entered data without informing the user.
I am not sure what should be done instead.
A warning?
Just an example: if you choose to write ID3V2.3 and ID3V1 tags then data from ALBUMARTIST and the cover will certainly no be written to the V1 tags. Also, the data in GENRE will we either transcoded to a number or if there is no equivalent, saved as type "Other".
In normal operations this would mean for me that I would switch off this warning immediately as I would get it for every file.
If would become even more complex if more than just one type of files and more than one type of tags should be written.
Of if some fields refer to a standard item in some tags and user-defined ones in other tags.
So even though I agree that user data should be sacred, I have no idea how to cope with such varying cases and still get a usable program.
Just my thoughts.
Oh. So would you share your ideas with us? It would make it easier to follow.
Right now, I see nothing but obstacles that would render the tagging process virtually unusable when checks are carried out during input, after setting different options for reading/writing/deleting and if different file types and different tag types as part of the selection.
The correction of malformed tags would also take ages.
So where and how do you see a way out?
I'm glad that @ohrenkino and others are also answering posts and asking questions. If you don't want to answer, then just don't.
I think the whole reason for this community here is that people can think and collaborate together (otherwise there would be no point for this place). This implies, that some topics are discussed entirely without me, or that I might jump in later if I have a better understanding for myself, or if the discussion reached a point where it's necessary.
I think this point is now reached, and I'll think about possible solutions to not loose data when entering specific fields or when resaving files with those specific fields.
Because this bug report covers a broad range of possible implications, I don't have an easy answer (which I might have had, if this was only about supporting multiple WXXX frames).
I've just released Mp3tag v3.32d with changes on how Mp3tag writes ID3v2 and WMA tags.
When writing ID3v2 tags, Mp3tag now attempts to preserve the original ID3v2 frames if they are not modified by user input. This means that multiple WXXX frames, even those with identical descriptions, are now simply carried over during rewrites.
In addition, it is now possible to add multiple WXXX frames, including those with the same description, via Mp3tag. This does not conform to the ID3v2 standard, but I believe it is a practical tradeoff that reflects the current reality of ID3v2 tagging.
Because ASF/WMA tagging is very strict, I decided to store multiple values for fields that do not support them as Value 1; Value 2 when writing.
I hope this addresses all issues raised in this topic. Please also note that these changes required significant modifications to the code that handles ID3v2 writing, so please use with caution.
