Csound Csound-dev Csound-tekno Search About

[Csnd] advance amplitude metering for masterign

Date2013-10-24 17:35
FromMachina
Subject[Csnd] advance amplitude metering for masterign
AttachmentsNone  None  

Date2013-10-25 09:34
FromMachina
SubjectRe: [Csnd] advance amplitude metering for masterign
AttachmentsNone  None  

Date2013-10-25 10:05
FromVictor Lazzarini
SubjectRe: [Csnd] advance amplitude metering for masterign
In Csound 6, use setksmps in an instrument or UDO to set the ksmps size. In Csound 5, it only works on UDOs.

http://www.csounds.com/manual/html/setksmps.html


Victor
On 25 Oct 2013, at 09:34, Machina wrote:

> if this is spanish to you guys, maybe you can help me understand how do i change the k-rate for specific section in an instrument (could be independent instrument, but runs parallel to other insturments) without changing the other instruments k-rate… (for my RMS psudo LUFS thing)
> On Thursday, October 24, 2013 at 7:35 PM, Machina wrote:
> 
>> Hi guys
>> 
>> i was wondering if anybody knows about advance metering systems in csound. i.e. LUFS, LKFS, RA, etc…
>> and if not, if i would want to implement some unweighted loudness unit using rms, how can i know how many samples are being processed? how can i know what kind of averaging takes place (because of the ihp thing, which i dont fully understand)? in other words, if i would like to average out (rms) 0.5 seconds of audio, without smoothing, filtering and such, how is best to perform this?
>> 
>> thank ye for ye time
> 

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie





Date2013-10-25 12:33
FromJustin Smith
SubjectRe: [Csnd] advance amplitude metering for masterign
To know the number of samples processed at a time by rms, you could start with:

halftime = 1/ihp * sr

since that is only the half power point, you would probably want to calculate the number of samples for a given ihp before you finally reach a full elimination of the input - this would be exactly as many iterations of the above as the number of bits of signal you care about - at the most extreme (high end) that would be the bit depth of your output:

halftime*bitdepth

16 * sr / ihp ; for CD quality output


On Fri, Oct 25, 2013 at 2:05 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
In Csound 6, use setksmps in an instrument or UDO to set the ksmps size. In Csound 5, it only works on UDOs.

http://www.csounds.com/manual/html/setksmps.html


Victor
On 25 Oct 2013, at 09:34, Machina wrote:

> if this is spanish to you guys, maybe you can help me understand how do i change the k-rate for specific section in an instrument (could be independent instrument, but runs parallel to other insturments) without changing the other instruments k-rate… (for my RMS psudo LUFS thing)
> On Thursday, October 24, 2013 at 7:35 PM, Machina wrote:
>
>> Hi guys
>>
>> i was wondering if anybody knows about advance metering systems in csound. i.e. LUFS, LKFS, RA, etc…
>> and if not, if i would want to implement some unweighted loudness unit using rms, how can i know how many samples are being processed? how can i know what kind of averaging takes place (because of the ihp thing, which i dont fully understand)? in other words, if i would like to average out (rms) 0.5 seconds of audio, without smoothing, filtering and such, how is best to perform this?
>>
>> thank ye for ye time
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie





Send bugs reports to the Sourceforge bug trackers
csound6:
            https://sourceforge.net/p/csound/tickets/
csound5:
            https://sourceforge.net/p/csound/bugs/
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




Date2013-10-25 15:41
Fromzohar argaman
SubjectRe: [Csnd] advance amplitude metering for masterign
AttachmentsNone  None  

Date2013-10-25 17:07
FromJustin Smith
SubjectRe: [Csnd] advance amplitude metering for masterign
I am under the impression that the window of time for which a sample affects the RMS value that is reported is directly correlated to the ihp value. I could be wrong about this.

My math was assuming that the low pass was a simple recursive lowpass, such that you could calculate the analysis window based on the reciprocal of the ihp frequency. On further consideration that assumption could be totally off base, and one would be better off looking at the source.

I don't think changing the kr should change the window size of the RMS analysis (in fact if it did I would consider that a bug).


On Fri, Oct 25, 2013 at 7:41 AM, zohar argaman <zoharargaman@gmail.com> wrote:
this is interesting. i dont fully understand what you wrote yet…

what does halftime means?
half power point is for filters, isn't it? what kind of filtering takes place and how can it help me understand how manya samples are being processed. i thought i could determine that by changing ksamp/

what is the meaning of the number of samples for a given ihp?
could you clarify what you mean?

