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