Winamp Tag Editor not reading ID3v1 genre tag correctly

[Aminifu]

I use the Winamp tag editor (Alt+3) to read and write ID3v1 and ID3v2 tags for my files. I mostly use v2 tags, but I need v1 tags to support an old mp3 player I still use.

Anyway, the editor's Basic Info tab displays the ID3v2 tag info from the file as shown on the ID3v2 tab, but the ID3v1 tab's genre tag does not display the genre tag data from the file. Instead it displays whatever that tag was last set to in the tag editor.

Making a tag change on the Basic Info tab or just clicking OK (without checking the ID3v1 tab entries) will rewrite the file with whatever was set for genre on the ID3v1 tag for the ID3v1 tags, causing this tag to potentially have the wrong value.

I'm aware that the ID3v1 and ID3v2 genre codes do not match, so making a ID3v2 genre change requires making a matching ID3v1 genre change. But it should not be required to check the ID3v1 genre when making a non-genre tab change.

[MrSinatra]

i am completely confused by what you are saying.

to my knowledge, an id3v2 genre tag can contain any value. an id3v1 genre tag however has to be either blank, or one of a limited set predefined list, thats set by the spec i believe, which actually are numeric codes.

obviously, this means that some, or possibly most, id3v2 values will not match the id3v1 values.

so assuming you agree with all that, explain what is happening that you think is wrong, and the exact steps to reproduce.

[Aminifu]

Originally Posted by MrSinatra

i am completely confused by what you are saying.

It's a terminology disconnect. I don't mean value in the literal sense. Just the data that is shown in the editor. As far as genre goes, codes are used per spec, but we see the word "Country" for instance, instead of the code. A particular code in ID3v1 can mean something else in ID3v2, but that is not what I'm talking about.

I'll try explaining in a different way.

Say you have a blues song and you set the ID3v1 and ID3v2 genre tags to 'Blues' on the ID3v1 and ID3v2 tabs (using the selection lists on the respective tabs) in the Alt+3 editor and save the file. Then you do the same thing with a rock song, set the v1 and v2 genre tags to 'Rock' on the v1 and v2 tabs in the Alt+3 editor and save the file. Now go back and view the tags for the blues song. When you click on the v1 tab, you should see 'Blues' as the genre, but instead you see 'Rock'.

[MrSinatra]

Originally Posted by Aminifu

It's a terminology disconnect. I don't mean value in the literal sense. Just the data that is shown in the editor. As far as genre goes, codes are used per spec, but we see the word "Country" for instance, instead of the code. A particular code in ID3v1 can mean something else in ID3v2, but that is not what I'm talking about.

yes, i understood all that.

Originally Posted by Aminifu

I'll try explaining in a different way.

Say you have a blues song and you set the ID3v1 and ID3v2 genre tags to 'Blues' on the ID3v1 and ID3v2 tabs in the Alt+3 editor and save the file. Then you do the same thing with a rock song, set the v1 and v2 genre tags to 'Rock' on the v1 and v2 tabs in the Alt+3 editor and save the file. Now go back and view the tags for the blues song. When you click on the v1 tab, you should see 'Blues' as the genre, but instead you see 'Rock'.

that would def seem to be a bug. that info should, imo, be parsed fresh from the file everytime alt+3 is done, as opposed to the DB or last used values in the alt+3 dialog.

can you reproduce this 100% of the time, or is it intermittent?

what did the basic tab have to do with it? (i found bugs with that before, esp where id3v1 was concerned, which is partly why i recommend stripping all v1 tags, to avoid these kinds of incongruities. i basically operate only on the id3v2 tab in alt+3 these days. i understand why u keep them, but perhaps its time to retire the old player?)

[Aminifu]

Originally Posted by MrSinatra

can you reproduce this 100% of the time, or is it intermittent?

what did the basic tab have to do with it? (i found bugs with that before, esp where id3v1 was concerned, which is partly why i recommend stripping all v1 tags, to avoid these kinds of incongruities. i basically operate only on the id3v2 tab in alt+3 these days. i understand why u keep them, but perhaps its time to retire the old player?)

