jeffmeh;370621 Wrote: > I'm not really clear on the problem with the attenuation via the > player's digital volume control. I would expect this to be additional > attenuation, after replaygain is applied. Is that not how it works > today? The simplest way to explain is probably with an example. Suppose you have a file that peaks at -3dB and has a replaygain value of +6dB. This would clip if the RG value is blindly applied (as at present). So the simple solution is back off the RG to +3dB. And this could easily be done at the server end.
But suppose the player's digital volume control is set to -4dB. That would put the file's peak at -7dB. So there is now enough headroom to apply the full +6dB of replaygain. If the player's volume was set to -2dB, there's room to apply +5dB of the RG. I hope you get the picture. So, you may ask, why can't *this* calculation be done at the server end? I don't know for sure, but I believe it can't because although the server knows what volume setting the player has in terms of the 1-100 scale, I don't think the server knows how that setting maps to a specific dB attenuation. We know that the characteristics of the volume control varies between different firmware releases (and possibly between different player models). The question is: does SqueezeCenter have a way of discovering the dB attenuation for attached players? If it can, then what I previously described as the "gold standard" implementation for replaygain can be done entirely inside SqueezeCenter. If not, then it would need firmware modifications. -- 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=30316 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/discuss
