Hello I am working on a software that will do frequency analysis of a sound signal. When doing the FFT (or DFT) the result is a compex number where the real part corresponds to the cosine component and the imaginary part corresponds to the sine component of the signal. If I analyze a sound consisting of a single frequency there is a slight difference in the DFT result, regarding the frequency of the sine and cosine components. The sine have a higher frequnecy than the cosine. Not much, but still... I would like to know what is the common approach to this problem? (Which frequency to use?) Should I pick one of the components and stick to that? Should I interpolate between the to results or use an average? Any ideas? Regards Jonas Rundberg

# Using Re[X] or Im[X] from FFT result

Started by ●September 16, 2004

Reply by ●September 16, 20042004-09-16

Usually you are interested in the POWER of the signal, so you should be interested in the module of the FFT (Re*Re+Im*Im, or its square root). Cheers, -- Robert Lacoste ALCIOM - The mixed signal experts www.alciom.com "Jonas Rundberg" <ridpiska@hotmail.com> a �crit dans le message de news:c17c86da.0409152311.fb9bdf4@posting.google.com...> Hello > > I am working on a software that will do frequency analysis of a sound > signal. When doing the FFT (or DFT) the result is a compex number > where the real part corresponds to the cosine component and the > imaginary part corresponds to the sine component of the signal. > If I analyze a sound consisting of a single frequency there is a > slight difference in the DFT result, regarding the frequency of the > sine and cosine components. The sine have a higher frequnecy than the > cosine. Not much, but still... > > I would like to know what is the common approach to this problem? > (Which frequency to use?) > Should I pick one of the components and stick to that? Should I > interpolate between the to results or use an average? > Any ideas? > > Regards > Jonas Rundberg

Reply by ●September 16, 20042004-09-16

Can you be more specific? The DFT uses bins at discrete frequencies, so how can the "sine part" have a different frequency than the "cosine part" for any given complex DFT bin...? -- Stephan M. Bernsee http://www.dspdimension.com

Reply by ●September 16, 20042004-09-16

Jonas Rundberg wrote:> Hello > > I am working on a software that will do frequency analysis of a sound > signal. When doing the FFT (or DFT) the result is a compex number > where the real part corresponds to the cosine component and the > imaginary part corresponds to the sine component of the signal. > If I analyze a sound consisting of a single frequency there is a > slight difference in the DFT result, regarding the frequency of the > sine and cosine components. The sine have a higher frequnecy than the > cosine. Not much, but still... > > I would like to know what is the common approach to this problem? > (Which frequency to use?) > Should I pick one of the components and stick to that? Should I > interpolate between the to results or use an average? > Any ideas? > > Regards > Jonas RundbergDo the sine and cosine parts appear to be one bin apart? If so, you are counting wrong. The frequencies reported by a DFT are quantized by the bin spacing. Any difference, however slight, must be a whole number of bin widths. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������

Reply by ●September 17, 20042004-09-17

Jerry Avins <jya@ieee.org> wrote in message news:<4149a94a$0$2666$61fed72c@news.rcn.com>...> Jonas Rundberg wrote: > > > Hello > > > > I am working on a software that will do frequency analysis of a sound > > signal. When doing the FFT (or DFT) the result is a compex number > > where the real part corresponds to the cosine component and the > > imaginary part corresponds to the sine component of the signal. > > If I analyze a sound consisting of a single frequency there is a > > slight difference in the DFT result, regarding the frequency of the > > sine and cosine components. The sine have a higher frequnecy than the > > cosine. Not much, but still... > > > > I would like to know what is the common approach to this problem? > > (Which frequency to use?) > > Should I pick one of the components and stick to that? Should I > > interpolate between the to results or use an average? > > Any ideas? > > > > Regards > > Jonas Rundberg > > Do the sine and cosine parts appear to be one bin apart? If so, you are > counting wrong. The frequencies reported by a DFT are quantized by the > bin spacing. Any difference, however slight, must be a whole number of > bin widths. > > JerryWell, yes, but indexing need not have anything to do with the problem. I recreated the problem by the matlab code below. Jonas might want to plot the absolute value of the spectrum. Rune %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% N=32; % Number of samples in time series f=8.5/N; % Frequency (Fs = 1) tv=[0:N-1]; % Time base s=sin(2*pi*f*tv); % Odd part of signal c=cos(2*pi*f*tv); % Even part of signal x=s+c; % Signal nfft=1024; % 1024 pt FFT to interpolate spectra X=fft(x,nfft); % fv=[0:nfft-1]/nfft; % Plot interpolated spectrum: |Real part|, |Imaginary part|, % magnitude. plot(fv,abs(real(X)),'b',fv,abs(imag(X)),'r',fv,abs(X),'g')