I just noticed it, but it seems to be 100% reproducible.

After my initial vetting, I seldom have a need to change anything. When I do, I have been using the Basic tab to enter changes, expecting them to transfer to the v1 and v2 tabs (and subsequently to the tags) correctly. I knew some things would change from v2 to v1, like '01' for a track # to '1' or a long album name would be truncated. If I made a genre change, I knew I had to do it on the v1 tab also (since v1 and v2 genre codes don't always match). I was not expecting tags that were not changed to be changed (which appears to only happen with the v1 genre tag).

My old player still works fine (and has a longer battery life than some of these newer players) and I have others. Its only issue is capacity. Anyway, I see no need to retire it because of a quirk in Winamp. Now that I'm aware of the issue, I can deal with it. But it should be fixed, if possible.

[DrO]

i know what Aminifu means and i've seen it happen a handful of times (though couldn't determine the cause of it when i saw it a while back).

-daz

[MrSinatra]

well, if he's so inclined, i would appreciate an exposition.

[DrO]

it's clearly explained in the first post - i don't see what the confusion is.

-daz

[MrSinatra]

i agree that its a bug and should be fixed. if every file was freshly parsed with each alt+3 invocation, i would think it would work properly.

[MrSinatra]

it might be helpful (given the convo in the other thread) to give exact steps to reproduce so DrO can try again to replicate, and maybe a file to do so with as well, one that does it for you. I could also attempt to do so.

[Aminifu]

Originally Posted by MrSinatra

it might be helpful (given the convo in the other thread) to give exact steps to reproduce so DrO can try again to replicate, and maybe a file to do so with as well, one that does it for you. I could also attempt to do so.

The steps to reproduce were given above in post #6. I don't think it is anything peculiar to my files. All mp3s with ID3v1 and v2 tags should exhibit this behavior.

This is a minor issue for me (it is only an ID3v1 tag after-all). Now that I'm aware of it, it has become a simple thing to deal with. Just another part of Winamp's personality.

I only mentioned it in the other thread because it acts the same as the issue with flacs being discussed there. I'm sure flac format users are more concerned.

[MrSinatra]

I was asking for something more step by step, numbered, explicit, so that DrO and I could follow EXACTLY the same steps you do, and the file would allow us all to work on the same thing, so that if any of us had differing results, that would be really instructive.

short of that, its hard to be helpful.

[Aminifu]

@MrSinatra

DrO understands the issue (posts #3 and #5 above). Since he and/or other Winamp devs are the only ones who can do anything about it, I think what has already been provided is sufficient.

I do appreciate your concern.

[MrSinatra]

and as he stated, he can no longer reproduce. there is a way to do things, and a way not to do things, and when it comes to squashing bugs, its clear which way this is.

[DrO]

...for FLAC... not for this.

[MrSinatra]

Originally Posted by DrO

...for FLAC... not for this.

wow, a response!

post 37 in that thread seemed to be in response to this, not FLAC, but either way my point above is valid. when I want a bug fixed, and I have known steps to reproduce, I explain how to do so exactly and often provide a file, so that others may verify. the more things are left ambiguous, the more chance for something to get missed. (its a worthy exercise not only b/c it is called for in the bug report instructions, but also b/c u have times when things are unique to a user, like 3rd party codecs)

[Aminifu]

Originally Posted by MrSinatra

(its a worthy exercise not only b/c it is called for in the bug report instructions, but also b/c u have times when things are unique to a user, like 3rd party codecs)

Of course a formal procedure has merit. When it comes to where this case falls on the bug list, there are bigger fish to fry, imo. But, like I said, if one of the devs wants a formal test, I'll be happy to join in.

As to the other thread (you linked) and 3rd party codecs, that has nothing to do with this case. I only use Winamp and Winamp provided codecs with my mp3s. That other thread was about a different format and I was associating it with a different app when our results differed. When I associated that format with Winamp, our results were the same.

[Aminifu]

If DrO or another dev wants to outline an experiment, I'll be happy to join in.

[MrSinatra]

that's not the point I was trying to make, the other thread was not related b/c of 3rd party codecs. it was about yet another genre issue, (3 so far) which is why I posted it.

the point about 3rd party codecs, which I wasn't saying def was (or wasn't) related to this threads bug, was actually a reference to the ratings display issue, which showed that a user could have unique results without being aware of it. the more people who test the same way, the more likely you are to find if something like 3rd party codecs are to blame, (if that ends up being the case).

