I get the zero but not the other:
octave:2> format long
octave:3> faustout(115200,:)
ans =
0 -2.738748490000000e-02 5.555857930000000e-05
On Fri, Jul 9, 2021 at 1:03 PM Dario Sanfilippo <sanfilippo.da...@gmail.com>
wrote:
> Thanks, Julius.
>
> I don't have Octave installed, and I can't see it myself, sorry; if you
> can inspect the generated values, can you also see if at sample #115200
> (48 kHz SR) you get 0 for ms_rec, and, 0.000658808684 for the lowpass?
>
> Yes, I might have done something wrong, but the leaky integrator doesn't
> work well.
>
> Ciao,
> Dario
>
> On Fri, 9 Jul 2021 at 21:49, Julius Smith <julius.sm...@gmail.com> wrote:
>
>> Here is a longer run that shows Dario's latest test more completely. I
>> don't think zi_leaky looks right at the end, but the other two look
>> reasonable to me.
>>
>> Here is the Octave magic for the plot:
>>
>> plot(faustout,'linewidth',2);
>> legend('zi','zi\_leaky','zi\_lp','location','southeast');
>> grid;
>>
>> I had to edit faust2octave to change the process duration, it's
>> hardwired. Length option needed! (Right now no options can take an
>> argument.)
>>
>> Cheers,
>> - Julius
>>
>> On Fri, Jul 9, 2021 at 12:01 PM Julius Smith <julius.sm...@gmail.com>
>> wrote:
>>
>>> Hi Dario,
>>>
>>> I tried your latest test and it looks plausible in faust2octave (see
>>> plot attached).
>>>
>>> TIIR filters present a nice, juicy Faust puzzle :-)
>>> I thought about a TIIR sliding average, but haven't implemented anything
>>> yet.
>>> You basically want to switch between two moving-average filters,
>>> clearing the state of the unused one, and bringing it back to steady state
>>> before switching it back in.
>>> In the case of an.ms_envelope_rect, the switching period can be anything
>>> greater than the rectangular-window length (which is the "warm up time" of
>>> the moving-average filter).
>>>
>>> Cheers,
>>> - Julius
>>>
>>> On Fri, Jul 9, 2021 at 10:49 AM Dario Sanfilippo <
>>> sanfilippo.da...@gmail.com> wrote:
>>>
>>>> Dear Julius, I just pulled and installed Faust 2.33.0.
>>>>
>>>> I'm running the test below on caqt and csvplot and I see the same
>>>> problem: when large inputs are fed in an.ms_envelope_rect, small
>>>> inputs are truncated to zero afterwards.
>>>>
>>>> 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 * ba.if(ba.time > ma.SR * 2, .01, 1.0);
>>>> process = sig <: zi , zi_leaky , zi_lp , ba.time;
>>>>
>>>> I'll look into TIIR filters or have you already implemented those in
>>>> Faust?
>>>>
>>>> Ciao,
>>>> Dr Dario Sanfilippo
>>>> http://dariosanfilippo.com
>>>>
>>>>
>>>> On Thu, 8 Jul 2021 at 19:19, Julius Smith <julius.sm...@gmail.com>
>>>> wrote:
>>>>
>>>>> 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
>>>>>
>>>>
>>>
>>> --
>>> "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
