> El 10 jul 2021, a las 15:31, Klaus Scheuermann <kla...@posteo.de> escribió: > > 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.
Nice project! definitely would be great to add LUFS meters and kind of a loudness stabilizer with targets. Best, Juan Carlos >> On 10. Jul 2021, at 14:47, Juan Carlos Blancas <lav...@gmail.com >> <mailto: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 >> <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
