BUG? bitrate reporting...

[MrSinatra]

wow, fast fixes DrO! i will test asap, but unfortunately it may be a while, as real life has gotten in the way unfortunately! however, i am excited to see how it is!

any chance these fixes will improve the very short file skipping problem?

[DrO]

take your time, only got around to looking at it whilst stone-walling on something else i'm trying to work on.

any chance these fixes will improve the very short file skipping problem?

i highly doubt it as that's due to the output plug-in(s) from what i remember of the issue you're referring to.

-daz

[MrSinatra]

hey DrO,

finally got some time to examine this. question: does the dll you sent me on PM include the TCMP fixes egg made? both list as 4.97

ok, so the good news is that this file is much better at getting things right in the ML. the bad news is i still have stragglers.

first off, you have to highlight and "read metadata" on all suspected items in order to update the ML. short of clearing the ML completely, i don't know another way to do it.

secondly, would you believe i had 519 files that the ML reported had a bitrate somewhere between 257-319? of those, almost all changed to the correct bitrate. some didn't. some weren't mp3s or were "real" VBRs, so not applicable, but some are 256 CBRs, that i ripped with EAC, just short.

thirdly, i found some strange behavior on the other end. i have a couple of songs i downloaded that ML and file info both report as vbr 318kbps, however the player when playing reports it as a 320, until the last silent moment, when it goes 32kbps for a split second. i figure this is just the files own weirdness, but i thought i'd report it anyway. (i consider this a file problem of some sort)

similarly, i have some stuff that i am almost certain is true VBR that the info window and ML get correct, but that the player reports as 256 CBR while playing. i suspect these are XING header files. (i consider this a winamp problem)

so anyway...

i have 159 CBR mp3s at 256kbps still mis-reported by the ML as 257 or higher. they all seem to be under 10 seconds long.

i'll try to upload some examples here in a bit...

[MrSinatra]

of the 159, none are longer than 15 seconds. most are under 10, but a decent amount are between 10-15secs. here is a 15 sec one:

http://www.mediafire.com/?v8uuo3xu05ruiou

similarly, i have some stuff that i am almost certain is true VBR that the info window and ML get correct, but that the player reports as 256 CBR while playing. i suspect these are XING header files. (i consider this a winamp problem)

here's an example of that:

http://www.mediafire.com/?hjefnwndve10jox

i have since found this m4a file that is vbr, but file info doesn't say so. it reports 130, while the ML reports 129.

http://www.mediafire.com/?h26avc1amn4b3fz

[DrO]

finally got some time to examine this. question: does the dll you sent me on PM include the TCMP fixes egg made? both list as 4.97

it should do as it was based on the current internal code at the time of building (though i could be wrong, heh).

first off, you have to highlight and "read metadata" on all suspected items in order to update the ML. short of clearing the ML completely, i don't know another way to do it.

that is the only way to do it (and is how i've been doing it).

thirdly, i found some strange behavior on the other end. i have a couple of songs i downloaded that ML and file info both report as vbr 318kbps, however the player when playing reports it as a 320, until the last silent moment, when it goes 32kbps for a split second. i figure this is just the files own weirdness, but i thought i'd report it anyway. (i consider this a file problem of some sort)

if it is vbr then that would make sense as it works out the average kbps for the whole file.

similarly, i have some stuff that i am almost certain is true VBR that the info window and ML get correct, but that the player reports as 256 CBR while playing. i suspect these are XING header files. (i consider this a winamp problem)

not sure but then this is getting further from what i've got the time and knowledge to work on with the original issue seen.

of the 159, none are longer than 15 seconds. most are under 10, but a decent amount are between 10-15secs. here is a 15 sec one:

am seeing it with that, will try to find a moment to look into what is causing it as it's probably related to the other files you're seeing quirks with.

similarly, i have some stuff that i am almost certain is true VBR that the info window and ML get correct, but that the player reports as 256 CBR while playing. i suspect these are XING header files. (i consider this a winamp problem)

i've had a quick play and that is definitely a vbr file and is reporting things correctly as over half way through the file the bitrate is at 320 though it does sit at 256 a lot. mp3tag also matches with the bitrate reported at 269 which Winamp is showing throughout.

i have since found this m4a file that is vbr, but file info doesn't say so. it reports 130, while the ML reports 129.

not sure about m4a files at all though can confirm it shows 129 in the ml and 130 in the alt+3 dialog (matching mp3tag).

-daz

[MrSinatra]

if it is vbr then that would make sense as it works out the average kbps for the whole file.

right, its just weird that it is VBR. DL'd files are always freaky, its amazing how crappy some tools are that make them.

am seeing it with that, will try to find a moment to look into what is causing it as it's probably related to the other files you're seeing quirks with.

right on. i can try the next fix and upload any stragglers from it if any remain. while all are under 15secs, its important to note that a good many files which are under 15secs were fixed. so its not ONLY shortness, but i think shortness combined with something else.

not sure but then this is getting further from what i've got the time and knowledge to work on with the original issue seen.

i've had a quick play and that is definitely a vbr file and is reporting things correctly as over half way through the file the bitrate is at 320 though it does sit at 256 a lot. mp3tag also matches with the bitrate reported at 269 which Winamp is showing throughout.

yeah, you're right, i should have been more careful. whats odd is thats an album i DL'd, (a very cool one, see here) where the other tracks i spot checked are VBR but the rate changes constantly in the player screen. oh well, no winamp problem here in any case.

not sure about m4a files at all though can confirm it shows 129 in the ml and 130 in the alt+3 dialog (matching mp3tag).

-daz

well i'm not too concerned over it, but i would ask you to please log it officially in the Devs bug tracker so its a known issue.

don't miss this:

http://forums.winamp.com/showthread.php?t=334731

[DrO]

right, its just weird that it is VBR. DL'd files are always freaky, its amazing how crappy some tools are that make them.

that's the fun of downloading music

don't miss this:

http://forums.winamp.com/showthread.php?t=334731

i'm not going to get involved in that issue and as i've commented in other threads about short file handling, it's a fundamental design flaw with how the system works. yes it probably shouldn't crash though i've not seen it crash on short ( < 1sec files) in years.

-daz

[MrSinatra]

i understand, i just figured a crash should be reported and i can reproduce it 100% of the time. i tried some things on it which i'll report in that thread. i was also hoping that by demonstrating the crash, which i haven't been able to reproduce on ANY other app, Benski would have his pride hurt ...and prioritize the fix, which is necessary anyway to fix the skipping short file issue.