Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Rightclick on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
From: Piotr Majdak <piotr@ma...>  20040920 16:04:19

Hi *, There is a bug calculating amplitude spectrum function in the menu View/Plot Spectrum (FFT): Analysing a simple harmonic I see some spikes in the amplitude spectrum, where they shouldn't be. They get bigger extending the resolution of the FFT or using more complicated analysis windows. To reproduce this bug:  Create a track with a single sine tone: Generate/Tone, Frequency: 1000, OK  Select some seconds of the track  Go to View/Plot Spectrum  Change settings to: Spectrum  16384 Rectangular window  Linear Freq. You should see this: http://iem.at/~majdak/temp/spect16384.jpg If you change the analysis window to hanning, the situation gets even worse (in terms of SNR). Look at that: http://iem.at/~majdak/temp/spect16384hanning.jpg Decreasing the number of bins to 2048, you still can see the distortions in spectrum: http://iem.at/~majdak/temp/spect2048hanning.jpg Can anyone confirm this? It looks like sloppy cast conversions in the windowing/FFT algorithms (do you _really_ use float numbers everywhere?) Piotr Majdak PS: OS: Win2000 SP5, Audacity 1.2.2 
From: Piotr Majdak <piotr@ma...>  20040920 16:04:19

Hi *, There is a bug calculating amplitude spectrum function in the menu View/Plot Spectrum (FFT): Analysing a simple harmonic I see some spikes in the amplitude spectrum, where they shouldn't be. They get bigger extending the resolution of the FFT or using more complicated analysis windows. To reproduce this bug:  Create a track with a single sine tone: Generate/Tone, Frequency: 1000, OK  Select some seconds of the track  Go to View/Plot Spectrum  Change settings to: Spectrum  16384 Rectangular window  Linear Freq. You should see this: http://iem.at/~majdak/temp/spect16384.jpg If you change the analysis window to hanning, the situation gets even worse (in terms of SNR). Look at that: http://iem.at/~majdak/temp/spect16384hanning.jpg Decreasing the number of bins to 2048, you still can see the distortions in spectrum: http://iem.at/~majdak/temp/spect2048hanning.jpg Can anyone confirm this? It looks like sloppy cast conversions in the windowing/FFT algorithms (do you _really_ use float numbers everywhere?) Piotr Majdak PS: OS: Win2000 SP5, Audacity 1.2.2 
From: Dominic Mazzoni <dominic@au...>  20040921 19:45:49

Piotr, I will take a closer look at some point, but my suspicion is the fact that Audacity is using singleprecision floating point FFT calculations, with accumulations in doubles in just a few key places. I did a few brief experiments and discovered that the difference between singleprecision and doubleprecision FFT is minimal up to 2048; for 4096 there are occasional deviations but overall it's stable, and beyond that there are significant deviations. Is that consistent with your observations? Perhaps we could add a doubleprecision FFT routine and switch to using that for FFT sizes of 8192 and higher? Then we could allow much larger FFTs, too, if you're willing to wait.  Dominic On Sep 20, 2004, at 9:08 AM, Piotr Majdak wrote: > Hi *, > > There is a bug calculating amplitude spectrum function in the menu > View/Plot Spectrum (FFT): Analysing a simple harmonic I see some > spikes in the amplitude spectrum, where they shouldn't be. They get > bigger extending the resolution of the FFT or using more complicated > analysis windows. > > To reproduce this bug: >  Create a track with a single sine tone: Generate/Tone, Frequency: > 1000, OK >  Select some seconds of the track >  Go to View/Plot Spectrum >  Change settings to: > Spectrum  16384 > Rectangular window  Linear Freq. > > You should see this: http://iem.at/~majdak/temp/spect16384.jpg > > If you change the analysis window to hanning, the situation gets even > worse (in terms of SNR). Look at that: > http://iem.at/~majdak/temp/spect16384hanning.jpg > Decreasing the number of bins to 2048, you still can see the > distortions in spectrum: > http://iem.at/~majdak/temp/spect2048hanning.jpg > > Can anyone confirm this? > > It looks like sloppy cast conversions in the windowing/FFT algorithms > (do you _really_ use float numbers everywhere?) > > > > Piotr Majdak > > PS: OS: Win2000 SP5, Audacity 1.2.2 > > >  > This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 > Project Admins to receive an Apple iPod Mini FREE for your judgement on > who ports your project to Linux PPC the best. Sponsored by IBM. > Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php > _______________________________________________ > Audacitydevel mailing list > Audacitydevel@... > https://lists.sourceforge.net/lists/listinfo/audacitydevel 
From: Piotr Majdak <piotr@ma...>  20040922 09:19:26

Hi Dominic, Dominic Mazzoni wrote: > Piotr, > > I will take a closer look at some point, but my suspicion is the fact > that Audacity is using singleprecision floating point FFT calculations, > with accumulations in doubles in just a few key places. I did a few > brief experiments and discovered that the difference between > singleprecision and doubleprecision FFT is minimal up to 2048; for > 4096 there are occasional deviations but overall it's stable, and beyond > that there are significant deviations. > > Is that consistent with your observations? I haven't tested single vs. double. All I can tell you, is that increasing the FFTlength the distortions get worse. Assuming that the problem is a too small range of numbers, the behaviour should looks like that you found out. (Computing FFT over longer frames, you must build a sum over more samples) > Perhaps we could add a doubleprecision FFT routine and switch to using > that for FFT sizes of 8192 and higher? Then we could allow much larger > FFTs, too, if you're willing to wait. Why not using a doubleprecision FFT at all? I think, the computation time for frames with 8192 samples or less should be in range of single miliseconds. Consequently, performance difference comparing "double" with "single" should be negligible. If it's not, then we have some problems computing FFT ;) (Do you use LAPACK or own libraries?) And, yes: I think audacity is a *great* thing, so I'm willing to wait :) I use audacity with files with 64 channels that are really huge (>5GB). I already have adapted audacity for our purposes, I hope I get round to write you some code changes I made... Piotr Majdak 
From: Dominic Mazzoni <dominic@au...>  20040922 19:01:06

