On Wed, Sep 26, 2012 at 12:08:00PM +0100, Chris Cannam wrote:
On 11 June 2012 18:47, Robin Gareus
<robin(a)gareus.org> wrote:
Anyway, some of you who package or copied code
from meterbridge may be
interested in this as well.
[...]
// def = (db + 60.0f) * 0.5f + 5.0f; // 5.0 .. 10.0 // bug? v0.9.2
def = (db + 60.0f) * 0.5f + 2.5f; // 2.5 .. 7.5 // fix!
You're quite right -- I just double-checked the standard and your fix
is the right one. I have cargo-culted this code into a couple of other
places myself without ever seeing this mistake, so I'll have to fix
those.
There is more to fix.
The meterbridge website still claims that those meters 'almost' conform
to some standards while in fact they even don't come close.
According to the standard, a VU measures the average of the absolute
value. For a steady input signal around 1 kHz, it must rise to 99% of
the real value in 300ms and overshoot it by 1 to 1.5% before falling
back to 100%. The one from meterbridge measures RMS and rises to the
final value in around 5.3ms, that is more than 50 times too fast (at
a sample rate of 48 kHz, and worse for higher sample rates).
According to the standards, a PPM or IEC meter must have a controlled
rise time of 5 or 10ms (depending on the standard). The one from
meterbridge indicates peak sample values instead.
Ciao,
--
FA
A world of exhaustive, reliable metadata would be an utopia.
It's also a pipe-dream, founded on self-delusion, nerd hubris
and hysterically inflated market opportunities. (Cory Doctorow)