Reply by ●September 17, 20042004-09-17

> Thank you all for your replies. > > However, I cannot tell from your answers wheather my results are > correct or not. To illustrate my problem I have collected my data in a > diagram. > I send a 8 kHz sine wave through my speakers and record it with my > mic. Then i do DFT using the FFTW3 library, and plot the result i the > diagram below: > http://www.rundberg.com/jonas/fftresults.gif > The sine peak (taken from Im[x]) is at 7988 Hz and the cosine peak > (taken from Re[x]) is at 8031 Hz. That is 43 Hz or 2 bins away from > each other. > > Is this a result to expect? Maybe is has to do with the library used? > Can I use the average (8010 Hz) of the two peaks? > > Thank you > / Jonas RundbergHi Jonas. This is an incredibly important piece of infomation! I can guarantee that the FFTW library has nothing to do with your problem. To check the FFTW, generate a synthetic set of data (see my other posts to find out how) and run them through the FFT. The split you see in the figure is due to the data and not the processing. In the magnitude spectrum, there is a small coefficient between the large ones, which means that you have two spectrum lines very close. I would guess that this split is due to some nonlinear effect in the speaker (or possibly in the mic). To check this, I suggest the following: - Test the FFTW library with synthetic, not recorded, data. You will see no line split when you plot the magnitude spectrum. - Play the sine at a louder volume (if necessary, reduce the volume of the mic pre-amp to avoid signal saturation) and repeat your measurement + analysis. If you see an "wider split" of the lines, or possiby more 'extra' lines showing up, the line split is caused by the speakers. - Conversely, if you play the sine at a quieter volume and repeat the measurement + analysis, I would expect the two lines to collapse into one spectral feature. To keep the measurements comparable, make sure you use the same number of samples in all FFTW analyses. Rune

Reply by ●September 17, 20042004-09-17

Rune Allnor wrote: ...> This is an incredibly important piece of infomation!...> - Test the FFTW library with synthetic, not recorded, data. You will > see no line split when you plot the magnitude spectrum. > - Play the sine at a louder volume (if necessary, reduce the volume of > the mic pre-amp to avoid signal saturation) and repeat your measurement > + analysis. If you see an "wider split" of the lines, or possiby more > 'extra' lines showing up, the line split is caused by the speakers. > - Conversely, if you play the sine at a quieter volume and repeat the > measurement + analysis, I would expect the two lines to collapse > into one spectral feature.Fantastic! An acoustic Zeeman effect! You are really good to spot something like that. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������

Reply by ●September 17, 20042004-09-17

In article <2qtm49F12ltunU1@uni-berlin.de>, Stephan M. Bernsee <spam@dspdimension.com> wrote:> >Can you be more specific? The DFT uses bins at discrete frequencies, so >how can the "sine part" have a different frequency than the "cosine >part" for any given complex DFT bin...?Stephan is asking the right question. I once had a similar problem. It turned out that I didn't understand the format of the output of the FFT routine. Once I figured out where the outputs were, I didn't have that problem any more. What is the output format of your FFT routine?

Reply by ●September 18, 20042004-09-18

