"Calculate Replay Gain" bug since 5.62

[rhododendron]

Since Winamp version 5.62 "Calculate Replay Gain" only works on some files of an album.
The other files show up as "+0.00dB" and "0.000000000" in the result window.
These files did work in previous versions of Winamp (e.g. 5.61).

[lostinsound]

I can confirm this on Windows 7. Although it looks like it's only happening with variable bitrate mp3s (not all VBR's just some of them). It's worked fine for all the flacs and constant bitrate mp3s I've tried. Those are the only file types I've tested it on.

[MrSinatra]

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

and

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

[DJ Egg]

Hmm, strange.
Nothing changed in the MP3/RG code between 5.61 to 5.62 and I can't reproduce the problem...
http://meggamusic.co.uk/shup/1310082...namp562_rg.jpg

[MrSinatra]

did u try on VBR?

like i said, i noticed this earlier, but got it to work, UNTIL this 6min+ VBR. RG calculates, but won't write the tags or even update the ML.

[MrSinatra]

interesting, i put this file in mp3val, and it "fixed" it, apparently a xing header issue, and now RG works (its in tags and ML).

but this was not an issue in earlier winamps, when i had broken headers in those files.

(so i wonder why the header matters to the RG tag calculation/writing, but i would run such files thru mp3val, and if that doesn't fix them, moonbases ver of vbrfix)

[DJ Egg]

Originally Posted by MrSinatra

did u try on VBR?

Yes, the files in my screenshot are vbr (bitrate is shown in playlist/ATF)

We would need a sample file to reproduce the problem.
We will then test it with 5.61 and 5.62 to see if there's any difference.

Broken headers would certainly cause a problem...
What rubbishy encoder/editor/program are you using which is breaking the headers in the first place?

[MrSinatra]

Originally Posted by DJ Egg

We would need a sample file to reproduce the problem.
We will then test it with 5.61 and 5.62 to see if there's any difference.

unfortunately, i fixed mine.

however, like i said elsewhere, i saw this on other files, where what i had to do was stop it playing to get it to apply RG. i did NOT "fix" those ones at any point, nor do i even know or think they're broken to begin with.

did you try applying RG on a currently "playing" file, as well as stopped ones?

Originally Posted by DJ Egg

Broken headers would certainly cause a problem...
What rubbishy encoder/editor/program are you using which is breaking the headers in the first place?

i never saw this problem prior to 5.62, pretty sure it didn't used to do it, in any circumstances, ie. playing or stopped, broken header or not.

as to the progam, p2p. frostwire in this case.

[DJ Egg]

Yes, I can apply RG to a vbr mp3 album whilst one of the tracks is playing.
However, none of my files have got broken headers....

Someone will need to provide a sample file for us to be able to reproduce the problem.

[MrSinatra]

i spoke too soon! i have a backup of the file made by mp3val that i restored from sending to recycle bin, so that should be pre "fixed" state.

only problem is, "stashbox" is dead. how can i get this file to you?

[lostinsound]

I've run replay gain on quite a few of my vbr albums (many of them I encoded using winamp) and almost every one of them has at least one file that has this problem. On average it's probably been 3-4 songs per album, and it happens whether or not I'm playing the track I'm analyzing. Running them through mp3val didn't show any errors and didn't fix the problem. And I can verify that it happens even on a clean install. I also checked that it's working fine with 5.61. I'm willing to supply a sample file but I'm not sure how to go about doing that.

[DJ Egg]

Originally Posted by MrSinatra

only problem is, "stashbox" is dead. how can i get this file to you?

Use any of:
www.dropbox.com
www.sendspace.com
www.mediafire.com

[MrSinatra]

duh! i had mediafire before...

egg,

this is the one that wouldn't work at all:

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

however, i did have some others that wouldn't work while playing, but did afterwards. i don't know if they were vbr or not, or bad headers or not. i will try to find an example of one of those types as well, i just don't have one currently.

thx!

[rhododendron]

As lostinsound said,
the problem is with some tracks of an album.
In my case the album is freshly ripped with EAC and encoded with Lame with VBR between 128 and 320 kBit.
I think the problem may not have something to do with the tags, because the result window with the properly caculated RGs and the improperly calculated RGs (+0.00dB) together appears before anything is written to the files (you can press "cancel" in this window).

[rhododendron]

Originally Posted by DJ Egg

Hmm, strange.
Nothing changed in the MP3/RG code between 5.61 to 5.62 and I can't reproduce the problem...
http://meggamusic.co.uk/shup/1310082...namp562_rg.jpg

If I try to put the ml_rg.dll of Winamp 5.61 into the plugin folder of Winamp 5.62, Winamp 5.62 exits silently, when trying to calculate RG.
It seems that something in the ml_rg.dll did change.

[rhododendron]

Do you need a sample of my tracks, too?
If yes, may I mail it? (because of copyright issues)

[MrSinatra]

just put it on mediafire long enough for egg to grab it, then u can take it down.

what happens when you put ml_rg.dll from 5.62 in 5.61?

did u test your files with mp3val?

[rhododendron]

I will test the album with mp3val at home later.
The file I can test here, is ok, according to mp3val.
Winamp 5.61 with mp_rg.dll 5.61 => is working, result -5.01 dB, peak 0.997659206
Winamp 5.61 with mp_rg.dll 5.62 => is working, result -5.01 dB, peak 0.997659206
Winamp 5.62 with mp_rg.dll 5.61 => crash, access violation, see attached screenshots
Winamp 5.62 with mp_rg.dll 5.62 => no crash, but result +0.00 dB, peak 0.000000000

[MrSinatra]

good work, and interesting results...

what happens when u try my mediafire file with 5.61?

but what language are you in though? fyi: best to troubleshoot in english, since thats the default.

[rhododendron]

Winamp is running in English (as always on my boxes).
The Visual Studio debugger is running in English, too.
My Windows XP is running in German.

[rhododendron]

The results of your mediafire file:
Winamp 5.61 and ml_rg.dll 5.61 => -7.61 dB, peak 1.775264502
Winamp 5.62 and ml_rg.dll 5.62 => +0.00 dB, peak 0.000000000

[DJ Egg]

Ok, let us know if this fixes it.

(With Winamp closed, unzip ml_rg.dll to the %ProgramFiles%\Winamp\Plugins folder)

_________________________________

[MrSinatra]

yes, that fixed the one example file of mine [at mediafire] i've identified so far...

but come on egg, what was the issue? SOMETHING is to blame here... (we just want to know what/how/why)

[DJ Egg]

It's a secret

Thanks for confirming the fix :-)