I don't care at all about v1 tags personally, but if any time by devs or anyone is to be spent looking at anything buggy, I believe in doing it as methodically as the best information one has allows. I guess that's a radical pov.

and actually, even though I don't care about v1 itself, I frequently learn aspects that improve my overall understanding and bug spotting abilities by going down these rabbit holes.

[Aminifu]

Originally Posted by MrSinatra

that's not the point I was trying to make, the other thread was not related b/c of 3rd party codecs. it was about yet another genre issue, (3 so far) which is why I posted it.

Ok, but that thread is about different apps and codecs using slightly different look-up tables for the numerical codes associated with ID3 genre values. Maybe the look-up tables should be the same, but it does not surprise me that different apps and codecs would use different implementations when they can. Look at how ratings are handled for example.

This thread and the one about flac are not about that and are basically talking about the same issue. Namely, instead of displaying the genre value read from the file, the value displayed is the last one used in the Alt + 3 dialog. Maybe the latest internal build fixes this, we will see in time.

Bringing that other thread into the discussion needlessly confuses things and frankly I have a hard time reconciling that with your methodical approach to troubleshooting.

Originally Posted by MrSinatra

I don't care at all about v1 tags personally, but if any time by devs or anyone is to be spent looking at anything buggy, I believe in doing it as methodically as the best information one has allows. I guess that's a radical pov.

Is it a radical pov to believe that a formal standard procedure is not needed in all cases?

To fix this issue, access to the Winamp code and a working knowledge of what that code is trying to do is required. When someone with the access and knowledge says the issue is understood, then it is a waste of time to re-present the issue in an alternate way, imo.

To find a work-a-round for this issue (or any issue), code access and a working knowledge of the code is not needed, imo. Any Winamp user is able to come up with suggestions. People are very ingenious. A user's suggestions can sometimes trigger an idea with a dev as to where to look in the code. A formal standard troubleshooting procedure is not needed in order to provide suggestions and work-a-rounds could be equally workable or off-base, if a formal procedure is used or not.

It is not easy to know when the Winamp standard troubleshooting procedure is needed. But from reading threads (new and old) over the past 2 years, it is not used very often and it becomes clear pretty quickly (and asked for) when it is needed. Many times there is no real issue, the user just needed to have read the documentation. Imagine the time wasted (reading or skimming through stuff) for those trying to help, if the user in those cases presented all the formal info.

[MrSinatra]

Originally Posted by Aminifu

Ok, but that thread is about different apps and codecs using slightly different look-up tables for the numerical codes associated with ID3 genre values. Maybe the look-up tables should be the same, but it does not surprise me that different apps and codecs would use different implementations when they can. Look at how ratings are handled for example.

This thread and the one about flac are not about that and are basically talking about the same issue. Namely, instead of displaying the genre value read from the file, the value displayed is the last one used in the Alt + 3 dialog. Maybe the latest internal build fixes this, we will see in time.

you are making assumptions all over the place. lets see how it shakes out before we draw conclusions. and i'm not challenging that this is the case, i'm just saying its not for sure known to be the case yet.

Originally Posted by Aminifu

Bringing that other thread into the discussion needlessly confuses things and frankly I have a hard time reconciling that with your methodical approach to troubleshooting.

