howdy, help file says "The analysis is "Hanning" (raised cosine) windowed."
how does that work? I tried looking at the code and got no clue...
I assume it's not just passing the input through a hanning window, and one way or another, it's gotta compensate it, right? But how?
cheers
Am Donnerstag, den 23. März 2017 um 01:34:58 Uhr (-0300) schrieb Alexandre Torres Porres:
howdy, help file says "The analysis is "Hanning" (raised cosine) windowed."
how does that work? I tried looking at the code and got no clue...
In the object's new method, the object allocates a buffer ("buf") and writes the Hanning function with RMS compensation (the two nested divisions by npoints) into it.
I assume it's not just passing the input through a hanning window, and one way or another,
That's exactly what it does. The Hanning window emphasizes the middle of the analysis window and by adjusting the hop size in the second argument of env~ you can fine tune the results.
-- Orm
some additions:
the object maintains a summing buffer where it writes the current sum of the different analysis windows (the number of windows depends on the hop size), starting with the most recent one.
what happens in the loop is that it takes n input samples, squares them, multiplies it with a section of the hanning windows depending on the current phase and adds the sum to the first element of the summing buffer. this is repeated for the number of overlaps, but the pointer into the hanning window gets incremented based on the phase difference (= hop size) and the result is now added to the *next* element in the summing buffer etc.
once the sum of a complete analysis window has been calculated (this takes 16 DSP ticks when your block size is 64 and the [env~] window size is 1024), the elements of the summing buffer are shifted one element to the front, the front (= sum of the most recent window) itself gets popped and passed to the outlet (where it is converted from power to decibels).
the powtodb function takes care of taking the square root of the sum but it's done in the logarithmic domain where it's just a division by two.
with smaller hop sizes you basically just get more frequent updates while maintaining a larger window size but with more CPU cost.
this is at least how I understood the code.
Gesendet: Donnerstag, 23. März 2017 um 10:54 Uhr Von: "Orm Finnendahl" orm.finnendahl@selma.hfmdk-frankfurt.de An: pd-list@lists.iem.at Betreff: Re: [PD] how does env~ work?
Am Donnerstag, den 23. März 2017 um 01:34:58 Uhr (-0300) schrieb Alexandre Torres Porres:
howdy, help file says "The analysis is "Hanning" (raised cosine) windowed."
how does that work? I tried looking at the code and got no clue...
In the object's new method, the object allocates a buffer ("buf") and writes the Hanning function with RMS compensation (the two nested divisions by npoints) into it.
I assume it's not just passing the input through a hanning window, and one way or another,
That's exactly what it does. The Hanning window emphasizes the middle of the analysis window and by adjusting the hop size in the second argument of env~ you can fine tune the results.
-- Orm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
how does overlap affect the rms value? If I use an overlap of 32 I see no difference, except the output rate.
2017-03-23 8:07 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
some additions:
the object maintains a summing buffer where it writes the current sum of the different analysis windows (the number of windows depends on the hop size), starting with the most recent one.
what happens in the loop is that it takes n input samples, squares them, multiplies it with a section of the hanning windows depending on the current phase and adds the sum to the first element of the summing buffer. this is repeated for the number of overlaps, but the pointer into the hanning window gets incremented based on the phase difference (= hop size) and the result is now added to the *next* element in the summing buffer etc.
once the sum of a complete analysis window has been calculated (this takes 16 DSP ticks when your block size is 64 and the [env~] window size is 1024), the elements of the summing buffer are shifted one element to the front, the front (= sum of the most recent window) itself gets popped and passed to the outlet (where it is converted from power to decibels).
the powtodb function takes care of taking the square root of the sum but it's done in the logarithmic domain where it's just a division by two.
with smaller hop sizes you basically just get more frequent updates while maintaining a larger window size but with more CPU cost.
this is at least how I understood the code.
Gesendet: Donnerstag, 23. März 2017 um 10:54 Uhr Von: "Orm Finnendahl" orm.finnendahl@selma.hfmdk-frankfurt.de An: pd-list@lists.iem.at Betreff: Re: [PD] how does env~ work?
Am Donnerstag, den 23. März 2017 um 01:34:58 Uhr (-0300) schrieb Alexandre Torres Porres:
howdy, help file says "The analysis is "Hanning" (raised cosine)
windowed."
how does that work? I tried looking at the code and got no clue...
In the object's new method, the object allocates a buffer ("buf") and writes the Hanning function with RMS compensation (the two nested divisions by npoints) into it.
I assume it's not just passing the input through a hanning window, and
one
way or another,
That's exactly what it does. The Hanning window emphasizes the middle of the analysis window and by adjusting the hop size in the second argument of env~ you can fine tune the results.
-- Orm
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/
listinfo/pd-list
2017-03-23 10:58 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
how does overlap affect the rms value? If I use an overlap of 32 I see no difference, except the output rate.
this is comparing an overlap of 32 to an overlap of "1" (no overlaps), and a window size of 8192 (256 being the hop size) - the input is a sinusoid
I do realize the windowing makes the result more accurate and stable, somehow... (and feel like the overlap affects only the output rate)
2017-03-23 10:59 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-23 10:58 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
how does overlap affect the rms value? If I use an overlap of 32 I see no difference, except the output rate.
this is comparing an overlap of 32 to an overlap of "1" (no overlaps), and a window size of 8192 (256 being the hop size) - the input is a sinusoid
(and feel like the overlap affects only the output rate)
Exactly! That's what i meant.
2017-03-23 10:59
Gesendet: Donnerstag, 23. März 2017 um 15:12 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] how does env~ work?
I do realize the windowing makes the result more accurate and stable, somehow... (and feel like the overlap affects only the output rate)
2017-03-23 10:59 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-23 10:58 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
how does overlap affect the rms value? If I use an overlap of 32 I see no difference, except the output rate.
this is comparing an overlap of 32 to an overlap of "1" (no overlaps), and a window size of 8192 (256 being the hop size) - the input is a sinusoid
sorry, I guess I didn't get most of what you said :/ kinda over my head...
2017-03-23 15:06 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
(and feel like the overlap affects only the output rate)
Exactly! That's what i meant.
2017-03-23 10:59
Gesendet: Donnerstag, 23. März 2017 um 15:12 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: Re: [PD] how does env~ work?
I do realize the windowing makes the result more accurate and stable, somehow... (and feel like the overlap affects only the output rate)
2017-03-23 10:59 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-23 10:58 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
how does overlap affect the rms value? If I use an overlap of 32 I
see no
difference, except the output rate.
this is comparing an overlap of 32 to an overlap of "1" (no overlaps),
and
a window size of 8192 (256 being the hop size) - the input is a
sinusoid
Am Donnerstag, den 23. März 2017 um 10:59:16 Uhr (-0300) schrieb Alexandre Torres Porres:
the input is a sinusoid
That's the problem: If the size of the analysis window is sufficiently large compared to the frequency of a static sinusoid You can't really expect any difference in the rms values if the window gets shifted. As stated before, no overlap-add is performed.
2017-03-23 6:54 GMT-03:00 Orm Finnendahl
In the object's new method, the object allocates a buffer ("buf") and writes the Hanning function with RMS compensation (the two nested divisions by npoints) into it.
ok, I get "buf" is a hann window with very small values (which depend on npoints, the greater, the smaller) - so by dividing it by the number of points, it's already doing the 'mean' value... that's what you mean by "RMS compensated"?
I don't get what 'hp' is (x->x_buf + count)
all values (which depend on npoints, the greater, the smaller).
then I get that the square sum is normalized by being multiplied to 'hp'...
So, Basically, if I want to remove the 'hann normalization', I just take 'hp' out and divide it by npoints.
I tried it, and what I get is a more deviated value.
and as I see it, it's just applying a hanning envelope into the input and NOTHING more, right?
It is not really compensating in any way, either with overlaping, or multiplying the result for normalizing it, huh?
This was my original question, if it was compensated somehow, but it seems not.
cheers
2017-03-23 16:45 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
and as I see it, it's just applying a hanning envelope into the input and NOTHING more, right?
the hanning envelope itself actually goes from 0 to "2" and not from 0 to 1, so I assume the compensation is done right there...
2017-03-23 16:53 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-23 16:45 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
and as I see it, it's just applying a hanning envelope into the input and NOTHING more, right?
the hanning envelope itself actually goes from 0 to "2" and not from 0 to 1, so I assume the compensation is done right there...
tested with an envelope going from 0 to 1 and lost about 3.0103 dB ;)
actually, also, the envelope is applied to the squares of the amplitudes... and this gets me completely lost now on what it means mathematically
2017-03-23 17:00 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-23 16:53 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-03-23 16:45 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
and as I see it, it's just applying a hanning envelope into the input and NOTHING more, right?
the hanning envelope itself actually goes from 0 to "2" and not from 0 to 1, so I assume the compensation is done right there...
tested with an envelope going from 0 to 1 and lost about 3.0103 dB ;)
On Thu, Mar 23, 2017 at 4:11 PM, Alexandre Torres Porres porres@gmail.com wrote:
actually, also, the envelope is applied to the squares of the amplitudes... and this gets me completely lost now on what it means mathematically
It means that negative signals will count the same as positive ones.
Martin
sorry, I guess I didn't get most of what you said :/ kinda over my head...
no worries. just an awkward attempt from my side to explain code with words :-D.
actually, also, the envelope is applied to the squares of the amplitudes... and this gets me completely lost now on what it means mathematically
https://en.wikipedia.org/wiki/Root_mean_square in short, RMS means you square each sample, sum them, divide the sum by the number of samples and then take the square root. in case you're wondering where the square root is, it is in powtodb(). compare rmstodb() and powtodb() to see the difference. rmstodb() expects an rms value (the square root already taken) while powtodb() will take the square root for you (and luckily, log(sqrt(x) is simply log(x)/2).
the hanning envelope itself actually goes from 0 to "2" and not from 0 to 1, so I assume the compensation is done right there...
that's a good observation!
the integral (= running sum) of f(x) = 0.5 - cos(2pi*x)*0.5 (= Hanning window within range 0-1) is F(x) = x*0.5 - sin(2pi*x)/4pi
F(1) (= the sum after a full period) is 0.5. That's the reason why the Hanning window in this case is twice as large to bring the sum to 1. weighting a constant(!) signal with such a Hanning window will yield the same sum as with a non-weighted signal.
Christof
Gesendet: Donnerstag, 23. März 2017 um 21:11 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] how does env~ work?
actually, also, the envelope is applied to the squares of the amplitudes... and this gets me completely lost now on what it means mathematically 2017-03-23 17:00 GMT-03:00 Alexandre Torres Porres <porres@gmail.com[mailto:porres@gmail.com]>:
2017-03-23 16:53 GMT-03:00 Alexandre Torres Porres <porres@gmail.com[mailto:porres@gmail.com]>: 2017-03-23 16:45 GMT-03:00 Alexandre Torres Porres <porres@gmail.com[mailto:porres@gmail.com]>:
and as I see it, it's just applying a hanning envelope into the input and NOTHING more, right? the hanning envelope itself actually goes from 0 to "2" and not from 0 to 1, so I assume the compensation is done right there... tested with an envelope going from 0 to 1 and lost about 3.0103 dB ;)_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
easy, I do at least know that much about what squaring is ;)
2017-03-23 19:27 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
F(1) (= the sum after a full period) is 0.5. That's the reason why the Hanning window in this case is twice as large to bring the sum to 1. weighting a constant(!) signal with such a Hanning window will yield the same sum as with a non-weighted signal.
thanks for trying again,I figured something like that happened, but I still can't get my head around the math ;) - I'll just be happy knowing it works for some reason... haha
Am Donnerstag, den 23. März 2017 um 17:00:14 Uhr (-0300) schrieb Alexandre Torres Porres:
the hanning envelope itself actually goes from 0 to "2" and not from 0 to 1, so I assume the compensation is done right there...
tested with an envelope going from 0 to 1 and lost about 3.0103 dB ;)
You're almost there: If you average the values in a rectangular window with the amplitude 1 you will get 1, the same value results if averaging the values of a Hanning window with amplitude 2 (you can check that by building the definite integral of the Hanning function cos(x-pi)+1 in the interval [0..6.28] and divide that by the width of the interval (6.28)).
If you use a Hanning window of amplitude 1, you'll get 0.5 as the average. As the windowing is applied to the squared values, after calculating the root (for obtaining the "R"MS), you'll end up with sqrt(0.5) = 0.707 of the "real" RMS value and that equals to -3.0103 dB.
In short: Using a Hanning window with amplitude 2 on the squared values will compensate the loss of the resulting mean value introduced by the windowing function. The result is a compensated RMS value with an emphasis on the center of the analysis window. In this use case the windowing results in smoothing the irregularities you observed when using rectangular windows.
-- Orm
-
Alexandre Torres Porres -
Christof Ressi -
Martin Peach -
Orm Finnendahl