Ok, it was just some extra error checking that we'd added, but it was too "sensitive"....

[rhododendron]

Your hotfix is working with my files, too.
Thank you!

[MrSinatra]

Originally Posted by DJ Egg

Hmm, strange.
Nothing changed in the MP3/RG code between 5.61 to 5.62

so this was incorrect then?

thats not to be snarky, i very much appreciate the quick fix! but just fyi, mis-statements like that can cause heartburn in troubleshooters like me, when we are trying to get to the bottom of these bugs.

can you expound on error checking? i'm just curious as to how it all works.

[lostinsound]

Looks like it's working for me too. Thanks for the fix. It's interesting that it was an error checking problem because I found one song where if I encoded it in winamp with the VBR Q value set to 0 or 1 it worked but if I set it to anything worse than 2 I would get the error. But I didn't get a chance to post about it before the fix. Makes sense I guess. Thanks again!

[Benski]

It was a bug in ml_rg. I found some bugs with error checking in the replaygain code that was causing a freeze-up when testing some random stuff with the new AAC decoder. Unfortunately, it uncovered another quirk - some mp3's will throw an error at the end of decoding, particularly stream-ripped songs but also some songs with APEv2 tags or sometimes randomly with just an ID3v1 tag at the end. This is because mp3's don't have a well-defined size. The bug with trying to decode end-of-file metadata as mp3 data will be fixed in 5.63 (and never really effected much anyway except showing the red light on track change in classic skin, and it's been a bug since the 2.x days . 5.621 will just have the ml_rg fix.

[MrSinatra]

thats what i was looking for! big thx to you and egg, winamp just keeps getting better!

looking forward to 5.63!

one suggestion: can you incorporate into winamp a diagnostic function for identifying files with "bad" tags, (like mp3tag does), and "bad" headers (like mp3val does) and better yet, include the ability to fix both situations when identified?