george.w.bush@whitehouse.com (George Bush) wrote in message news:<SmJ2d.8496$XW.8269@twister.socal.rr.com>...> In article <2qtm49F12ltunU1@uni-berlin.de>, Stephan M. Bernsee <spam@dspdimension.com> wrote: > > > >Can you be more specific? The DFT uses bins at discrete frequencies, so > >how can the "sine part" have a different frequency than the "cosine > >part" for any given complex DFT bin...? > > Stephan is asking the right question. I once had a similar problem. It > turned out that I didn't understand the format of the output of the FFT > routine. Once I figured out where the outputs were, I didn't have that > problem any more. What is the output format of your FFT routine?Right. It could look as if the magenta curve equals the black curve, but shifted two samples to the left. This could be a matter data formatting just as much as it could be a "weird" physical effect. In my first ever analysis job that involved experimental data, I was asked to look at some seismic data from the North Sea. The geology of the North Sea is pretty well known, and "everybody" knows that the sound speed of sediments and rocks don't exceed 2.0 - 2.2 km/s until several hundred meters below the sea floor. I had gotten my local data guru to fetch me some data from the in-house database. This database was on a format proprietary to the seismic processing software, and no documentation was available. So my colleague shuffled the data out in a binary file which was on an "unformatted FORTRAN" binary format. I knew how many traces were there, and I knew how many samples there were in eaxh trace. I wrote my very simple binary data import function in matlab, imported the data and ran my analysis. I plotted one or two traces to check that the numbers made sense, they did, and I embarked on my own velocity estimation project. Imagine my surprise when I found "loud and clear" waves in the data that travelled at 2.5 km/s! 500 m/s faster than anything ever seen before in the North Sea. Even worse, there was no trace of the direct sound that propagate in the water column, that travel at nominal speeds of 1500 m/s and usually completely dominates the raw sesmic data. I spent a couple of days talking to people, no one understood what was wrong, since no one understood how I did my processing. I did not understand what was wrong, since I did not understand data acquisition, standard processing, and at the time barely understood my own processing routines. One scientist saw my perdicament and asked me to explain to him in detail what I had done. When he heard what intermediate data format I had used, he asked "You have, of course, accounted for the data coulmn markers?" I hadn't. I had never heard of the buggers. It turned out that FORTRAN, when it stores matrixes in the "unformatted" data file format, inserts some integers at the beginning and end of each column of the matrix. I did not know that, so I had read the data in sequence, thus unknowingly advancing each data trace by two samples relative to the previous trace. When plotting single traces, the two samples had no effect. When plotting the full data matrix as an image, the effect was clearly visible as a "skewing" of the expected features in the raw data. This skewing, in turn, had the effect of "speeding up" the data. (I know, this might sound a bit awkward, but in the data section I looked at, the advancing waves came from the 'increasing index' direction.) When I adjusted for these extra samples, all the numbers popped out exactly as expected. Data formats can never be documented too well. Rune

Reply by ●September 18, 20042004-09-18

Jerry Avins <jya@ieee.org> wrote in message news:<414af497$0$2646$61fed72c@news.rcn.com>...> Rune Allnor wrote: > > ... > > > This is an incredibly important piece of infomation! > > ... > > > - Test the FFTW library with synthetic, not recorded, data. You will > > see no line split when you plot the magnitude spectrum. > > - Play the sine at a louder volume (if necessary, reduce the volume of > > the mic pre-amp to avoid signal saturation) and repeat your measurement > > + analysis. If you see an "wider split" of the lines, or possiby more > > 'extra' lines showing up, the line split is caused by the speakers. > > - Conversely, if you play the sine at a quieter volume and repeat the > > measurement + analysis, I would expect the two lines to collapse > > into one spectral feature. > > Fantastic! An acoustic Zeeman effect! You are really good to spot > something like that. > > JerryThanks, but working with real data is 95% about sniffing out these kinds of "trivial" details. Is it a plotting effect (ref Richard Owlett's recent thread)? Is it a data format effect (which it might be in this case, ref my reply to a post from George Bush)? Or is it some obscure physical phenomenon? Most of the time, these things are due to plotting, in which case they may be seen as annoying and must somehow be "filtered out" in the future. Some times they are due to bad data formatting, in which case one could end up with the most ridiculous results from analysis, if one does not correct them. And every once in a blue moon, they are actually due to some physical phenomenon. If so, they might very well be the key to untangling the analysis of the data. Over the last five years, I have been involved in one analysis where I know spotting one such "insignificant" detail made the difference, and one where it might well have done but where the "bold" interpretation has not been confirmed. Rune