On Oct 2, 11:15&#4294967295;pm, kevin <kevinjmc...@netscape.net> wrote:
> On Oct 3, 2:12&#4294967295;am, kevin <kevinjmc...@netscape.net> wrote:
>
> Aaargh! Another mistake - the 'sampling inteval' in the second
> paragraph should be N/s_r, not s_r/N.

Thanks for the replies, guys.  As usual it'll take me a little while
to digest all the great info.  It may be less of an issue in a real
sample (I'm analyzing voice for closeness of pronunciation), but I
noticed in my test samples with sine waves it really showed it's head
pretty clearly.  I'll experiment a little with different windowing
options and see how it looks on both the sine wave samples and the
voice samples.

Thanks again!

On Oct 3, 2:12&#4294967295;am, kevin <kevinjmc...@netscape.net> wrote:

Aaargh! Another mistake - the 'sampling inteval' in the second
paragraph should be N/s_r, not s_r/N.

On Oct 3, 2:09&#4294967295;am, kevin <kevinjmc...@netscape.net> wrote:

Dang! Second line above should be s_r/N, not s_r/n.  One of these days
I'll learn to type properly.

Kevin McGee

Raeldor <rael...@gmail.com> wrote:

> (snip)

Let's see. You've got N = 4096 and a sampling rate (s_r) of 44100, so
your 'bin width' and bin spacing in the frequency domain is s_r/n =
10.76 hz or so. You can tell immediately that you'll have leakage in
your results because the 440 hz sine wave is not an integer multiple
of your bin spacing (i.e.: you don't have an FFT output point that
corresponds EXACTLY to the frequency off your input).  Based on the
numbers you're using, the closest bins are at k = 40 (corresponds to
40*s_r/N = 430.66 hz) and k = 41 (corresponds to 41*s_r/N = 441.43
hz).

You can figure out the number of cycles of your 440 tone within the
4096 FFT samples by considering that your 'sampling interval' (total
length of time represented by your 4096 samples) is s_r/N = 4096/44100
= .09287 seconds, and a single cycle of your 440 hz input is 1/440 = .
00227 seconds.  So dividing your sampling interval by the time for 1
cycle of your input gives you about 40.87 cycles.

So what you're seeing is probably due to leakage in the frequency
domain.

I said probably because you also mentioned a window in your post. Is
that an implied rectangular window, or an explicit one (e.g.: Hann,
Hamming, etc.)?  Explicit windows can help you reduce leakage effects,
but there are trade-offs and subtleties in using them (see Dale's link
in the dbd post above for the well known Harris paper on windows).
You have to know how the parameters of the window can affect your
results.  There are even 'sum of cosine' windows that can reduce the
leakage to zero above and below certain points, even if you have an
input sinusoid that's non-periodic in the sampling interval (R. J.
Webster, IEEE Proc., Oct 1980).

Kevin McGee

Raeldor <raeldor@gmail.com> wrote:
> On Oct 2, 11:29&#4294967295;am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Raeldor <rael...@gmail.com> wrote:

>> > Basically, I have a 3 second 440hz sine wave file created in Audacity
>> > at 44.1khz sampling rate. &#4294967295;I am running FFTW on a 4096 size window on
>> > the data and moving the window along by a small amount each time. &#4294967295;I
>> > was expecting the sum of all the amplitudes returned from FFTW to be
>> > the same for each run of the window as it moves along, but there is a
>> > noticeable difference. &#4294967295;

>> Why would you expect that? &#4294967295;It is hard to answer without knowing,
>> as there is little reason to expect it. &#4294967295;If you have a whole
>> number of cycles of the 440Hz, then it would be a reasonably
>> expectation.
(snip)
 
> Thank you for the reply Glen.  Yes, I meant whole cycles... sorry, I'm
> new to this and still picking up the terminology.
 
> If I wanted to get rid of this anomaly would using some kind of
> exponential curve on the data set to effectively 'fade in and out'
> help?  Are there any other techniques to minimize this?

The way to get rid of it is to include only whole cycles.

