Mark Lanctot;381252 Wrote: > I can't find the relevant bug, but I believe this is a bug that's been > recently fixed. Andy G and Sean Adams were active in this IIRC. The bug that was fixed (in 7.3.1, I believe) is this one: http://bugs.slimdevices.com/show_bug.cgi?id=5119
To briefly summarise: if the replaygain vaue is positive and applying that positive gain would cause clipping, then it should be scaled back to prevent clipping. (A typical example would be classical music which has a low average volume but has a few peaks at or around 0dB). However, the screen shot posted by blkmagik98 appears to show something has gone horribly wrong. The album gain is -5.4dB, and it says it's been adjusted to -18.06dB to prevent clipping. If the replaygain is negative (as in this case), then clipping cannot be introduced, so no adjustment should be made. Assuming the bug fix is applying the expected calculation based on the replaygain tags, then it suggests the file has a REPLAYGAIN_ALBUM_PEAK tag value of 8. That value should always be 1 or less (except in some pathalogical cases with MP3, where it might be a little bit more than 1). You should check the value of this tag with a suitable program (such as MP3Tag, Foobar2000, etc). If it is 8, then whatever program added the replaygain tags has made an error. If it's 1 or less, then the error appears to have been made either during the SqueezeCenter scan or in the clipping prevention calculation that was added in the bug fix. -- cliveb Transporter -> ATC SCM100A ------------------------------------------------------------------------ cliveb's Profile: http://forums.slimdevices.com/member.php?userid=348 View this thread: http://forums.slimdevices.com/showthread.php?t=57543 _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/ripping
