https://www.tortall.net/mu/blog/2007/04/07/rereplaygainComments on ReReplayGain2007-04-07T20:15:44ZMichael Urmanhttps://www.tortall.net/muRe: ReReplayGainJoe Wreschnighttps://www.tortall.net/mu/blog/2007/04/07/rereplaygain#comment-32007-04-26T01:01:06Z
I finally got around to actually using this today. The best part is that it's about twice as fast as mp3gain was.
Maybe they're clamping signed ints rather than unsigned ones?
]]>Re: ReReplayGainMichael Urmanhttps://www.tortall.net/mu/blog/2007/04/07/rereplaygain#comment-22007-04-08T16:11:52Z
Looking at code that implements it, generally 16bit values that are scaled by 1/32768. Thus I expect 2.0 to be the cap, but something doesn't add up. (This would be as you describe, but with a 2x multiplier for reasons I cannot explain.)
]]>Re: ReReplayGainTobiashttps://www.tortall.net/mu/blog/2007/04/07/rereplaygain#comment-12007-04-08T11:40:11Z
Awesome, simply awesome. One less reason to resort to external tools (which often don't take tags into account).
I didn't understand why the peak should reach 2.0. Isn't the peak the maximum sample value in the file, for a possible range 0-1.0?
]]>Re: ReReplayGainMichael Urmanhttps://www.tortall.net/mu/blog/2007/04/07/rereplaygain#comment-02007-04-08T07:50:29Zcymacs on #gstreamer, who has been helping me all along, assures me that the 1.0 cap is related to the integer decoding used by GStreamer. Since this feeds clamped values to the analysis, the maximum the result can be is 1.0.
]]>