WinAmp can drop Comments

[RedivideR]

There is a bug in how WinAmp handles an ID3v2.3 tag with multiple Comments (COMM) frames. This flaw can then lead to data loss.

Based on examing the tags of some test files in a binary editor, WinAmp appears to be using the first COMM frame it encounters in the ID3 tag to set the Comments value that appears in the "View file info" window. But what it should be doing is using the COMM frame with a blank Description field.

According to the standard, the COMM frame in an ID3 v2.3 tag has a Text field, which stores the actual comments, and a Description field which stores a description about the comments. The tag can contain multiple COMM frames, as long as the Description field of the of the COMM frame is different. So, there should only ever be one COMM frame with a blank Description.

Because of this bug, a tag might have detailed comments, but you'd never see it in WinAmp, because it's showing the Text field from the wrong COMM frame. It's important to note that this is not a request to add a new feature to WinAmp to support multiple Comments frames. This is a report of a bug in how WinAmp chooses a single Comments frame to use from a tag that, according to the ID3v2.3 standard, can have multiple Comments frames.


This bug can be verified using either ID3-TagIT or MusicMatch.

To verify this bug using ID3-TagIT, follow these steps...

1) Make two copies of an MP3 file, Copy A and Copy B
2) In Copy A, first create a Comment with a blank "Comment Descriptor" field value and a Comment field value of "Comment without Description".
3) In Copy A, then create a Comment with a "Comment Descriptor" field value of "Description" and a Comment field value of "Comment with Description".
4) In Copy B, first create a Comment with a "Comment Descriptor" field value of "Description" and a Comment field value of "Comment with Description".
5) In Copy B, then create a Comment with a blank "Comment Descriptor" field value and a Comment field value of "Comment without Description". (We just switched the order of the same Comments frame.)
6) Open up Copy A in WinAmp and look at the Comments field in the "View file info" window. You'll see "Comment without a Description". This is correct, but only because the right frame happens to show up first in the tag.
7) Open up Copy B in WinAmp and look at the Comments field in the "View file info" window. You'll see "Comment with a Description". This is incorrect. WinAmp should have skipped over this Comments frame and used the second one.


To verify this bug using MusicMatch, follow these steps...

1) In MusicMatch, open up an MP3 with a ID3 v 2.3 tag with no Comments field.
2) Edit the tag info and enter "Comments entered before Tempo" into the "Notes" field.
3) Save the file.
4) Edit the tag again and set the Tempo to "Slow".
5) Save the file.
6) Open up the file in WinAmp and look at the Comments field in the "View file info" window. You'll see "Slow" and not "Comments entered before Tempo". (MusicMatch uses the Comments fields, with Description field values, to store additional information about a track like Temp.)


Admittedly, this bug will only cuase data loss under a narrow set of conditions. But because there is a chance that a user would lose their data just by using WinAmp, I would think it'd be worth it to install a non-WinAmp application to verify the bug and to take the time to implement the simple fix.

[I've posted this bug two times previously.]

- RedivideR

[DJ Egg]

Known and already fixed for 5.13

[RedivideR]

Cool! Thanks for the quick reply!

(I didn't see it in the known issues list.)

- RedivideR

[bugintags]

The above bug, far from being fixed, is ALIVE AND WELL in version 5.621

I made changes in songs' tags using ID3-TagIT, and the comments "disappeared" in WinAmp! Upon closer examination, it became clear that ID3-TagIT inserted some kind of blank "Comment Descriptor" in the comment, which apparently STILL confuses WinAmp

PS: you shouldn't require people who report bugs to have to register on your message boards....

[bugintags]

PS: here's a step-by-step way to REPRODUCE the bug. Everything is in ID3v2.

1) Start with a song that has a comment that was added by WinAmp

2) Import that song into ID3-TagIT. When viewing that entry, the comment is shown to possess a Descriptor with value "[]" , where [] is actually a little rectangle (I presume a non-ASCII character, such as NULL?)

3) Using the ID3-TagIT program, make any change in some other v2 tag of that song. For example, change the name of the artist. Save the change.

4) When viewing that song again in WinAmp, the Comment field in ID3v2 appears blanks! However, when the same song is viewed in ID3-TagIT, the comment (with the odd-looking Descriptor) is still there.

[ryerman]

Originally Posted by bugintags

PS: here's a step-by-step way to REPRODUCE the bug. Everything is in ID3v2.

1) Start with a song that has a comment that was added by WinAmp

2) Import that song into ID3-TagIT. When viewing that entry, the comment is shown to possess a Descriptor with value "[]" , where [] is actually a little rectangle (I presume a non-ASCII character, such as NULL?)

3) Using the ID3-TagIT program, make any change in some other v2 tag of that song. For example, change the name of the artist. Save the change.

4) When viewing that song again in WinAmp, the Comment field in ID3v2 appears blanks! However, when the same song is viewed in ID3-TagIT, the comment (with the odd-looking Descriptor) is still there.

How can we be sure that this is a Winamp bug?
Isn't it possible that there is a bug in ID3-TagIT concerning the comment field?
You are assuming that ID3-TagIT reads and writes tags perfectly, which ain't necessarily so!

[MrSinatra]

it would be good to verify this using mp3tag, which basically sets the standard.

its important to know whats going on here tho, b/c itunes routinely uses multiple comment fields, as the second field is where it stores soundcheck data.

also, test using 5.623, the most current winamp ver.