On Friday, October 25, 2013 at 2:33 PM, Justin Smith wrote:

To know the number of samples processed at a time by rms, you could start with:

halftime = 1/ihp * sr

since that is only the half power point, you would probably want to calculate the number of samples for a given ihp before you finally reach a full elimination of the input - this would be exactly as many iterations of the above as the number of bits of signal you care about - at the most extreme (high end) that would be the bit depth of your output:

halftime*bitdepth

16 * sr / ihp ; for CD quality output


On Fri, Oct 25, 2013 at 2:05 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
In Csound 6, use setksmps in an instrument or UDO to set the ksmps size. In Csound 5, it only works on UDOs.

http://www.csounds.com/manual/html/setksmps.html


Victor
On 25 Oct 2013, at 09:34, Machina wrote:

> if this is spanish to you guys, maybe you can help me understand how do i change the k-rate for specific section in an instrument (could be independent instrument, but runs parallel to other insturments) without changing the other instruments k-rate… (for my RMS psudo LUFS thing)
> On Thursday, October 24, 2013 at 7:35 PM, Machina wrote:
>
>> Hi guys
>>
>> i was wondering if anybody knows about advance metering systems in csound. i.e. LUFS, LKFS, RA, etc…
>> and if not, if i would want to implement some unweighted loudness unit using rms, how can i know how many samples are being processed? how can i know what kind of averaging takes place (because of the ihp thing, which i dont fully understand)? in other words, if i would like to average out (rms) 0.5 seconds of audio, without smoothing, filtering and such, how is best to perform this?
>>
>> thank ye for ye time
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie





Send bugs reports to the Sourceforge bug trackers
csound6:
            https://sourceforge.net/p/csound/tickets/
csound5:
            https://sourceforge.net/p/csound/bugs/
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"






Date2013-10-25 17:19
FromJustin Smith
SubjectRe: [Csnd] advance amplitude metering for masterign
in OOps/ugens5.c:

int rms(CSOUND *csound, RMS *p)
{
    int     n, nsmps = csound->ksmps;
    MYFLT   *asig;
    double  q;
    double  c1 = p->c1, c2 = p->c2;

    q = p->prvq;
    asig = p->asig;
    for (n=0; n<nsmps; n++) {
      double as = (double)asig[n];
      q = c1 * as * as + c2 * q;
    }
    p->prvq = q;
    *p->kr = (MYFLT) sqrt(q);
    return OK;
}

If I read that correctly, the previous q (quotient?) is stored in p->prvq, and c1*as^2 is added to c2*q to generate the new value of q. So we have summations every ksmps with a scaling factor, being added to the previous sum.

here we have the initialization code:

int rmsset(CSOUND *csound, RMS *p)
{
    double   b;

    b = 2.0 - cos((double)(*p->ihp * csound->tpidsr));
    p->c2 = b - sqrt(b*b - 1.0);
    p->c1 = 1.0 - p->c2;
    if (!*p->istor)
      p->prvq = 0.0;
    return OK;
}

which shows how those c2 and c1 values are being derived. Clearly this is enough information to know how wide the effective window of analysis is, though I don't know the right math to derive that off the top of my head, and someone else here may be more qualified to puzzle it out than I am.


On Fri, Oct 25, 2013 at 9:07 AM, Justin Smith <noisesmith@gmail.com> wrote:
I am under the impression that the window of time for which a sample affects the RMS value that is reported is directly correlated to the ihp value. I could be wrong about this.

My math was assuming that the low pass was a simple recursive lowpass, such that you could calculate the analysis window based on the reciprocal of the ihp frequency. On further consideration that assumption could be totally off base, and one would be better off looking at the source.

I don't think changing the kr should change the window size of the RMS analysis (in fact if it did I would consider that a bug).


On Fri, Oct 25, 2013 at 7:41 AM, zohar argaman <zoharargaman@gmail.com> wrote:
this is interesting. i dont fully understand what you wrote yet…

what does halftime means?
half power point is for filters, isn't it? what kind of filtering takes place and how can it help me understand how manya samples are being processed. i thought i could determine that by changing ksamp/

what is the meaning of the number of samples for a given ihp?
could you clarify what you mean?

On Friday, October 25, 2013 at 2:33 PM, Justin Smith wrote:

To know the number of samples processed at a time by rms, you could start with:

halftime = 1/ihp * sr

since that is only the half power point, you would probably want to calculate the number of samples for a given ihp before you finally reach a full elimination of the input - this would be exactly as many iterations of the above as the number of bits of signal you care about - at the most extreme (high end) that would be the bit depth of your output:

