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