Bugzilla – Bug 4456
Improved VU Meter scale calculation for replaygained tracks
Last modified: 2010-05-07 10:20:09 UTC
Not sure if this is SlimServer or firmware, or both. Please feel free to reclassify. I know that somewhere along the line, a change was committed so that the VU Meters used pre-gain values, and that this resulted in more "lively" visualizations for most people. However, I have a lot of music where the VU Meters hardly move at all, yet they sound just as loud as music where the VU meter needle is buried as far right as it can go (because replaygain makes them just as loud). To me, it makes it look like the VU meter visualization is broken. So I have two alternate proposals, which could be easy or hard depending on where the VU meter values are generated (SlimServer or device firmware, I don't know!). ALTERNATE PROPOSAL 1: Have a checkbox in SlimServer that enables VU meters to use post-replaygain values if checked. ALTERNATE PROPOSAL 2: Always use post-replaygain values, but have a value range you can set in SlimServer which "exaggerates" the VU meter values to make them more lively.
Even better, no new user option needed! Here's the symbolic logic: if(track is being played back with replaygain applied) { minimum_value=0dB; maximum_value=89dB; // or so...maybe make this higher so that the VU meters don't go into the red until you're past 85dB? generate_visualizer(minimum_value,maximum_value,actual_value); } else { use_current_visualizer_code(actual_value); } The idea being that nearly all replaygained tracks use a reference level of 89dB, so that should be a uniform "high point" on the scale.
Changed summary to reflect new possible solution
Yep firmware. It's starting to get a bit squeezy but Richard's still cramming in a few more things.
All new Squeezebox products are likely to be based on the SqueezePlay platform. We do not plan to implement any further enhancements to the ip3k firmware or which are targeted specifically at ip3k-based products.