Unable to modify/clear ID3v2 `comments` field

[avengerx]

I have reproduced this with MP3 files from different sources, but if I set the id3v2 from WinAmp (2.95) or from the id3 tool itself (using Windows 64-bit build, v0.81), then these can be manipulated.

This is most likely a known limitation or bug since when the id3 tool is unable to modify it (or remove), then WinAmp 2.95 also is silently fails.

When an ID3v2 comment tag can't be erased it doesn't necessarily mean it can't be modified. I.e. if a file has the v2 comment field that cannot be cleared, it may or may not be possible to modify the comment field. If the field is "modifiable" in this situation though, by modifying the field then clearing it, it just returns it to the previous value.

It is as if the file uses an "alternative" id3v2 comment field that doesn't compete with the one the id3 tool manipulates. So sometimes (at least for old WinAmp 2.95), this field may or may not take precedence over the one this tool uses.

For the files I've found so far, they all also had id3v1 tags, and the comments field was always cleared (or updated) successfully. For instance, in a directory full of mp3 files with this problem, I could id3 --comment "" *.mp3 and the comments would get cleared from the id3v1 tag but not the id3v2 one.

A workaround for the issue is to id3 -2 --delete *.mp3 then re-create it. But then other id3v2 fields (like "composer") gets erased in the process and I can't simply recreate from the existing id3v1 tag.

~~I'm still trying to find a reliable way to reproduce this issue (or a public, royalty-free online MP3 file to share here), but so far I haven't had much luck with it. Perhaps if that's a known issue/limitation that doesn't have a reliable fix, it would be a waste of time to try to provide a repro. I've searched thru the open and closed issues and didn't find a corresponding one.~~

The steps to reproduce the issue (provided you have an affected MP3 file) is:

1. Open MP3 file in a player that has an id3 viewer (I'm using WinAmp v2.95).
2. Check for the "comment" field in the ID3v2 tag. It should be filled with something.
3. id3 --comment "" <filename.mp3>
4. Check again, the "comment field" will still have the same thing from step 2. The comment field gets erased in the id3v1 field if it was set.
5. id3 --comment "a" <filename.mp3>
6. At this point, it might show "a" (or still show the old comment).
7. id3 --comment "" <filename.mp3>
8. The same comment from step 2 is shown
9. id3 -2 --comment "" <filename.mp3>
10. The same comment from step 2 is shown
11. id3 -d --delete <filename.mp3>
12. The whole id3v2 tag is cleared. Re-creating the tag results in an id3v2 tag which the comments field is fully interactable with (tested re-creating with the tool and WinAmp v2.95 to the same result).

Maybe I can dump just the id3v2 tag from one of these files and share them here, but I'd need some directions in doing that, if this could help reproduce & potentially evaluate a possible fix for it. :)

Edit: After reviewing a few other issues here, I found that I could list custom tags with id3 -2v <file.mp3>, then to these files I get the following comments tag:

{COMM::eng}
        Something

And when I set something (step 5 above), it ignores the existing ::eng tag and creates:

{COMM::xxx}
        a

So it now has the two COMM tags, and the players may or may not use that to display the comments field. Perhaps the tool should check, when changing/clearing the comments field for id3v2:

1. check if it has one and only one COMM::* frame type, then manipulate it instead of COMM::xxx.
2. When it has several frames after COMM::*, it should show a warning (I'd say even if --verbose is not set), and then do its own COMM::xxx frame-type. There could be an extra commandline argument to either replace all comments frames, or wipe them all in favor of a single one. In particular, when --comment "", it could infer this and clear the frame for all languages (and show warning only when --verbose in this case)
3. If there are no COMM::* frames, then go ahead with the current COMM::xxx one.