View Single Post
Old 8th May 2013, 17:25   #21
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,623
Send a message via AIM to MrSinatra
Quote:
Originally Posted by Aminifu View Post
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.

Quote:
Originally Posted by Aminifu View Post
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?

Quote:
Originally Posted by Aminifu View Post
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.

Quote:
Originally Posted by Aminifu View Post
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.

Quote:
Originally Posted by Aminifu View Post
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.

Quote:
Originally Posted by Aminifu View Post
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.

Quote:
Originally Posted by Aminifu View Post
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.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline