Windowing in the Frequency Domain

Rune Allnor wrote:
..
> My position might seem absurd in context with the OP.
> However, a totally separate discussion started with
> this post of mine:
> 
> http://groups.google.no/group/comp.dsp/msg/be1c2b9af37a1641?hl=no
> 

Which reminds me: you sort of diverted the subject there from "how" to 
"why" (do time-domain windowing while using the SDFT); I am still 
interested to know "how".

One reason is to be able to try out the Kaiser window, widely used in 
pvoc. Being not based on cosines, there is no obvious way to do it as a 
convolution, and quite possibly no non-obvious way either. Needs more 
maths chops than I am capable of, anyway. I fear it would require too 
high-order a convolution to be useful, unless the audio results are 
truly stellar.

Richard Dobson

Rune Allnor wrote:

> 
> Only when you know what you aim to achieve, can you
> start discussing how to go about achieving it.
> 

Right. So why do you keep insisting one method is better than another
when you don't what the aim is?

-jim

Rune Allnor wrote:
..
> 
> So you have a messy (magnitude) spectrum you would
> like to 'clean up' to be better able to see what
> is 'actual' spectral features and what is just
> noise and random fluctuations?
> 

Not really. The plain output of the SDFT corresponds to equally plain 
rectangular windowing, where the input is arbitrary audio invariably not 
periodic to the window length. So what you get is the usual  spectral 
leakage due to the rectangular window, that hides the peaks of low-level 
components. Beyond that, it is not "messy" at all in the way you suggest.

> If my interpretation is correct, what you have is
> a real-life application for PSD estimation. Just for
> fun, try to use the 'proper' N-1-period windows and
> see how the results compare to both the 'raw' spectrum
> and the 3pt kernel spectrum. You'd presumably want
> to do this with recorded data, not on-line.

As part of my development work, I made a test program to perform among 
other things a direct comparison between the time-domain window function 
and the frequency-domain convolution (via ifft), basically to make sure 
the code for the latter was correct and like was being compared to like. 
They are, to at least 10 decimal places, with the usual f/p roundoff 
accounting for the error differences at and below 1.0e-10. Maybe that 
can be improved, but it was decided that was "good enough" give the very 
short duration for the project. Both forms comply with your "N-1 period" 
criterion. I have in fact not attempted the other form ("N period"?). 
For what we are trying to do (interesting musical transformations), I 
suspect the difference between N and N-1 windowing is rather less 
critical than for the processes you refer to. But if I ever get the 
chance to do a follow-up, that may be something to look at in the cause 
of filling in the gaps.


> 
> My prediction is that the 3pt averaged spectrum will
> be a lot closer to the 'raw' spectrum, but the N-1-
> period windowed spectrum will show smoother spectral
> features.

Given the windows are identical (allowing for the above low-level 
numerical differences), hopefully it will not surprise you that both 
windowing methods give similarly identical results  on the same input.

> 
> I won't have any opinions about what method to use
> (that would depend on what you look for in the spectra),
> just ask you to try to be aware what you are doing and
> why. From the above experiment you might end up with
> the conclusion that you don't need the windows at all.
> 

I tried it early on. I do, as I need the separation of partial 
amplitudes the windowing give me. We may want to do Cool Things such as 
removing odd partials, stretching them,  making sounds inharmonic etc. 
There may be new "exciter" algorithms just waiting to be developed. To 
say nothing of partial tracking, which is something I do want to 
investigate, not least as we already have such tools in Csound.


> A more interesting outcome might be that you start
> experimenting with weighted averages in spectrum domain,
> where the weight coefficients have nothing to do with
> the 'classic' window functions at all. If all you do
> is to compute weighted averages in spectrum domain, why
> constrain the weight coefficients by time-doamin
> properties?

It was more important at this early stage to be able to relate the 
SDFT/SPV results directly to familiar time-domain equivalents. It is 
nevertheless a very interesting question. We have different priorities 
at present (such as developing a Constant-Q version of the transform), 
but I did experiment briefly with hacking a quasi-Kaiser window  by 
taking its FFT, and using the bottom few values of the output as the 
coefficients for a convolved version.  It works as well (or as badly) as 
could be expected. As we are in fact very happy with how the Hann window 
works  (and found a few other choices that work as well, but not 
obviously better), it is not something we have pursued.  I would be 
delighted if someone was sufficiently interested to investigate that 
aspect further.


Richard Dobson

On 15 Apr, 20:36, jim <"sjedgingN0Sp"@m@mwt,net> wrote:
> Rune Allnor wrote:
>
> > Only when you know what you aim to achieve, can you
> > start discussing how to go about achieving it.
>
> Right. So why do you keep insisting one method is better than another
> when you don't what the aim is?

Read my posts again, and try to see if you can discover
where I:

1) Explain what uses for window function I am aware of
2) Explain why I think the frequency-domain computation
   approach is
     a) irrelevant
     b) plain wrong
   for those uses
3) Asks for anyone who knows something I don't, to enlighten
   me.

To rip off a quotation Dale offered earlier on:

Those who don&#4294967295;t read are no better off than those who can&#4294967295;t.
&#4294967295; Mark Twain

Unlike Dale, who apparently writes for merely literate
readers, judging from this quote, I aim a bit higher.
For *intelligent* readers. In vain, it seems.

Rune

Rune Allnor wrote:
> 
> On 15 Apr, 20:36, jim <"sjedgingN0Sp"@m@mwt,net> wrote:
> > Rune Allnor wrote:
> >
> > > Only when you know what you aim to achieve, can you
> > > start discussing how to go about achieving it.
> >
> > Right. So why do you keep insisting one method is better than another
> > when you don't what the aim is?
> 
> Read my posts again, and try to see if you can discover
> where I:
> 
> 1) Explain what uses for window function I am aware of