Piotr, > Why not using a doubleprecision FFT at all? I think, the computation > time for frames with 8192 samples or less should be in range of single > miliseconds. Consequently, performance difference comparing "double" > with "single" should be negligible. Audacity shares a single FFT routine throughout its code, including many effects. However many milliseconds, doubleprecision fft is 23x slower than singleprecision, which makes a big difference when doing noise removal, for example. > If it's not, then we have some > problems computing FFT ;) (Do you use LAPACK or own libraries?) We're using our own FFT currently. I'm not aware of an LAPACK FFT library, can you point me to it? The best FFT library I'm aware of is FFTW, but unfortunately the license is not compatible with Audacity's  though both are GPL, the FFTW authors do not agree with linking FFTW to a program that has plugin support. I think there may be another way around this, though: on Linux, we can allow the user to optionally compile with FFTW support, though it wouldn't be required  on Mac OS X we can link to Apple's VecLib, which provides its own optimized FFT routine  and perhaps there is something similar in new versions of Windows? Anyone know? > And, yes: I think audacity is a *great* thing, so I'm willing to wait :) > I use audacity with files with 64 channels that are really huge (>5GB). > I already have adapted audacity for our purposes, I hope I get round to > write you some code changes I made... Great!  Dominic 
From: <xiphmont@xi...>  20040922 20:09:09

I will point out that my own Spectrum Analyzer app is a singleprecision FFT and has no precision problems to a depth of over 140dB. Either this is just a legitimate bug (likely), a very faulty FFT (in terms of noise behavior; possible but less likely), or the data itself really does have those pseudoharmonic distortions in it and the spectral tool isn't lying. Have you checked the waveform in a trusted spectral analyzer? I'll throw mine in SVN now if you don't have any others. Monty 
From: Piotr Majdak <piotr@ma...>  20040923 09:47:39

Hi Monty and Dominic, Monty wrote: > Either this is just a legitimate bug (likely), a very faulty FFT (in > terms of noise behavior; possible but less likely), or the data itself > really does have those pseudoharmonic distortions in it and the > spectral tool isn't lying. > > Have you checked the waveform in a trusted spectral analyzer? I'll > throw mine in SVN now if you don't have any others. Since I've generated the wave form in audacity we either have a problem in Generate/Tone or in View/Plot Spectrum. What I did to check this problem: In Audacity I've generated and saved a sine tone:  Generate/Tone, Frequency: 1000Hz, Amplitude: 0.5  File/Export As WAV... (In Preferences: 16bit PCM) First, let's see the amplitude spectrum in audacity. We must reload the audio track to be sure, that we're goning compare the same audio data in each program:  File/New  File/Open Analysis:  Select a range > 16384 samples  View/Plot Spectrum  Settings: Spectrum, 16384, Rect. window, Lin. Freq  Result: http://iem.at/~majdak/temp/audacity16384.jpg  We see distortions :( Assuming the distortions lie in the audio file, I've used CoolEdit to crosscheck the amplitude spectrum of this tone:  File/Open  Select a sample in the middle of the track  Result: http://iem.at/~majdak/temp/cool16384.jpg  No distortions at all. Ok, we don't trust CoolEdit, do we? Let's try some really proofed method: I used MATLAB (http://www.mathworks.com) to calculate the FFT and then the amplitude spectrum. These basic functions of MATLAB were proofed many times by many scientists worldwide, so we can trust them:  Load WAVFile as a vector: a=wavread('sine.wav');  Plot the amplitude spectrum in dB of the first 16384 samples: plot(20*log10(abs(fft(a(1:16384)))));  Result: http://iem.at/~majdak/temp/matlab16384.png  No distortions at all, so we have a problem with audacity... @Monty, please tell me, if I have done a mistake in my analysis procedure. @Dominic: I think about FFTPACK (http://www.netlib.org/fftpack/) and not LAPACK. There is no FT in LAPACK (http://www.netlib.org/lapack/) :( Piotr Majdak 
From: <xiphmont@xi...>  20040923 16:53:11

On Thu, Sep 23, 2004 at 11:50:49AM +0200, Piotr Majdak wrote: > @Monty, please tell me, if I have done a mistake in my analysis procedure. Nope, looks pretty thorough. We can be pretty sure it is the spectral view in Audacity. > @Dominic: I think about FFTPACK (http://www.netlib.org/fftpack/) and not > LAPACK. There is no FT in LAPACK (http://www.netlib.org/lapack/) :( Dominic: The 'smallft' I gave you a few months back to play with is a partial C implementation of the FFTPACK routine. By 'partial' I mean that it only includes to optimized butterflies for various powers of two. (I think you already knew that, but just in case) BTW, I'm going to have to write an FFTW3like wrapper for it so I can plug it into libpostfish for nonGPL uses. Monty 
Sign up for the SourceForge newsletter:
No, thanks