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

# FFTW Help

Started by ●October 2, 2010

Reply by ●October 2, 20102010-10-02

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

Reply by ●October 2, 20102010-10-02

On Oct 2, 11:29�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. �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. > > -- glenThank 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

Reply by ●October 2, 20102010-10-02

On Oct 2, 12:04�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? �Are there any other techniques to minimize this? > > Thanks > RayThere 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

Reply by ●October 2, 20102010-10-02

Raeldor <raeldor@gmail.com> wrote:> On Oct 2, 11:29�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. �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.(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

Reply by ●October 3, 20102010-10-03

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

Reply by ●October 3, 20102010-10-03

On Oct 3, 2:09�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

Reply by ●October 3, 20102010-10-03

On Oct 3, 2:12�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.

Reply by ●October 3, 20102010-10-03

On Oct 2, 11:15�pm, kevin <kevinjmc...@netscape.net> wrote:> On Oct 3, 2:12�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!