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