If you can't do that, then you need to say what you are really
trying to do.  The first post sounded like you were testing out
FFTW, though the actual use might be different.

The math for it says that the sum of the squares in frequency space
is proportional to the sum of the squares in real space.

-- glen

On Oct 2, 12:04&#4294967295;pm, Raeldor <rael...@gmail.com> wrote:
> ...
>
> If I wanted to get rid of this anomaly would using some kind of
> exponential curve on the data set to effectively 'fade in and out'
> help? &#4294967295;Are there any other techniques to minimize this?
>
> Thanks
> Ray

There is a technique called windowing.

http://utdallas.edu/~cpb021000/EE%204361/Great%20DSP%20Papers/Harris%20on%20Windows.pdf

Windowing may help your expectation when you do not have a integer
number of cycles of your sine wave in your fft. It may hurt your
expectations when you don't.

The fact that you refer to what you have found as an anomaly makes
your expectations suspect. Better to find out how things actually work
first and then grow expectations. Many people come to comp.dsp with
continuous/infinite Fourier transform expectations for discrete/finite
transform behavior. Sometimes it is close. Sometimes it isn't.
(Depending on what you expect 'close' to mean. :)

Dale B. Dalrymple

On Oct 2, 11:29&#4294967295;am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Raeldor <rael...@gmail.com> wrote:
> > I'm doing some tests with FFTW and it seems to be working ok, but I am
> > seeing something that's a little odd and was wondering if my reasoning
> > for it happening was correct.
> > Basically, I have a 3 second 440hz sine wave file created in Audacity
> > at 44.1khz sampling rate. &#4294967295;I am running FFTW on a 4096 size window on
> > the data and moving the window along by a small amount each time. &#4294967295;I
> > was expecting the sum of all the amplitudes returned from FFTW to be
> > the same for each run of the window as it moves along, but there is a
> > noticeable difference. &#4294967295;
>
> Why would you expect that? &#4294967295;It is hard to answer without knowing,
> as there is little reason to expect it. &#4294967295;If you have a whole
> number of cycles of the 440Hz, then it would be a reasonably
> expectation.
>
> > Is this because the starting point of the
> > sample of data doesn't start and end cleanly at the same position
> > along the sine wave?
>
> If this means a whole number of cycles, then yes.
>
> -- glen

Thank you for the reply Glen.  Yes, I meant whole cycles... sorry, I'm
new to this and still picking up the terminology.

If I wanted to get rid of this anomaly would using some kind of
exponential curve on the data set to effectively 'fade in and out'
help?  Are there any other techniques to minimize this?

Thanks
Ray

Raeldor <raeldor@gmail.com> wrote:
 
> I'm doing some tests with FFTW and it seems to be working ok, but I am
> seeing something that's a little odd and was wondering if my reasoning
> for it happening was correct.
 
> Basically, I have a 3 second 440hz sine wave file created in Audacity
> at 44.1khz sampling rate.  I am running FFTW on a 4096 size window on
> the data and moving the window along by a small amount each time.  I
> was expecting the sum of all the amplitudes returned from FFTW to be
> the same for each run of the window as it moves along, but there is a
> noticeable difference.  

Why would you expect that?  It is hard to answer without knowing,
as there is little reason to expect it.  If you have a whole
number of cycles of the 440Hz, then it would be a reasonably
expectation.

> Is this because the starting point of the
> sample of data doesn't start and end cleanly at the same position
> along the sine wave?

If this means a whole number of cycles, then yes.

-- glen

Hi All,

I'm doing some tests with FFTW and it seems to be working ok, but I am
seeing something that's a little odd and was wondering if my reasoning
for it happening was correct.

Basically, I have a 3 second 440hz sine wave file created in Audacity
at 44.1khz sampling rate.  I am running FFTW on a 4096 size window on
the data and moving the window along by a small amount each time.  I
was expecting the sum of all the amplitudes returned from FFTW to be
the same for each run of the window as it moves along, but there is a
noticeable difference.  Is this because the starting point of the
sample of data doesn't start and end cleanly at the same position
along the sine wave?

Thanks
Ray