halftime*bitdepth

16 * sr / ihp ; for CD quality output


On Fri, Oct 25, 2013 at 2:05 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
In Csound 6, use setksmps in an instrument or UDO to set the ksmps size. In Csound 5, it only works on UDOs.

http://www.csounds.com/manual/html/setksmps.html


Victor
On 25 Oct 2013, at 09:34, Machina wrote:

> if this is spanish to you guys, maybe you can help me understand how do i change the k-rate for specific section in an instrument (could be independent instrument, but runs parallel to other insturments) without changing the other instruments k-rate… (for my RMS psudo LUFS thing)
> On Thursday, October 24, 2013 at 7:35 PM, Machina wrote:
>
>> Hi guys
>>
>> i was wondering if anybody knows about advance metering systems in csound. i.e. LUFS, LKFS, RA, etc…
>> and if not, if i would want to implement some unweighted loudness unit using rms, how can i know how many samples are being processed? how can i know what kind of averaging takes place (because of the ihp thing, which i dont fully understand)? in other words, if i would like to average out (rms) 0.5 seconds of audio, without smoothing, filtering and such, how is best to perform this?
>>
>> thank ye for ye time
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie





Send bugs reports to the Sourceforge bug trackers
csound6:
            https://sourceforge.net/p/csound/tickets/
csound5:
            https://sourceforge.net/p/csound/bugs/
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"







Date2013-10-25 17:21
FromJustin Smith
SubjectRe: [Csnd] advance amplitude metering for masterign
And finally, unless I am reading this code wrong: it is using a simple recursive lowpass, so the ihp parameter (which controls the recursion) will determine the effective width of the input window for the calculation.


On Fri, Oct 25, 2013 at 9:19 AM, Justin Smith <noisesmith@gmail.com> wrote:
in OOps/ugens5.c:

int rms(CSOUND *csound, RMS *p)
{
    int     n, nsmps = csound->ksmps;
    MYFLT   *asig;
    double  q;
    double  c1 = p->c1, c2 = p->c2;

    q = p->prvq;
    asig = p->asig;
    for (n=0; n<nsmps; n++) {
      double as = (double)asig[n];
      q = c1 * as * as + c2 * q;
    }
    p->prvq = q;
    *p->kr = (MYFLT) sqrt(q);
    return OK;
}

If I read that correctly, the previous q (quotient?) is stored in p->prvq, and c1*as^2 is added to c2*q to generate the new value of q. So we have summations every ksmps with a scaling factor, being added to the previous sum.

here we have the initialization code:

int rmsset(CSOUND *csound, RMS *p)
{
    double   b;

    b = 2.0 - cos((double)(*p->ihp * csound->tpidsr));
    p->c2 = b - sqrt(b*b - 1.0);
    p->c1 = 1.0 - p->c2;
    if (!*p->istor)
      p->prvq = 0.0;
    return OK;
}

which shows how those c2 and c1 values are being derived. Clearly this is enough information to know how wide the effective window of analysis is, though I don't know the right math to derive that off the top of my head, and someone else here may be more qualified to puzzle it out than I am.


On Fri, Oct 25, 2013 at 9:07 AM, Justin Smith <noisesmith@gmail.com> wrote:
I am under the impression that the window of time for which a sample affects the RMS value that is reported is directly correlated to the ihp value. I could be wrong about this.

My math was assuming that the low pass was a simple recursive lowpass, such that you could calculate the analysis window based on the reciprocal of the ihp frequency. On further consideration that assumption could be totally off base, and one would be better off looking at the source.

I don't think changing the kr should change the window size of the RMS analysis (in fact if it did I would consider that a bug).


On Fri, Oct 25, 2013 at 7:41 AM, zohar argaman <zoharargaman@gmail.com> wrote:
this is interesting. i dont fully understand what you wrote yet…

what does halftime means?
half power point is for filters, isn't it? what kind of filtering takes place and how can it help me understand how manya samples are being processed. i thought i could determine that by changing ksamp/

what is the meaning of the number of samples for a given ihp?
could you clarify what you mean?

On Friday, October 25, 2013 at 2:33 PM, Justin Smith wrote:

To know the number of samples processed at a time by rms, you could start with:

halftime = 1/ihp * sr

since that is only the half power point, you would probably want to calculate the number of samples for a given ihp before you finally reach a full elimination of the input - this would be exactly as many iterations of the above as the number of bits of signal you care about - at the most extreme (high end) that would be the bit depth of your output:

halftime*bitdepth

16 * sr / ihp ; for CD quality output


