Hi Dario,
The problem seems to be architecture-dependent. I am on a Mac (latest
non-beta software) using faust2caqt. What are you using?
I do not see the "strange behavior" you describe.
Your test looks good for me in faust2octave, with gain set to 0.01 (-40 dB,
which triggers the display bug on my system). In Octave, faustout(end,:)
shows
-44.744 -44.968 -44.708
which at first glance seems close enough for noise input and slightly
different averaging windows. Changing the signal to a constant 0.01, I get
-39.994 -40.225 -40.000
which is not too bad, but which should probably be sharpened up. The third
value (zi_lp) is right on, of course.
gain = 0.01; // hslider("Gain [unit:dB]",-70,-70,0,0.1) : ba.db2linear;
sig = gain; //sig = no.noise * gain;
On Thu, Jul 8, 2021 at 3:53 AM Dario Sanfilippo <sanfilippo.da...@gmail.com>
wrote:
> Hi, Julius.
>
> I must be missing something, but I couldn't see the behaviour that you
> described, that is, the gating behaviour happening only for the display and
> not for the output.
>
> If a remove the hbargraph altogether, I can still see the strange
> behaviour. Just so we're all on the same page, the strange behaviour we're
> referring to is the fact that, after going back to low input gains, the
> displayed levels are -inf instead of some low, quantifiable ones, right?
>
> Using a leaky integrator makes the calculations rather inaccurate. I'd say
> that, if one needs to use single-precision, averaging with a one-pole
> lowpass would be best:
>
> import("stdfaust.lib");
> zi = an.ms_envelope_rect(Tg);
> slidingSum(n) = fi.pole(.999999) <: _, _@int(max(0,n)) :> -;
> slidingMean(n) = slidingSum(n)/rint(n);
> zi_leaky(x) = slidingMean(Tg*ma.SR, x * x);
> lp1p(cf, x) = fi.pole(b, x * (1 - b))
> with {
> b = exp(-2 * ma.PI * cf / ma.SR);
> };
> zi_lp(x) = lp1p(1 / Tg, x * x);
> Tg = 0.4;
> sig = no.noise * gain;
> gain = hslider("Gain [unit:dB]",-70,-70,0,0.1) : ba.db2linear;
> level = ba.linear2db : *(0.5);
> process = sig <: level(zi) , level(zi_leaky) , level(zi_lp);
>
> Ciao,
> Dr Dario Sanfilippo
> http://dariosanfilippo.com
>
>
> On Thu, 8 Jul 2021 at 00:39, Julius Smith <julius.sm...@gmail.com> wrote:
>
>> > I think that the problem is in an.ms_envelope_rect, particularly the
>> fact that it has a non-leaky integrator. I assume that when large values
>> recirculate in the integrator, the smaller ones, after pushing the gain
>> down, are truncated to 0 due to single-precision. As a matter of fact,
>> compiling the code in double precision looks fine here.
>>
>> I just took a look and see that it's essentially based on + ~ _ : (_
>> - @(rectWindowLenthSamples))
>> This will indeed suffer from a growing roundoff error variance over time
>> (typically linear growth).
>> However, I do not see any noticeable effects of this in my testing thus
>> far.
>> To address this properly, we should be using TIIR filtering principles
>> ("Truncated IIR"), in which two such units pingpong and alternately reset.
>> Alternatively, a small exponential decay can be added: + ~ *(0.999999)
>> ... etc.
>>
>> - Julius
>>
>> On Wed, Jul 7, 2021 at 12:32 PM Dario Sanfilippo <
>> sanfilippo.da...@gmail.com> wrote:
>>
>>> I think that the problem is in an.ms_envelope_rect, particularly the
>>> fact that it has a non-leaky integrator. I assume that when large values
>>> recirculate in the integrator, the smaller ones, after pushing the gain
>>> down, are truncated to 0 due to single-precision. As a matter of fact,
>>> compiling the code in double precision looks fine here.
>>>
>>> Ciao,
>>> Dr Dario Sanfilippo
>>> http://dariosanfilippo.com
>>>
>>>
>>> On Wed, 7 Jul 2021 at 19:25, Stéphane Letz <l...@grame.fr> wrote:
>>>
>>>> « hargraph seems to have some kind of a gate in it that kicks in around
>>>> -35 dB. » humm…. hargraph/vbargrah only keep the last value of their
>>>> written FAUSTFLOAT* zone, so once per block, without any processing of
>>>> course…
>>>>
>>>> Have you looked at the produce C++ code?
>>>>
>>>> Stéphane
>>>>
>>>> > Le 7 juil. 2021 à 18:31, Julius Smith <julius.sm...@gmail.com> a
>>>> écrit :
>>>> >
>>>> > That is strange - hbargraph seems to have some kind of a gate in it
>>>> that kicks in around -35 dB.
>>>> >
>>>> > In this modified version, you can hear that the sound is ok:
>>>> >
>>>> > import("stdfaust.lib");
>>>> > Tg = 0.4;
>>>> > zi = an.ms_envelope_rect(Tg);
>>>> > gain = hslider("Gain [unit:dB]",-10,-70,0,0.1) : ba.db2linear;
>>>> > sig = no.noise * gain;
>>>> > process = attach(sig, (sig : zi : ba.linear2db : *(0.5) :
>>>> hbargraph("test",-70,0)));
>>>> >
>>>> > On Wed, Jul 7, 2021 at 12:59 AM Klaus Scheuermann <kla...@posteo.de>
>>>> wrote:
>>>> > Hi all,
>>>> > I did some testing and
>>>> >
>>>> > an.ms_envelope_rect()
>>>> >
>>>> > seems to show some strange behaviour (at least to me). Here is a video
>>>> > of the test:
>>>> > https://cloud.4ohm.de/s/64caEPBqxXeRMt5
>>>> >
>>>> > The audio is white noise and the testing code is:
>>>> >
>>>> > import("stdfaust.lib");
>>>> > Tg = 0.4;
>>>> > zi = an.ms_envelope_rect(Tg);
>>>> > process = _ : zi : ba.linear2db : hbargraph("test",-95,0);
>>>> >
>>>> > Could you please verify?
>>>> >
>>>> > Thanks, Klaus
>>>> >
>>>> >
>>>> >
>>>> > On 05.07.21 20:16, Julius Smith wrote:
>>>> > > Hmmm, '!' means "block the signal", but attach should save the
>>>> bargraph
>>>> > > from being optimized away as a result. Maybe I misremembered the
>>>> > > argument order to attach? While it's very simple in concept, it
>>>> can be
>>>> > > confusing in practice.
>>>> > >
>>>> > > I chose not to have a gate at all, but you can grab one from
>>>> > > misceffects.lib if you like. Low volume should not give -infinity,
>>>> > > that's a bug, but zero should, and zero should become MIN as I
>>>> mentioned
>>>> > > so -infinity should never happen.
>>>> > >
>>>> > > Cheers,
>>>> > > Julius
>>>> > >
>>>> > >
>>>> > > On Mon, Jul 5, 2021 at 10:39 AM Klaus Scheuermann <kla...@posteo.de
>>>> > > <mailto:kla...@posteo.de>> wrote:
>>>> > >
>>>> > > Cheers Julius,
>>>> > >
>>>> > >
>>>> > >
>>>> > > At least I understood the 'attach' primitive now ;) Thanks.
>>>> > >
>>>> > >
>>>> > >
>>>> > > This does not show any meter here...
>>>> > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>>>> vbargraph("LUFS",-90,0)))
>>>> > > : _,_,!;
>>>> > >
>>>> > > But this does for some reason (although the output is 3-channel
>>>> then):
>>>> > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>>>> vbargraph("LUFS",-90,0)))
>>>> > > : _,_,_;
>>>> > >
>>>> > > What does the '!' do?
>>>> > >
>>>> > >
>>>> > >
>>>> > > I still don't quite get the gating topic. In my understanding,
>>>> the meter
>>>> > > should hold the current value if the input signal drops below a
>>>> > > threshold. In your version, the meter drops to -infinity when
>>>> very low
>>>> > > volume content is played.
>>>> > >
>>>> > > Which part of your code does the gating?
>>>> > >
>>>> > > Many thanks,
>>>> > > Klaus
>>>> > >
>>>> > >
>>>> > >
>>>> > > On 05.07.21 18:06, Julius Smith wrote:
>>>> > > > Hi Klaus,
>>>> > > >
>>>> > > > Yes, I agree the filters are close enough. I bet that the
>>>> shelf is
>>>> > > > exactly correct if we determined the exact transition
>>>> frequency, and
>>>> > > > that the Butterworth highpass is close enough to the
>>>> > > Bessel-or-whatever
>>>> > > > that is inexplicably not specified as a filter type, leaving
>>>> it
>>>> > > > sample-rate dependent. I would bet large odds that the
>>>> differences
>>>> > > > cannot be reliably detected in listening tests.
>>>> > > >
>>>> > > > Yes, I just looked again, and there are "gating blocks"
>>>> defined,
>>>> > > each Tg
>>>> > > > = 0.4 sec long, so that only ungated blocks are averaged to
>>>> form a
>>>> > > > longer term level-estimate. What I wrote gives a "sliding
>>>> gating
>>>> > > > block", which can be lowpass filtered further, and/or gated,
>>>> etc.
>>>> > > > Instead of a gate, I would simply replace 0 by ma.EPSILON so
>>>> that the
>>>> > > > log always works (good for avoiding denormals as well).
>>>> > > >
>>>> > > > I believe stereo is supposed to be handled like this:
>>>> > > >
>>>> > > > Lk2 = _,0,_,0,0 : Lk5;
>>>> > > > process(x,y) = Lk2(x,y);
>>>> > > >
>>>> > > > or
>>>> > > >
>>>> > > > Lk2 = Lk(0),Lk(2) :> 10 * log10 : -(0.691);
>>>> > > >
>>>> > > > but since the center channel is processed identically to left
>>>> > > and right,
>>>> > > > your solution also works.
>>>> > > >
>>>> > > > Bypassing is normal Faust, e.g.,
>>>> > > >
>>>> > > > process(x,y) = x,y <: (_,_), attach(x, (Lk2 :
>>>> > > vbargraph("LUFS",-90,0)))
>>>> > > > : _,_,!;
>>>> > > >
>>>> > > > Cheers,
>>>> > > > Julius
>>>> > > >
>>>> > > >
>>>> > > > On Mon, Jul 5, 2021 at 1:56 AM Klaus Scheuermann <
>>>> kla...@posteo.de
>>>> > > <mailto:kla...@posteo.de>
>>>> > > > <mailto:kla...@posteo.de <mailto:kla...@posteo.de>>> wrote:
>>>> > > >
>>>> > > >
>>>> > > > > I can never resist these things! Faust makes it too
>>>> > > enjoyable :-)
>>>> > > >
>>>> > > > Glad you can't ;)
>>>> > > >
>>>> > > > I understood you approximate the filters with standard
>>>> faust
>>>> > > filters.
>>>> > > > That is probably close enough for me :)
>>>> > > >
>>>> > > > I also get the part with the sliding window envelope. If I
>>>> > > wanted to
>>>> > > > make the meter follow slowlier, I would just widen the
>>>> window
>>>> > > with Tg.
>>>> > > >
>>>> > > > The 'gating' part I don't understand for lack of
>>>> mathematical
>>>> > > knowledge,
>>>> > > > but I suppose it is meant differently. When the input
>>>> signal
>>>> > > falls below
>>>> > > > the gate threshold, the meter should stay at the current
>>>> > > value, not drop
>>>> > > > to -infinity, right? This is so 'silent' parts are not
>>>> taken into
>>>> > > > account.
>>>> > > >
>>>> > > > If I wanted to make a stereo version it would be
>>>> something like
>>>> > > > this, right?
>>>> > > >
>>>> > > > Lk2 = par(i,2, Lk(i)) :> 10 * log10 : -(0.691);
>>>> > > > process = _,_ : Lk2 : vbargraph("LUFS",-90,0);
>>>> > > >
>>>> > > > Probably very easy, but how do I attach this to a stereo
>>>> > > signal (passing
>>>> > > > through the stereo signal)?
>>>> > > >
>>>> > > > Thanks again!
>>>> > > > Klaus
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > >
>>>> > > > > I made a pass, but there is a small scaling error. I
>>>> think
>>>> > > it can be
>>>> > > > > fixed by reducing boostFreqHz until the sine_test is
>>>> nailed.
>>>> > > > > The highpass is close (and not a source of the scale
>>>> error),
>>>> > > but I'm
>>>> > > > > using Butterworth instead of whatever they used.
>>>> > > > > I glossed over the discussion of "gating" in the spec,
>>>> and
>>>> > > may have
>>>> > > > > missed something important there, but
>>>> > > > > I simply tried to make a sliding rectangular window,
>>>> instead
>>>> > > of 75%
>>>> > > > > overlap, etc.
>>>> > > > >
>>>> > > > > If useful, let me know and I'll propose it for
>>>> analyzers.lib!
>>>> > > > >
>>>> > > > > Cheers,
>>>> > > > > Julius
>>>> > > > >
>>>> > > > > import("stdfaust.lib");
>>>> > > > >
>>>> > > > > // Highpass:
>>>> > > > > // At 48 kHz, this is the right highpass filter (maybe a
>>>> > > Bessel or
>>>> > > > > Thiran filter?):
>>>> > > > > A48kHz = ( /* 1.0, */ -1.99004745483398,
>>>> 0.99007225036621);
>>>> > > > > B48kHz = (1.0, -2.0, 1.0);
>>>> > > > > highpass48kHz = fi.iir(B48kHz,A48kHz);
>>>> > > > > highpass = fi.highpass(2, 40); // Butterworth highpass:
>>>> > > roll-off is a
>>>> > > > > little too sharp
>>>> > > > >
>>>> > > > > // High Shelf:
>>>> > > > > boostDB = 4;
>>>> > > > > boostFreqHz = 1430; // a little too high - they should
>>>> give
>>>> > > us this!
>>>> > > > > highshelf = fi.high_shelf(boostDB, boostFreqHz); //
>>>> Looks
>>>> > > very close,
>>>> > > > > but 1 kHz gain has to be nailed
>>>> > > > >
>>>> > > > > kfilter = highshelf : highpass;
>>>> > > > >
>>>> > > > > // Power sum:
>>>> > > > > Tg = 0.4; // spec calls for 75% overlap of successive
>>>> > > rectangular
>>>> > > > > windows - we're overlapping MUCH more (sliding window)
>>>> > > > > zi = an.ms_envelope_rect(Tg); // mean square: average
>>>> power =
>>>> > > > energy/Tg
>>>> > > > > = integral of squared signal / Tg
>>>> > > > >
>>>> > > > > // Gain vector Gv = (GL,GR,GC,GLs,GRs):
>>>> > > > > N = 5;
>>>> > > > > Gv = (1, 1, 1, 1.41, 1.41); // left GL(-30deg), right GR
>>>> > > (30), center
>>>> > > > > GC(0), left surround GLs(-110), right surr. GRs(110)
>>>> > > > > G(i) = *(ba.take(i+1,Gv));
>>>> > > > > Lk(i) = kfilter : zi : G(i); // one channel, before
>>>> summing
>>>> > > and before
>>>> > > > > taking dB and offsetting
>>>> > > > > LkDB(i) = Lk(i) : 10 * log10 : -(0.691); // Use this
>>>> for a mono
>>>> > > > input signal
>>>> > > > >
>>>> > > > > // Five-channel surround input:
>>>> > > > > Lk5 = par(i,5,Lk(i)) :> 10 * log10 : -(0.691);
>>>> > > > >
>>>> > > > > // sine_test = os.oscrs(1000); // should give –3.01
>>>> LKFS, with
>>>> > > > > GL=GR=GC=1 (0dB) and GLs=GRs=1.41 (~1.5 dB)
>>>> > > > > sine_test = os.osc(1000);
>>>> > > > >
>>>> > > > > process = sine_test : LkDB(0); // should read -3.01
>>>> LKFS -
>>>> > > high-shelf
>>>> > > > > gain at 1 kHz is critical
>>>> > > > > // process = 0,sine_test,0,0,0 : Lk5; // should read
>>>> -3.01
>>>> > > LKFS for
>>>> > > > > left, center, and right
>>>> > > > > // Highpass test: process = 1-1' <: highpass,
>>>> highpass48kHz;
>>>> > > // fft in
>>>> > > > > Octave
>>>> > > > > // High shelf test: process = 1-1' : highshelf; // fft
>>>> in Octave
>>>> > > > >
>>>> > > > > On Sat, Jul 3, 2021 at 1:08 AM Klaus Scheuermann
>>>> > > <kla...@posteo.de <mailto:kla...@posteo.de>
>>>> > > > <mailto:kla...@posteo.de <mailto:kla...@posteo.de>>
>>>> > > > > <mailto:kla...@posteo.de <mailto:kla...@posteo.de>
>>>> > > <mailto:kla...@posteo.de <mailto:kla...@posteo.de>>>> wrote:
>>>> > > > >
>>>> > > > > Hello everyone :)
>>>> > > > >
>>>> > > > > Would someone be up for helping me implement an LUFS
>>>> > > loudness
>>>> > > > analyser
>>>> > > > > in faust?
>>>> > > > >
>>>> > > > > Or has someone done it already?
>>>> > > > >
>>>> > > > > LUFS (aka LKFS) is becoming more and more the
>>>> standard for
>>>> > > > loudness
>>>> > > > > measurement in the audio industry. Youtube, Spotify
>>>> and
>>>> > > broadcast
>>>> > > > > stations use the concept to normalize loudness. A
>>>> very
>>>> > > > positive side
>>>> > > > > effect is, that loudness-wars are basically over.
>>>> > > > >
>>>> > > > > I looked into it, but my programming skills clearly
>>>> > > don't match
>>>> > > > > the level for implementing this.
>>>> > > > >
>>>> > > > > Here is some resource about the topic:
>>>> > > > >
>>>> > > > > https://en.wikipedia.org/wiki/LKFS
>>>> > > <https://en.wikipedia.org/wiki/LKFS>
>>>> > > > <https://en.wikipedia.org/wiki/LKFS
>>>> > > <https://en.wikipedia.org/wiki/LKFS>>
>>>> > > > <https://en.wikipedia.org/wiki/LKFS
>>>> > > <https://en.wikipedia.org/wiki/LKFS>
>>>> > > > <https://en.wikipedia.org/wiki/LKFS
>>>> > > <https://en.wikipedia.org/wiki/LKFS>>>
>>>> > > > >
>>>> > > > > Specifications (in Annex 1):
>>>> > > > >
>>>> > > >
>>>> > >
>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>>>> > > <
>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>>>> >
>>>> > > >
>>>> > > <
>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>>>> > > <
>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>>>> >>
>>>> > > > >
>>>> > > >
>>>> > > <
>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>>>> > > <
>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>>>> >
>>>> > > >
>>>> > > <
>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>>>> > > <
>>>> https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-3-201208-S!!PDF-E.pdf
>>>> >>>
>>>> > > > >
>>>> > > > > An implementation by 'klangfreund' in JUCE / C:
>>>> > > > > https://github.com/klangfreund/LUFSMeter
>>>> > > <https://github.com/klangfreund/LUFSMeter>
>>>> > > > <https://github.com/klangfreund/LUFSMeter
>>>> > > <https://github.com/klangfreund/LUFSMeter>>
>>>> > > > > <https://github.com/klangfreund/LUFSMeter
>>>> > > <https://github.com/klangfreund/LUFSMeter>
>>>> > > > <https://github.com/klangfreund/LUFSMeter
>>>> > > <https://github.com/klangfreund/LUFSMeter>>>
>>>> > > > >
>>>> > > > > There is also a free LUFS Meter in JS / Reaper by
>>>> > > Geraint Luff.
>>>> > > > > (The code can be seen in reaper, but I don't know
>>>> if I
>>>> > > should
>>>> > > > paste it
>>>> > > > > here.)
>>>> > > > >
>>>> > > > > Please let me know if you are up for it!
>>>> > > > >
>>>> > > > > Take care,
>>>> > > > > Klaus
>>>> > > > >
>>>> > > > >
>>>> > > > > _______________________________________________
>>>> > > > > Faudiostream-users mailing list
>>>> > > > > Faudiostream-users@lists.sourceforge.net
>>>> > > <mailto:Faudiostream-users@lists.sourceforge.net>
>>>> > > > <mailto:Faudiostream-users@lists.sourceforge.net
>>>> > > <mailto:Faudiostream-users@lists.sourceforge.net>>
>>>> > > > > <mailto:Faudiostream-users@lists.sourceforge.net
>>>> > > <mailto:Faudiostream-users@lists.sourceforge.net>
>>>> > > > <mailto:Faudiostream-users@lists.sourceforge.net
>>>> > > <mailto:Faudiostream-users@lists.sourceforge.net>>>
>>>> > > > >
>>>> > > >
>>>> > >
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>> > > <
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
>>>> > > >
>>>> > > <
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>> > > <
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users>>
>>>> > > > >
>>>> > > >
>>>> > > <
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>> > > <
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users>
>>>> > > >
>>>> > > <
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>> > > <
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users>>>
>>>> > > > >
>>>> > > > >
>>>> > > > >
>>>> > > > > --
>>>> > > > > "Anybody who knows all about nothing knows everything"
>>>> --
>>>> > > Leonard
>>>> > > > Susskind
>>>> > > >
>>>> > > >
>>>> > > >
>>>> > > > --
>>>> > > > "Anybody who knows all about nothing knows everything" --
>>>> Leonard
>>>> > > Susskind
>>>> > >
>>>> > >
>>>> > >
>>>> > > --
>>>> > > "Anybody who knows all about nothing knows everything" -- Leonard
>>>> Susskind
>>>> >
>>>> >
>>>> > --
>>>> > "Anybody who knows all about nothing knows everything" -- Leonard
>>>> Susskind
>>>> > _______________________________________________
>>>> > Faudiostream-users mailing list
>>>> > Faudiostream-users@lists.sourceforge.net
>>>> > https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Faudiostream-users mailing list
>>>> Faudiostream-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/faudiostream-users
>>>>
>>>
>>
>> --
>> "Anybody who knows all about nothing knows everything" -- Leonard Susskind
>>
>
--
"Anybody who knows all about nothing knows everything" -- Leonard Susskind
_______________________________________________
Faudiostream-users mailing list
Faudiostream-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/faudiostream-users
