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