> 2) Explain why I think the frequency-domain computation
>    approach is
>      a) irrelevant
>      b) plain wrong

Then you are saying that using the Hann window is irrelevant and plain
wrong. For all I know, the OP's purpose is to determine if that is true.




>    for those uses
> 3) Asks for anyone who knows something I don't, to enlighten
>    me.
> 

The Op made it clear it is trivial to implement the window function in
the frequency domain, but more work than he cares to do in the time
domain. How many times does something need to be explained before you
become enlightened.

-jim


> To rip off a quotation Dale offered earlier on:
> 
> Those who don&#4294967295;t read are no better off than those who can&#4294967295;t.
> &#4294967295; Mark Twain
> 
> Unlike Dale, who apparently writes for merely literate
> readers, judging from this quote, I aim a bit higher.
> For *intelligent* readers. In vain, it seems.
> 
> Rune

On Apr 15, 12:43 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>...
>
> Unlike Dale, who apparently writes for merely literate
> readers, judging from this quote, I aim a bit higher.
> For *intelligent* readers. In vain, it seems.
>
> Rune

Rune

The reasons to cite a reference on usenet include:

1) Providing a reviewed, readily available source.

2) Providing a media with equations and figures.

3) Providing a basis in established terminology.

4) Avoiding an error prone restart from scratch to explain topics that
have long since been documented and reduced to effective practice.

The cited portions of the harris paper serve these purposes with
regard to the topic of this thread.


I'm happy to settle for writing for those who do read. They won't be
mislead by errors about frequency kernel size, limited by your
unfamiliarity with windows applications or confused by the repeated
denial of the presence of material posted in this thread.

Dale B. Dalrymple

On 16 Apr, 05:10, dbd <d...@ieee.org> wrote:
> On Apr 15, 12:43 pm, Rune Allnor <all...@tele.ntnu.no> wrote:
>
> >...
>
> > Unlike Dale, who apparently writes for merely literate
> > readers, judging from this quote, I aim a bit higher.
> > For *intelligent* readers. In vain, it seems.
>
> > Rune
>
> Rune
>
> The reasons to cite a reference on usenet include:
>
> 1) Providing a reviewed, readily available source.

Obtaining the paper requires access to IEEE archives.
You have in previous posts presented the view that
paying $10-$15 to get that access is a neglectable
issue. I happen to disagree.

Could you please, for the benefit of those who don't
have access to the paper through IEEE archives, give
a short summary of why it is worth $10-$15 to read
about these N-period windows, and why they are relevant
in contemporary applications?

> 2) Providing a media with equations and figures.

Where? Through IEEE archives one must pay to get access to?

> 3) Providing a basis in established terminology.
>
> 4) Avoiding an error prone restart from scratch to explain topics that
> have long since been documented and reduced to effective practice.

If this is true, that these N-period windows indeed have
been "reduced to effective practice" there should be no
problems coming up with a quick, comprehensable explanation
about why, and what their purpose are?

> The cited portions of the harris paper serve these purposes with
> regard to the topic of this thread.

I have to disagree.

> I'm happy to settle for writing for those who do read. They won't be
> mislead by errors about frequency kernel size, limited by your
> unfamiliarity with windows applications or confused by the repeated
> denial of the presence of material posted in this thread.

This might come as a surprise to you, but I actually
try to learn something. Either by DSP or the human
psychology. I never stop being amazed by the lengths
people go to, to avoid answering even the simplest
questions, when they either have no answers or are
plain wrong.

Say 'hi' to harris from me next time you see him.

Rune

Rune Allnor wrote:
..
>> The reasons to cite a reference on usenet include:
>>
>> 1) Providing a reviewed, readily available source.
> 
> Obtaining the paper requires access to IEEE archives.
> You have in previous posts presented the view that
> paying $10-$15 to get that access is a neglectable
> issue. I happen to disagree.
> 
> Could you please, for the benefit of those who don't
> have access to the paper through IEEE archives, give
> a short summary of why it is worth $10-$15 to read
> about these N-period windows, and why they are relevant
> in contemporary applications?
> 

Or, go to the bottom of this page:

http://en.wikipedia.org/wiki/Window_function

Find the link to the Harris paper, and download it. As it is scanned, 
some of the figs have lost definition; apart from that is is very readable.


Richard Dobson

>
> Ouch... I am not aware of a single application where
> windows are applied in frequency domain...
>

Hello Rune,

Sometimes one defines a signal via a windowed frequency domain
function.

One example is the ghost cancellation reference used in analog
television. This is a frequency chirp.

See details here:

http://www.claysturner.com/dsp/Analog%20GCR%20Details.pdf


Clay

On 16 Apr, 17:12, c...@claysturner.com wrote:
> > Ouch... I am not aware of a single application where
> > windows are applied in frequency domain...
>
> Hello Rune,
>
> Sometimes one defines a signal via a windowed frequency domain
> function.

Sure. That's an obvious corollary to the idea that time-domain
windowing for PSD estimation is an efficient way to implement
frequency-domain weighted averages.

Both Kay and Papoulis, two of the 'heavy' writers on statistical
DSP, explain that windowing in time domain is a means to reduce
the influence of the outer coefficients in the autocorrelation
sequence, which have high variance.

The difference might seem one of merely semantics, but the
'standard' texts on statistical DSP represent lobe widths and
side lobe levels as very big problems. They are, if you restrict
attention only to the 'classical' window functions.

But as you point out, one can just as well design the desired
frequency response and compute the desired time domain
coefficients.

But that's *design*. I still haven't seen any reason to do
the *computations* in frequency domain.

Rune