Hello Juan Carlos, > Klaus, I’m using Atom+FaustLive, Max and SC to do the tests, but I get the > same crash as you with faustide/editor. > https://www.dropbox.com/s/blwtwao7j317db0/test.mov?dl=0 > <https://www.dropbox.com/s/blwtwao7j317db0/test.mov?dl=0> cool, thanks!
> Btw the reading are aprox but not the same as Youlean nor Insight2 for > instance… great, that’s promising! > also thinking about how to do the -70 dB gate and most important the > integrated loudness. Yes, I was wondering about that too… Just so you have some context, I don’t want to replicate an lufs meter, but I want to use lufs it in my project master_me, which is meant to stabilise audio during streaming events: https://github.com/trummerschlunk/master_me <https://github.com/trummerschlunk/master_me> For that I would like to be able to adjust the agility of the integrated loudness. Also the gating should be adjustable. Way to go… ;) Cheers, Klaus > On 10. Jul 2021, at 14:47, Juan Carlos Blancas <lav...@gmail.com> wrote: > > Klaus, I’m using Atom+FaustLive, Max and SC to do the tests, but I get the > same crash as you with faustide/editor. > https://www.dropbox.com/s/blwtwao7j317db0/test.mov?dl=0 > > Btw the reading are aprox but not the same as Youlean nor Insight2 for > instance… > also thinking about how to do the -70 dB gate and most important the > integrated loudness. > > Cheers, > Juan Carlos > >> El 10 jul 2021, a las 12:17, Klaus Scheuermann <kla...@posteo.de> escribió: >> >> Thanks, Juan :) >> >> Your code crashes my faustide on firefox and on chromium (both linux). >> Here is the error message: >> >> ASSERT : please report this message and the failing DSP file to Faust >> developers (file: wasm_instructions.hh, line: 918, version: 2.32.16, >> options: -lang wasm-ib -es 1 -single -ftz 0) >> >> When 'realtime compile' is active, the only way to gain control again is >> to delete all cookies and cache from the site. >> >> I'll try Dario's workaround now ;) >> >> Cheers, Klaus >> >> >> On 09.07.21 18:08, Juan Carlos Blancas wrote: >>> Hi Klaus, >>> >>> For me ms_envelope and rms_envelope functions are not working properly. >>> I’ve done some test in my Mac Pro with High Sierra, porting without >>> barograph to Max or Supercollider and I get the strange gate behaviour in >>> low levels. >>> >>> My workaround at the moment is using ba.slidingMeanp instead of >>> ms_envelope, but it’s 2x cpu intense, so I guess Dario solution of 1plp >>> filter would be the best for the mean square stage. >>> >>>>> 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); >>> >>> >>> Cheers, >>> Juan Carlos >>> >>> >>> // Mono Momentary LUFS meter without gate of Julius, using slidingMeanp >>> instead of ms_envelope >>> >>> import("stdfaust.lib"); >>> >>> A48kHz = ( /* 1.0, */ -1.99004745483398, 0.99007225036621); >>> B48kHz = (1.0, -2.0, 1.0); >>> highpass48kHz = fi.iir(B48kHz,A48kHz); >>> highpass = fi.highpass(2, 40); >>> >>> boostDB = 4; >>> boostFreqHz = 1430; >>> highshelf = fi.high_shelf(boostDB, boostFreqHz); >>> kfilter = highshelf : highpass; >>> >>> MAXN = 262144; >>> Tg = 0.4; >>> Lk = kfilter <: _*_ : ba.slidingMeanp(Tg*ma.SR, MAXN) : ba.linear2db : >>> *(0.5); >>> >>> process = _ <: attach(_, Lk : hbargraph("[1]Momentary LUFS",-70,0)); >>> >>> // >>> >>>> El 9 jul 2021, a las 16:55, Klaus Scheuermann <kla...@posteo.de> escribió: >>>> >>>> Ha, so I was really on to something ;) >>>> >>>> Is the bug in the meter or in the envelope? >>>> Would you have a workaround for me to get on with the lufs analyser? >>>> >>>> Thanks, Klaus >>>> >>>> On 08.07.21 19:19, Julius Smith 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 <mailto: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 removethe hbargraphaltogether, 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 <http://dariosanfilippo.com> >>>>> >>>>> >>>>> On Thu, 8 Jul 2021 at 00:39, Julius Smith <julius.sm...@gmail.com >>>>> <mailto: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 <mailto: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 <http://dariosanfilippo.com> >>>>> >>>>> >>>>> On Wed, 7 Jul 2021 at 19:25, Stéphane Letz <l...@grame.fr >>>>> <mailto: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 <mailto: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 <mailto: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 >>>>> <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> >>>>>>> <mailto: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>> >>>>>>>> <mailto: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>>> >>>>>>>>> <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 >>>>> <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>>> >>>>>>>> <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>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>>> <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>>> >>>>>>>>> >>>>> <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 https://lists.sourceforge.net/lists/listinfo/faudiostream-users