that's your opinion, not mine; obviously I disagree. in the other thread I said it was "interestingly related" and it is. we now have 3 formats that all have some kind of issue with the genre tag. at no point did I say that they are all somehow connected beyond that, or that they share an underlying cause.

but it is interesting that to the casual observer, they would seem very similar.

I tend to agree that the m4a issue seems to be differing encoding codecs, (not playback ones) while the flac/id3 issue seems to be in the UI/file parsing, but I await the facts. and it may turn out that the cause for the FLAC/id3 issues are also separate.

one assumes the devs will truthfully and graciously explain the case when known.

regardless, I don't think there's anything wrong with referencing the m4a example, as it was a real brainteaser... until it wasn't. it cleared the UI of wrong doing, and that COULD happen here, could it not?

Originally Posted by Aminifu

Is it a radical pov to believe that a formal standard procedure is not needed in all cases?

no, but you assume this one doesn't need it. I think it does. we disagree. so be it.

Originally Posted by Aminifu

To fix this issue, access to the Winamp code and a working knowledge of what that code is trying to do is required.

of course, to FIX ANY issue, that's whats required.

but to diagnose it? its not.

Originally Posted by Aminifu

When someone with the access and knowledge says the issue is understood, then it is a waste of time to re-present the issue in an alternate way, imo.

