On third thought, I now see how subtraction is not exact (it depends on
what shifts are needed at addition/subtraction time, which can differ).
The idea is to effectively never round, only summation and the
delayed subtraction, so that subtraction after the delay is exact, avoiding
a TIIR requirement.
It should be possible to accomplish this by converting to fixed-point,
etc. I'm back to thinking about the TIIR case...
On Sat, Jul 10, 2021 at 12:02 PM Julius Smith <julius.sm...@gmail.com>
wrote:
> On second thought, I don't see at the moment how anything can go wrong
> with this:
>
> sliding_mean(durSamples) = (+ ~ _) - @(int(durSamples)) : /(durSamples);
>
> Since there is no rounding involved, the cancellation has to be exact. We
> just have to ensure that the implementation does not subtract integrators
> that keep going separately, i.e., there needs to be one summer in the
> implementation (and the delay line of course). This looks ok to me (but
> I'm rushed so apologies if I overlook anything);
>
> float fVec0[131072]; // 2^17
>
> for (int i0 = 0; (i0 < count); i0 = (i0 + 1)) {
> fRec0[0] = (float(input0[i0]) + fRec0[1]);
> fVec0[(IOTA & 131071)] = float(input1[i0]);
> output0[i0] = FAUSTFLOAT((fConst1 * (fRec0[0] - fVec0[((IOTA - iConst0)
> & 131071)])));
> fRec0[1] = fRec0[0];
> IOTA = (IOTA + 1);
> }
>
> On Sat, Jul 10, 2021 at 11:24 AM Julius Smith <julius.sm...@gmail.com>
> wrote:
>
>> The obvious conclusion, of course, is to work out the ping-ponged
>> truncated integrators, for measurements this long. We just need two 0.4s
>> mean calculators that alternate. I'm sure I'll work it out sometime soon
>> if nobody beats me to it. I imagine a square wave, select2, the
>> sliding-mean unit, a state-clearing mechanism, etc. Gotta do it in the
>> cracks of the day, however... it'll be fun!
>>
>> On Sat, Jul 10, 2021 at 11:08 AM Julius Smith <julius.sm...@gmail.com>
>> wrote:
>>
>>> Actually, the pattern we want kicks in at durSamples = 32
>>> (circular-buffer delay line).
>>>
>>> On Sat, Jul 10, 2021 at 10:53 AM Julius Smith <julius.sm...@gmail.com>
>>> wrote:
>>>
>>>> > I'm not sure I understand what you mean by allocating a delay line
>>>> for the sliding mean, but I'll look into it.
>>>>
>>>> Here's an example implementation in Faust. The "small test" allocates
>>>> a length 8 delay line.
>>>> The full test takes too long to compile, but you can see the pattern,
>>>> so it's easy to just write it.
>>>>
>>>> import("stdfaust.lib");
>>>>
>>>> // Small test:
>>>> durSamples = 8;
>>>> DUR_SAMPLES_MAX = durSamples*2;
>>>>
>>>> // What we really need (but takes a LONG time to compile):
>>>> // DUR_SAMPLES_MAX = 2^16;
>>>> // durSamples = int(0.5 + 0.4 * ma.SR);
>>>>
>>>> sliding_mean(durSamples) = _ <:
>>>> par(i,DUR_SAMPLES_MAX,ba.if(i<durSamples,@(i),0)) :> /(durSamples);
>>>>
>>>> process = sliding_mean(durSamples);
>>>>
>>>> On Sat, Jul 10, 2021 at 1:12 AM Dario Sanfilippo <
>>>> sanfilippo.da...@gmail.com> wrote:
>>>>
>>>>> Dear Julius, thanks for putting it nicely. :)
>>>>>
>>>>> I'm not sure I understand what you mean by allocating a delay line for
>>>>> the sliding mean, but I'll look into it.
>>>>>
>>>>> A quick improvement to the slidingMean function could be to put the
>>>>> integrator after the difference. With a sliding window of .4 sec at 48
>>>>> kHz,
>>>>> we should have about 60 dBs of dynamic range when feeding a full-amp
>>>>> constant. It should be even better with close-to-zero-mean signals.
>>>>>
>>>>> import("stdfaust.lib");
>>>>> slidingSum(n) = _ <: _, _@int(max(0,n)) : - : fi.pole(1);
>>>>> slidingMean(n) = slidingSum(n)/rint(n);
>>>>> t=.4;
>>>>> process = ba.if(ba.time < ma.SR * 1, 1.0, .001) <:
>>>>> slidingMean(t*ma.SR) , ba.slidingMean(t*ma.SR) : ba.linear2db ,
>>>>> ba.linear2db;
>>>>>
>>>>> Ciao,
>>>>> Dr Dario Sanfilippo
>>>>> http://dariosanfilippo.com
>>>>>
>>>>>
>>>>> On Sat, 10 Jul 2021 at 00:27, Julius Smith <julius.sm...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Dario,
>>>>>>
>>>>>> Ok, I see what you're after now. (I was considering only the VU
>>>>>> meter display issue up to now.)
>>>>>>
>>>>>> There's only 23 bits of mantissa in 32-bit floating point, and your
>>>>>> test counts up to ~100k, which soaks up about 17 bits, and then you hit
>>>>>> it
>>>>>> with ~1/1024, or 2^(-10), which is then a dynamic range swing of 27 bits.
>>>>>> We can't add numbers separated by 27 bits of dynamic level using a
>>>>>> mantissa
>>>>>> (or integer) smaller than 27 bits. Yes, double precision will fix that
>>>>>> (52-bit mantissas), but even TIIR methods can't solve this problem. When
>>>>>> adding x and y, the wordlength must be on the order of at least
>>>>>> |log2(|x|/|y|)|.
>>>>>>
>>>>>> The situation is not so dire with a noise input, since it should be
>>>>>> zero mean (and if not, a dcblocker will fix it). However, the variance
>>>>>> of
>>>>>> integrated squared white noise does grow linearly, so TIIR methods are
>>>>>> needed for anything long term, and double-precision allows the TIIR
>>>>>> resets
>>>>>> to be much farther separated, and maybe not even needed in a given
>>>>>> application.
>>>>>>
>>>>>> Note, by the way (Hey Klaus!), we can simply allocate a 0.4 second
>>>>>> delay line for the sliding mean and be done with all this
>>>>>> recursive-filter
>>>>>> dynamic range management. It can be a pain, but it also can be managed.
>>>>>> That said, 0.4 seconds at 96 kHz is around 15 bits worth
>>>>>> (log2(0.4*96000)=15.2), so single-precision seems to me like enough for a
>>>>>> simple level meter (e.g., having a 3-digit display), given a TIIR reset
>>>>>> every 0.4 seconds. Since this works out so neatly, I wouldn't be
>>>>>> surprised
>>>>>> if 0.4 seconds was chosen for the gated-measurement duration for that
>>>>>> reason.
>>>>>>
>>>>>> Cheers,
>>>>>> Julius
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 9, 2021 at 1:54 PM Dario Sanfilippo <
>>>>>> sanfilippo.da...@gmail.com> wrote:
>>>>>>
>>>>>>> Thanks, Julius.
>>>>>>>
>>>>>>> So it appears that the issue I was referring to is in that
>>>>>>> architecture too.
>>>>>>>
>>>>>>> To isolate the problem with ba.slidingMean, we can see that we also
>>>>>>> get 0 when transitioning from a constant input of 1 to .001 (see code
>>>>>>> below). Double-precision solves the issue. Perhaps we could advise
>>>>>>> using DP
>>>>>>> for this function and the others involving it.
>>>>>>>
>>>>>>> Ciao,
>>>>>>> Dario
>>>>>>>
>>>>>>> import("stdfaust.lib");
>>>>>>> lp1p(cf, x) = fi.pole(b, x * (1 - b))
>>>>>>> with {
>>>>>>> b = exp(-2 * ma.PI * cf / ma.SR);
>>>>>>> };
>>>>>>> sig = ba.if(ba.time > ma.SR * 2, .001, 1.0);
>>>>>>> t = .4;
>>>>>>> process = sig <: ba.slidingMean(t * ma.SR) , lp1p(1.0 / t) , ba.time;
>>>>>>>
>>>>>>> On Fri, 9 Jul 2021 at 22:40, Julius Smith <julius.sm...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> "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
>
--
"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