On Fri, Oct 25, 2013 at 2:05 AM, Victor Lazzarini <Victor.Lazzarini@nuim.ie> wrote:
In Csound 6, use setksmps in an instrument or UDO to set the ksmps size. In Csound 5, it only works on UDOs.

http://www.csounds.com/manual/html/setksmps.html


Victor
On 25 Oct 2013, at 09:34, Machina wrote:

> if this is spanish to you guys, maybe you can help me understand how do i change the k-rate for specific section in an instrument (could be independent instrument, but runs parallel to other insturments) without changing the other instruments k-rate… (for my RMS psudo LUFS thing)
> On Thursday, October 24, 2013 at 7:35 PM, Machina wrote:
>
>> Hi guys
>>
>> i was wondering if anybody knows about advance metering systems in csound. i.e. LUFS, LKFS, RA, etc…
>> and if not, if i would want to implement some unweighted loudness unit using rms, how can i know how many samples are being processed? how can i know what kind of averaging takes place (because of the ihp thing, which i dont fully understand)? in other words, if i would like to average out (rms) 0.5 seconds of audio, without smoothing, filtering and such, how is best to perform this?
>>
>> thank ye for ye time
>

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie





Send bugs reports to the Sourceforge bug trackers
csound6:
            https://sourceforge.net/p/csound/tickets/
csound5:
            https://sourceforge.net/p/csound/bugs/
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"








Date2013-10-25 18:03
Fromjpff
SubjectRe: [Csnd] advance amplitude metering for masterign
rms is based on a lp filter of the square of the samples.  I think your 
analysis is mainly correct.



Date2013-10-25 18:50
Fromzohar argaman
SubjectRe: [Csnd] advance amplitude metering for masterign
AttachmentsNone  None  

Date2013-10-25 19:10
FromJustin Smith
SubjectRe: [Csnd] advance amplitude metering for masterign
That's a very large number so I suspect it is off somewhere. Remember that the half time is not half of the time, but the time to get to half amplitude, so you need to multiply the half time by the bit depth to find the total time that the input effects the measurement (each bit of output resolution is effectively one more cutting in half you can do before the signal disappears completely). Of course this only works if input is full scale; more generally, if your peak requires an N bit signal to be represented, you can divide it by 2 N times before it disappears (an input that with peaks half as loud gets one less scaling etc.).


On Fri, Oct 25, 2013 at 10:50 AM, zohar argaman <zoharargaman@gmail.com> wrote:
ok thanks guys
so… effectivly
this is half of the processing time?
halftime = 1/ihp * sr

which means that for 1 sec rms summing, with 44k=sr, wanting to get 0.5 sec half time, means ihp=88k.

right?

On Friday, October 25, 2013 at 8:03 PM, jpff wrote:

rms is based on a lp filter of the square of the samples. I think your
analysis is mainly correct.




Send bugs reports to the Sourceforge bug trackers
csound6:
csound5:
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"



Date2013-10-26 11:35
FromZohar Argaman
SubjectRe: [Csnd] advance amplitude metering for masterign
sounds right, but since the samples that are after half time are less influential (their contribution is cut by at least half), i thought the half time would be a good point to intuitivly disregard their contribution


On Fri, Oct 25, 2013 at 9:10 PM, Justin Smith <noisesmith@gmail.com> wrote:
That's a very large number so I suspect it is off somewhere. Remember that the half time is not half of the time, but the time to get to half amplitude, so you need to multiply the half time by the bit depth to find the total time that the input effects the measurement (each bit of output resolution is effectively one more cutting in half you can do before the signal disappears completely). Of course this only works if input is full scale; more generally, if your peak requires an N bit signal to be represented, you can divide it by 2 N times before it disappears (an input that with peaks half as loud gets one less scaling etc.).


On Fri, Oct 25, 2013 at 10:50 AM, zohar argaman <zoharargaman@gmail.com> wrote:
ok thanks guys
so… effectivly
this is half of the processing time?
halftime = 1/ihp * sr

which means that for 1 sec rms summing, with 44k=sr, wanting to get 0.5 sec half time, means ihp=88k.

right?

On Friday, October 25, 2013 at 8:03 PM, jpff wrote:

rms is based on a lp filter of the square of the samples. I think your
analysis is mainly correct.




Send bugs reports to the Sourceforge bug trackers
csound6:
csound5:
Discussions of bugs and features can be posted here
To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"




Date2013-10-27 11:08
Fromzohar argaman
SubjectRe: [Csnd] advance amplitude metering for masterign
AttachmentsNone  None