Spectrogram problems
Norm C <n_badger42 <at> hotmail.com>
2012-02-02 06:12:02 GMT
I've found three bugs in the spectral display, and the attached patch fixes
all of them. They are:
- if EXPERIMENTAL_USE_REALFFTF is not defined, then PowerSpectrum calculates
the DC power incorrectly, by adding together the squares of the (correct) DC
value and the Nyquist value. To verify this:
- build without EXPERIMENTAL_USE_REALFFTF
- generate a 5 second tone at 21900 Hz, amplitude 0.5 (with 44100 Hz
sample rate)
- view as spectrogram (with window size at 256)
- observe that the bottom frequencies (0 to about 200 Hz) display in a
colour that indicates substantial power
- rebuild with EXPERIMENTAL_USE_REALFFTF and repeat
- observe that the bottom frequencies now indicate no power there, as you
would expect
- in addition, it's clear from Numerical Recipes in C (from which the
source code for the FFT was derived) that the DC
bin is found in data(1) of the result (our variable rt), and the
Nyquist bin is found in data(2) of the result (our
variable it). (See pg 513 of ver 2 of the book). "it" should not be
used for calculation of the DC value. Furthermore
Goldwave displays zero power in the DC bin under the same conditions
(CEPro doesn't; it appears to have this same bug)
- in Spectrum.cpp a check is made for temp > 0 before taking the log10 to
turn it into dB. But if temp is 0 (or -ve) then
the value used is 0 dB, which is clearly wrong - it should be a large
negative number (I've used -300 dB here)
- the alignment of the spectrogram's bins and the frequency axis is wrong,
by half a bin width. Here's how to verify the problem:
- generate a sine wave, frequency 280 Hz, duration 5 seconds
- set Spectrogram preferences to a window size of 1024, Hann window
- select the entire track and do a Analyze-Plot Spectrum
- set the Algorithm to Spectrum, the Size to 1024, the Function to Hann
window, the Axis to Log Frequency
- observe that the peak is very close to 280 Hz (correct)
- cancel the Frequency Analysis and return to the main window, select
Spectrogram in the track's dropdown menu
- observe that the peak (lightest colour) appears to be at about 300 Hz.
This is in error by one half a bin (44100/1024/2)
(See the attached images for clarification)
SpectrogramFix_Spectrogram(fixed)HF.png The reason for this error is that
although the bin width is 44100/1024 (43 Hz), the first bin is displayed as
extending from 0 to 43 Hz when in fact it represents frequencies from -21.5
Hz to 21.5 Hz (that is, DC is at the *centre* of the bin). The second bin
represents frequencies from 21.5 Hz to 64.5 Hz, and so on. Lending support
to this argument is that fact that the "Nyquist" bin (the 513th bin when the
FFT size is 1024) is not displayed at all on the spectrogram (it would be
positioned completely *above* 22050 Hz).
Note that some other DAWs do display spectrograms the same way as Audacity
currently does. However there is support for displaying the DC bin and the
Nyquist bin with half the height of the others. See, for instance,
http://www.vlf.it/fft_beginners/fft_beginners.html : "the <bin> containing
the lowest frequency, has only half the width of all other bins. From the
example above, the 1st bin covers 0.000 Hz ... 21.5 Hz."
My patch does not display the (half-width) Nyquist bin at the top of the
spectrum, however. To do so would require that the various FFT functions
would have to be modified to output FFT_Size/2+1 output values (currently
they output FFT_Size/2 values) and this interface change would affect other
modules that use the FFTs (probably too risky right now). Instead the
highest bin that we have is now displayed 1.5 times as wide as it should be.
This is probably acceptable since in most cases the "action" is all down in
the lower frequencies, and rarely right at Nyquist.
One other point: my patch includes my earlier proposed change from "Hanning"
to "Hann". I kept that in my code tree because I believe it is the best
thing (to minimize user confusion with Hamming, among other reasons) but
feel free to nuke that part of the patch if it is too close to 2.0 time for
something controversial.
Norm
http://audacity.238276.n2.nabble.com/file/n7245898/SpectrumFixes.patch
SpectrumFixes.patch
http://audacity.238276.n2.nabble.com/file/n7245898/SpectrogramFix_FreqAnalysis.png
SpectrogramFix_FreqAnalysis.png
http://audacity.238276.n2.nabble.com/file/n7245898/SpectrogramFix_Spectrogram%28wrong%29.png
SpectrogramFix_Spectrogram(wrong).png
http://audacity.238276.n2.nabble.com/file/n7245898/SpectrogramFix_Spectrogram%28fixed%29.png
SpectrogramFix_Spectrogram(fixed).png
http://audacity.238276.n2.nabble.com/file/n7245898/SpectrogramFix_Spectrogram%28fixed%29HF.png
--
View this message in context: http://audacity.238276.n2.nabble.com/Spectrogram-problems-tp7245898p7245898.html
Sent from the audacity-devel mailing list archive at Nabble.com.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
RSS Feed