11 Jun
2012
11 Jun
'12
5:47 p.m.
Hi there,
Does anyone have Steve Harris' new email address? steve(a)plugin.org.uk
fails with "550 5.1.2 Bad destination system address".
Anyway, some of you who package or copied code from meterbridge may be
interested in this as well.
-=-=-=-=-
Hi Steve,
Haven't seen you around much on LAD. I hope this email finds you well.
Are you still maintaining meterbridge? I've stumbled over a bug in 0.9.2
The IEC scale is not continuous. Attached patch resolves the issue.
I don't have access to the IEC-268-18 specs, so I can't tell if the
patch is correct, but it does fix the discontinuity between -60db and
-50db. To make it obvious, here's the annotated iec_scale(float db):
if (db < -70.0f) {
def = 0.0f;
} else if (db < -60.0f) {
def = (db + 70.0f) * 0.25f; // 0.0 .. 2.5
} else if (db < -50.0f) {
// 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!
} else if (db < -40.0f) {
def = (db + 50.0f) * 0.75f + 7.5; // 7.5 .. 15.0
} else if (db < -30.0f) {
def = (db + 40.0f) * 1.5f + 15.0f; // 15.0 .. 30.0
} else if (db < -20.0f) {
def = (db + 30.0f) * 2.0f + 30.0f; // 30.0 .. 50.0
} else if (db < 0.0f) {
def = (db + 20.0f) * 2.5f + 50.0f; // 50.0 .. 100.0
} else {
def = 100.0f;
}
Furthermore, the DPM image has a couple of problems:
The markers at -10, -19, -20, -25, -30, -35, -55 are off by one pixel
(they need to be moved 1px down), the -45db marker is correct.
The marks for -40, and -50 are missing and it's easy to mistake the
-45db and -55db marks to correspond to the -40db, -50db annotations.
Last but not least, the minus-signs of all annotation does not align
with the marks and the font used for the annotation text is somewhat
blurry..
All fixed in attached image.
Cheers!
robin
26 Sep
26 Sep
11:08 a.m.
[This went rather in one ear and out the other when you posted it (if
that's possible for email) but I did eventually realise I'd seen it.]
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.
Thanks for spotting this.
Chris
3:39 p.m.
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:
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)
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. 
5:23 p.m.
On Wednesday 26 September 2012 12:58:35 Fons Adriaensen did opine:
On Wed, Sep 26, 2012 at 12:08:00PM +0100, Chris Cannam
wrote:
You are very correct, Fons. However, as a BC engineer, I have observed
severe clipping of the waveforms because they exceeded the headroom of the
DA's, which in this case was _+28 dbm, while the true vu meter sitting on
that same line was reading -3dbm peaks. For average loudness readings the
legal and pricey vu meter is fairly accurate, but it fails to detect the
transients in todays music, or even in tv's spoken dialog during a soap,
where the human ear as assaulted by the clipping cracklies the 70 year old
analog std meter simply doesn't detect. To that end, the best production
audio boards are also equipt with the much faster LED setups that latch
such a peak condition excursion for at least 100 milliseconds to make it
obvious a peak has been exceeded.
To that end, the operators under my control have always been instructed to
take it down a snudge until the overload LED at +16dbm only blinks at 5
second or more intervals. Listener fatigue can be very apparent in much of
todays audio streams when the old 'vu' meter is peaking at _+4.
And it shows in the ratings books when those instructions are being
ignored, folks might be fans of the program but something they only 'feel'
makes them channel hop looking for a more pleasant experience. When 1
point in the ratings is as important as it is to a facilities cash flow, we
look for every conceivable advantage. Bad audio hurts.
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Gary Hart: living proof that you *can* screw your brains out.
On 11 June 2012 18:47, Robin Gareus
<robin(a)gareus.org> wrote:
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, 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.
7:28 p.m.
On Wed, Sep 26, 2012 at 01:23:48PM -0400, Gene Heskett wrote:
On Wednesday 26 September 2012 12:58:35 Fons
Adriaensen did opine:
All very true. But that's no reason to claim that something that
just looks a bit like a VU meter but behaves *very* differently
actually is a VU meter. Same for the PPMs.
The code to this correctly has been available and GPL licensed for
4 or 5 years now (jmeters), so there's no excuse.
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)
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,
You are very correct, Fons. However, as a BC engineer, I have observed
severe clipping of the waveforms because they exceeded the headroom of the
DA's, which in this case was _+28 dbm, while the true vu meter sitting on
that same line was reading -3dbm peaks. For average loudness readings the
legal and pricey vu meter is fairly accurate, but it fails to detect the
transients in todays music, or even in tv's spoken dialog during a soap,
where the human ear as assaulted by the clipping cracklies the 70 year old
analog std meter simply doesn't detect. To that end, the best production
audio boards are also equipt with the much faster LED setups that latch
such a peak condition excursion for at least 100 milliseconds to make it
obvious a peak has been exceeded.
To that end, the operators under my control have always been instructed to
take it down a snudge until the overload LED at +16dbm only blinks at 5
second or more intervals. Listener fatigue can be very apparent in much of
todays audio streams when the old 'vu' meter is peaking at _+4.
And it shows in the ratings books when those instructions are being
ignored, folks might be fans of the program but something they only 'feel'
makes them channel hop looking for a more pleasant experience. When 1
point in the ratings is as important as it is to a facilities cash flow, we
look for every conceivable advantage. Bad audio hurts.
27 Sep
27 Sep
3:57 a.m.
On Wednesday 26 September 2012 23:48:57 Fons Adriaensen did opine:
[...]
All very true. But that's no reason to claim that
something that
just looks a bit like a VU meter but behaves *very* differently
actually is a VU meter. Same for the PPMs.
No argument here. Most are better than nothing, but still lie like a rug
under dynamic conditions.
The code to this correctly has been available and GPL
licensed for
4 or 5 years now (jmeters), so there's no excuse.
I wasn't aware of that bit of code, thanks Fons.
Now that I've been retired for over a decade, lots of that stuff goes right
on by I'm sorry to say. What does it use for its A/D converter? Not all
audio cards have sufficient depth to pull that off w/o the converter
showing what a POC it is if the input level is off 3 to 6 db from ideal.
My audigy2 value I would call just usable with its 24 bit range.
Ciao,
Cheers, Gene
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Now I lay me down to sleep
I hear the sirens in the street
All my dreams are made of chrome
I have no way to get back home
-- Tom Waits
26 Sep
26 Sep
8:13 p.m.
On 26 September 2012 16:39, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
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.
I'm not sure whether you're addressing me, but I have nothing to do
with meterbridge. My interest was limited to the IEC 268-18 extension
curve. Which I apparently should have done due diligence on.
Not sure whether Steve would be applying patches? If he isn't placed
to update it, it might be a better idea to tell people to use
something else (jmeters? with a link?) than to spend too much time on
specific issues with meterbridge. Especially if they've been described
before and if there is no way to get a fix through to anyone who picks
up the program from the obvious location or through a search.
Chris
4321
days inactive
4429
days old
linux-audio-dev@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Chris Cannam -
Fons Adriaensen -
Gene Heskett -
Robin Gareus