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
