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 >
_______________________________________________ Faudiostream-users mailing list Faudiostream-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/faudiostream-users