you are far more trusting than I. I have nothing but the utmost respect for the devs, I think they are honest, hardworking, and talented, be they DrO, Egg, Benski, whoever. but they are not gods, nor are they infallible. I have had to engage in dialogue, sometimes in a testy way, to get them to see the light. ratings come to mind. in other words, they can make mistakes and they can also sometimes be enlightened by lowly users, such as myself. (had I just taken the dev party line, they'd still be broken today. and I did so at the expense of my personal relationship with them, b/c the truth is to me, more important)

and even if you don't agree with that, the exercise can, in and of itself, have unforeseen benefits.

Originally Posted by Aminifu

To find a work-a-round for this issue (or any issue), code access and a working knowledge of the code is not needed, imo. Any Winamp user is able to come up with suggestions. People are very ingenious. A user's suggestions can sometimes trigger an idea with a dev as to where to look in the code. A formal standard troubleshooting procedure is not needed in order to provide suggestions and work-a-rounds could be equally workable or off-base, if a formal procedure is used or not.

not sure what this has to do with anything, but just fyi, the stickies call for a formal method when reporting bugs. not saying I always do it myself, I don't, but I have never failed to do so when ANYONE asks me to, to the best of my abilities.

that's just me, radical.

Originally Posted by Aminifu

It is not easy to know when the Winamp standard troubleshooting procedure is needed. But from reading threads (new and old) over the past 2 years, it is not used very often and it becomes clear pretty quickly (and asked for) when it is needed. Many times there is no real issue, the user just needed to have read the documentation. Imagine the time wasted (reading or skimming through stuff) for those trying to help, if the user in those cases presented all the formal info.

its one thing to report a problem. its another to report a problem, a cause, and a solution. are you saying you know all 3? how, without access to the code as you specified earlier?

i'm not trying to be argumentative just to be argumentative, I am trying to illustrate a point. you claim above to be concerned about time... but what about scenarios where your assumptions are wrong?

again, I don't claim to know if your assumptions are correct or not. I would not be surprised either way. HOWEVER, I do know that the more people one has to test out an issue, and try to replicate it, the LESS likely it will turn out to be that said issue is somehow unique to any of the people involved. that technique was very useful in showing why you and ryerman had different results than I did with ratings.

so there you have it. the v1 / genre issue[s] isn't worth all this back and forth, but I do consider it worthy to layout the principles here, since future issues, likely more important ones, call for it.

[Aminifu]

Originally Posted by MrSinatra

one assumes the devs will truthfully and graciously explain the case when known.

I'll be happy if the problem is just fixed.

Originally Posted by MrSinatra

of course, to FIX ANY issue, that's whats required.

but to diagnose it? its not.

I guess we have a different understanding of what "to diagnose" means.

Originally Posted by MrSinatra

you are far more trusting than I. I have nothing but the utmost respect for the devs, I think they are honest, hardworking, and talented, be they DrO, Egg, Benski, whoever. but they are not gods, nor are they infallible.

The devs are human. Of course they can and do make mistakes. But if one says he understands something I can accept that until proven otherwise.

Originally Posted by MrSinatra

and even if you don't agree with that, the exercise can, in and of itself, have unforeseen benefits.

True. And it can waste time, and yes, I'm mostly concerned about my time.

Originally Posted by MrSinatra

not sure what this has to do with anything, but just fyi, the stickies call for a formal method when reporting bugs. not saying I always do it myself, I don't, but I have never failed to do so when ANYONE asks me to, to the best of my abilities.

Good for you, I'm not that charitable. I do know what the stickies say. I've read all of them, several more than once or twice. It is interesting that on one hand you say the devs are not gods (which is true), then you argue to follow their instructions (in the stickies) as though its gospel.

Originally Posted by MrSinatra

its one thing to report a problem. its another to report a problem, a cause, and a solution. are you saying you know all 3? how, without access to the code as you specified earlier?

I don't know where that comment comes from or how you got to that from what I wrote.

Originally Posted by MrSinatra

so there you have it. the v1 / genre issue[s] isn't worth all this back and forth, but I do consider it worthy to layout the principles here, since future issues, likely more important ones, call for it.

Good to know your view of the principles involved here, although I think I already had a pretty fair idea. We are all human and therefore can be wrong. I could even be wrong about that last comment.

[MrSinatra]

Originally Posted by Aminifu

I guess we have a different understanding of what "to diagnose" means.

for your edification:

http://www.merriam-webster.com/dictionary/diagnose

Originally Posted by Aminifu

The devs are human. Of course they can and do make mistakes. But if one says he understands something I can accept that until proven otherwise.

and that's what leads to faulty implementations.

doveryai, no proveryai

the point of the procedures is to prevent people missing things. blind trust has little utility.

Originally Posted by Aminifu

True. And it can waste time, and yes, I'm mostly concerned about my time.

taking shortcuts can also waste time. that's the point u seem to miss.

Originally Posted by Aminifu

Good for you, I'm not that charitable.

indeed. well proven i'd say.

Originally Posted by Aminifu

I do know what the stickies say. I've read all of them, several more than once or twice. It is interesting that on one hand you say the devs are not gods (which is true), then you argue to follow their instructions (in the stickies) as though its gospel.

not nearly as clever as you intend. just b/c the devs state a truism, (a SOP), does not mean they invented it, or that its credible b/c they happen to utilize it. they simply recognize the worthiness of such a paradigm. its a universal truth, and not a controversial one.

Originally Posted by Aminifu

I don't know where that comment comes from or how you got to that from what I wrote.

in the last few recent posts, you have drawn conclusions about what this problem is or is not. you complain about me bringing m4a in but you mention this in the FLAC thread, (where DrO can NO longer reproduce btw). you state you don't think its your files. and so on... one need only read your posts to see that you have reached many conclusions. they may or may not be correct. the point, as I see it, is that I can neither verify, or disprove, your assertions conclusively, if you will not provide steps nor files. that's your choice, I accept it, c'est la vie. the only reason i'm still posting is to explain my POV.

Originally Posted by Aminifu

Good to know your view of the principles involved here, although I think I already had a pretty fair idea. We are all human and therefore can be wrong. I could even be wrong about that last comment.

likely so, i'd say.

[DrO]

there will be some changes relating to this in 3383 or anything newer.

[Aminifu]

Originally Posted by DrO

there will be some changes relating to this in 3383 or anything newer.

Ok. Thank you for giving some time to this, I know you currently have bigger issues to deal with.

[DrO]

issue confirmed as due to my deprecated gen_os_diag.dll plug-in.

solution is to remove the plug-in or allow the Winamp 5.7 (and later) installers to remove it.