Audacity Point List

Home (/) / Browse (/directory) / Audacity (/p/audacity/) / Mailing Lists
Audacity (/p/audacity/)
A free multi-track audio editor and recorder
Brought to you by: jamescrook (/u/jamescrook/), martynshaw (/u/martynshaw/), vjohnson (/u/vjohnson/), windinthew (/u/windinthew/)
Re: [Audacity-devel] Plot spectrum function- suggested changes
Re: [Audacity-devel] Plot spectrum function- suggested changes (/p/audacity/mailman/message/34810277/)

From: Bill Unruh <unruh@ph...> - 2016-01-31 22:32:52
Sorry, I disagree with this. The signal has been sampled, that is all the data
we have, and all the data we have to create the frequency domain as well. To
interpolate in either domain implies a belief in the smoothness of the
function that one is interpolating. One might believe this in the time domain,
because the original signal was frequency limited, but in the frequency domain
this does not work. To interpolate one has to extend the time domain somehow.
One can zero pad it, but in general this leads to a non-smooth interpolation
in the frequency domain. Again, the result has no significance, since the
actual signal was almost certainly not one which suddenly dropped to zero
outside the recorded domain. One has the discretely sampled time domain of a
finite length, and thus values in the discrete frequency domain of finite max
frequency. The issue then does become one of display.
Note that IF one were willing to save both the real and imaginary parts of the
FFT (ie both the amplitude and phase) then ways of interpolation could be
found. But then of course display issues become even more difficult.
I certainly agree that a clear description of what one sees in the plot is
good, but I do not think we should be manufacturing data.
In the time domain, audacity plots only the sampled points and then does a
linear interpolation between them (aggregating the points if there are more
than one point per few pixels). I think that the same principle should apply to the
spectrum, but the interpolation should be on the power, not on the dB. The
"many points per pixel" is done now. The "many pixels per point" is the
sticking point now. My first proposal was essentially to do a bar graph, but
to use cos^2 as a rounding proceedure for the bars. I am not so happy with
that now. I think it would be best to do a linear interpolation but on the
power, not the dB. The important thing is to demonstrate that the spectrum as
displayed contains only a finite amount of data. In the time domain, a point
is plotted designating the actual measured value. One could do the same in the
frequency plots-- for example by colouring those vertical stripes one pixel
wide which contain the actual FFT frequency a darker colour than those which
do not to make it clear to the user that those are interpolated, and should
not really be used as data.
The real problem is that the power spectrum is not really stable to further
refinement. You can try zero padding the time domain, taking the fourier
transform, and seeing the way that the new intermediate spectral points have
little relation to the adjacent old ones (ie can differ by 20dB or more) .
I agree that in part this is caused
by the sharp edges of the Rectangular window function, and is not as much a
concern with the other window function. However, the other window function suffer from throwing
away
almost half the information in the data. We leave the decision as to which
window function to use up to the user. We could leave the decision as to
Get latest updates about
which interpolation function to use for the power spectrum up to the user as Open Source Projects,
well.
Conferences and News.
The other item is that whatever is done needs to be fast. To have the user have to wait 10
seconds to display the frequency plot would ensure it never is used. Sign up for the SourceForge
newsletter:
The other complication is the logaritmic plotting possible for the
frequencies. This means that in some parts of the spectrum (low freq ( there
are very many horizonal pixels per FFT frequency, while at high frequencies email@address.com
many FFT per pixel. Ie, in plotting one has to cover both possibilities in the
same graph and decide which to use in each section of the graph. This is not a
Country United Kingdom
problem in the time domain.
On Sun, 31 Jan 2016, Roger Dannenberg wrote:
> Rather than discussing all these graphical and averaging approaches to displaying the
> spectrum, wouldn't it make more sense to compute the frequency-limited value of the spectrum
> at each pixel? In other words, if we zoom in in the time domain, we could resample the signal
> so that there is one sample per pixel, which we could then display (Audacity doesn't actually
> do this.) To display a spectrum, it seems to me we should resample in the frequency domain
> giving a time limited spectrum, just as we would resample in the time domain giving a
No, thanks ()
> frequency limited signal, for time-domain display. Rather than debating what looks good or
> seems right, we could have a principled approach and a clear description of what you are
> seeing in the plot.
>
> -Roger
>
> On 1/30/16 10:08 PM, Bill Unruh wrote:
>
> On Sat, 30 Jan 2016, Paul Licameli wrote:
>
>
>
> On Sat, Jan 30, 2016 at 5:05 PM, Federico Miyara
> <fmiyara@...> wrote:
>
> Bill,
>
> Your work seems very interesting. Some time ago I had reported a
> bug in the
> spectrum plot that may be related to what you have addressed:
> When resizing the
> spectral window, spectral lines went up and down chaotically.
> This is particularly
> the case when representing the spectrum of discrete spectrum
> signals (such as a
> sine wave).
>
>
> I recall that problem Federico found. The discussion is here:
> http://audacity.238276.n2.nabble.com/Spetrum-plot-misbehaviour-tt7568076.html
(http://audacity.238276.n2.nabble.com/Spetrum-plot-misbehaviour-tt7568076.html)
>
> I did not try to fix that, but I then found an analogous problem
> existed in the plotting of
> spectrogram views, which does not share code with the Plot Spectrum
> window besides basic FFT
> calculation.
>
> Just as resizing the width of the plotting window caused the plotted
> peaks to vary -- so too I
> saw that resizing the height spectrogram view of the waveform caused
> the colors of the
> horizontal lines to vary.
>
> The common problem was averaging of the contributions of bins to a
> point on the graph or the
> color of a pixel that corresponded to multiple bins. (The case of
> more bins that pixels -- a
> zoomed-out view along frequency axis.)
>
>
> I think that if one averages the power, rather than the dB it would also help.
> (the power is after
> all what the ear hears-- thus a bunch of power closely spaced in frequency
> will be summed and then dBed (the ear averages over the "critical band" of
> about a minor third)
>
> In that discussion in your above referenced thread, one of my realisations
> that the spectrum is far from a smooth function was precisely to do zero
> padding on a sample. Thus I had a time sample of 4096 points. I then zero
> padded it to double its length (after I had gotten rid of the overlapping
> window spectra that audacity now uses)and took a 8192 point spectrum.
> The spectrum became much more jagged Open Source Projects,
> (holes and occasionally mountains of 10-20dB appeared). If I doubled again and
> did 16K FFT and again more holes appeared. Ie, the spectrum simply is not a Conferences and News.
> smooth function of the time series.
> Sign up for the SourceForge
> In the patch I submitted, I used a cos^2 interpolation of the power (not the newsletter:
> dB) for the case where there are many pixel bins in one FFT bin. I have realised
> that this is really a rounded "bar graph" of the spectral
> power. I am now tending toward using linear interpolation of the power email@address.com
> instead. This gives a "spikier" graph, but it is probably a more accurate
> representation of what the FFT gives us.
>
>
> Note with respect to the averaging of the power, not the dB in a pixel bin
> (when many fft bins are in one pixel bin) the power represented seems to be
> quite stable. If I expand the spectrum window horizontally, the peaks do not
> bounce
> around anymore. And if I increase the resolution by zero padding, again the
> spectrum does not change much if there are many FFT bins per pixel bin. (By going
> to logarithmic scale, the low frequencies are in the "many pixel
> bins per fft bin" while the high frequencies are in the "many fft bins per
> pixel bin" There the low frequencies develop holes, but the high frequencies
No, thanks ()
> are quite stable when the resolution is changed.
>
> .
>
> An acceptable solution for spectrogram view was simpler than for the
> graph. I simply took
> maximum instead of average.
>
> PRL
>
>
>
> The quadratic peak finding makes much sense, since most if not
> all windowing
> functions have a (bilateral) spectrum with a symmetric lobe
> (often coming from a
> sinc function) that is well approximated by a parabola.
>
> As to zooming the spectrum, there is an approach called "zoom
> FFT" that may be
> traced back to the tuning system of a traditional radio
> receiver. The zoomed
> region is spectrally shifted towards the "base band" by
> multiplying it by a "local
> intermediate frequency oscillator" (actually exp(-jwt)), then it
> is low-pass
> filtered, downsampled (this is precisely to reduce the FFT size
> needed to get more
> resolution, since resolution is obtained as Fs/N) and finally
> the FFT is
> performed.
>
> The smoothness of the spectrum is not completely meaningless if
> it is long-term
> (the energy average of many spectra, since it tends to represent
> the spectral
> power density)
>
> Regards,
>
> Federico
>
>
>
> On 30/01/2016 16:30, Bill Unruh wrote:
>
>
> The one other that would be really useful would be to be able to
> zoom in on
> the frequency axis, just like we can now Zoom in on the time
> axis. This is
> clearly a bigger job, and my knowledge of wx (and of the details
> of the
> spectrum plot function) have kept me from trying this. When we
> zoom in so
> that the interpolation has to be used, or at the low frequencies
> when using
> logarithmic axis, the individual points at which the FFT is
> calculated begin to be plotted, just as is now done for the time
> series when
> one zooms in.
> The problem with the smoothing, either the old cubic
> interpolation, or my Open Source Projects,
> cos^2 is that the user gets the feeling that the
> value of the spectrum at the intermediate points means Conferences and News.
> something, since the
> spectrum looks smooth (which is one reason I have sometimes felt Sign up for the SourceForge
> that simply newsletter:
> doing linear interpolation on the power, so you can see the
> jaggedness of
> the email@address.com
> spectrum and don't get fooled that the smoothness means
> something).
>
> But I am torn. Certainly a smoother curve looks better, even if
> it is not
> very
> significant.
>
> On Sat, 30 Jan 2016, James Crook wrote:
>
> Bill, this is fantastic.
>
> Thank you very much indeed, not only for doing the work to
No, thanks ()
> fix
> it but also for the very clear
> explanations of why.
> Besides point 5, are there other enhancements to the
> spectrum
> plot that would be useful for
> your use case.
>
> --James.
>
>
>
> On 30/01/2016 05:42, Bill Unruh wrote:
> I have been looking at the Analyze->PlotFrequency
> function. I have enclosed patch
> files with a number of changes.
>
> 1) If one is using the Rectangular window function,
> I have
> changed the overlap
> to zero, instead of half. As a test for the problems
> with
> the current overlap,
> set the Project Rate to 8000, and Generate a Chirp
> from
> 400Hz to 800Hz over 2
> sec. Select the whole time. Now go PlotSpectrum and
> choose
> 8192 as Size:
> The spectrum will have the center of the spectrum
> 3dB
> higher than the
> sides. The spectrum should be flat. This is not as
> crucial
> for the
> non-rectangular window functions.
>
> 2)A spectrum is not a smooth function, and thus
> both the
> cubic
> interpolation and the cubic peak finding really make
> no
> sense. I have replaced
> the cubic peak finding with a quandratic one, which
> one
> might be able to
> defend. To illustrate the problem with the cubic
> peak
> finding, set up Rate of
> 8000,
> and Generate a Sine Tone of 312.5Hz and amplitude
> of .8 .
> The spectrum will now
> be a single peak with a single non-zero value at
> 312.5 Hz
> and height -1.9dB. The
> cubic peak
> finder will however find a peak at less than that
> frequency (depending on the
> Size) and height +14dB This value is out by almost
> 20dB
> from the true peak.
> Open Source Projects,
> The other problem is that the dB is simply a way of
> plotting the power. It is Conferences and News.
> the power that is important in the spectrum not the
> dB. Sign up for the SourceForge
> Thus the peak finding newsletter:
> should operate on the power not the dB.
>
> 3. If the number of FFT bins in one pixel bin is email@address.com
> more than
> one, then then
> averaging the dB in the pixel bin makes no sense. It
> should be averaging the
> power over the FFT bins in that pixel bin. I have
> changed
> the Spectrum
> function to do the power averaging rather then the
> dB for
> the case when there is
> more
> than one FFT bin per pixel bin. (The display of
> course is
No, thanks ()
> turned back into dB
> for plotting).
>
> 4. Similarly for the case where the FFT bins are
> bigger
> than the pixel bins,
> where now cubic interpolation is done, this
> interpolation
> is also arguably wrong.
> Again, use the above
> 312.5 Hz signal. and use a FFT Size of 512. Now drag
> the
> edges of the spectrum
> display window larger.
> The height of the single peak will vary by Huge
> amounts as
> you do this (up to
> and over 90dB.) This
> is because of the cubic interpolation of the
> spectrum
> (between -1.9dB at
> the one point and -200dB (noise floor) at adjacent
> points), produces wrong
> results. The peak power should stay at -1.9dB no
> matter
> what the size of the
> window.
>
>
> The problem is that one cannot do cubic
> interpolation on
> the power instead of
> the dB
> since that produceis negative
> powers, which, when converted to dB, would give
> imaginary
> dB. Doing cubic
> interpolation on the cos, and sin components of the
> FFT
> could
> work, but would require that the program worked on
> the
> complex amplitude of
> the FFT. And because of the non-analytic behaviour
> of the
> fourier transform it
> is not clear this would be worth anything anyway.
>
>
> Because the spectrum is not, as I stated above, a
> smooth
> function anyway, the
> best estimate is really the FFT value at the points
> at
> which it is calculated. But
> a point spectrum is hard to see. I have thus
> implimented a
> Cos squared
> interpolation. Ie, if you are at freq f between two
> frequencies f1 f2 at which the
> FFT
> is calculated, I use Power(f)= Power(f1)
> cos^2(pi/4(f-f1)/(f2-f1)) + Power(f2) Open Source Projects,
> cos^2( pi/4(f-f2)/(f1-f2)) . If the Power(f1) and
> Power(f2) are the same, then Conferences and News.
> interpolation is simply a horizonal straight line
> joining Sign up for the SourceForge
> them. And if f=f1, newsletter:
> the power is the FFT calculated power.
>
> Then after the power interpolation is calculated, it email@address.com
> is
> converted back to dB
> to plot it.
>
> 5. It would be nice to have the frequency delta-f
> displayed (Rate/Size) to
> make it clear that the spectrum is really only
> accurate
> over that frequency
> span. Unfotunately I really do not understant wx
> well
> enough to be able to do
> that myself.
No, thanks ()
>
>
> The enclosed patches for FreqWindow.cpp and
> FreqWindow.h
> implement the first
> four of the above.
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application
> Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just
> $35/Month
> Monitor end-to-end web transactions and take corrective
> actions
> now
> Troubleshoot faster and improve end-user experience.
> Signup Now!
>
>
>
>
> _______________________________________________
> audacity-devel mailing list
> audacity-devel@...
>
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
(https://lists.sourceforge.net/lists/listinfo/audacity-devel)
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
>
>
>
> _______________________________________________
>
>
>
> ------------------------------------------------------------------------------
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
>
> _______________________________________________
> Open Source Projects,
>
> Conferences and News.
>
> Sign up for the SourceForge
> newsletter:
> ------------------------------------------------------------------------------
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month email@address.com
>
>
>
> _______________________________________________
>
>
>
No, thanks ()
View entire thread (/p/audacity/mailman/audacity-
devel/thread/alpine.LMD.2.03.1601310957060.27651%40physics.ubc.ca/#msg34810277)
SourceForge Find and Develop Software Community Help
About (/about) Create a Project (/create/) Blog (/blog/) Site Documentation

Site Status Software Directory (/directory/) @sourceforge (http://p.sf.net/sourceforge/docs)
(/blog/category/sitestatus/) Top Downloaded Projects (http://twitter.com/sourceforge) Support Request (/support)
@sfnet_ops (/top) Resources
(http://twitter.com/sfnet_ops) (https://library.slashdotmedia.com/)
Powered by
Apache Allura
(http://allura.apache.org/)
2017 Slashdot Media. All Rights Reserved. Terms (http://slashdotmedia.com/terms-of-use) Privacy (http://slashdotmedia.com/privacy-statement/) Cookie
Preferences () Opt Out Choices (http://slashdotmedia.com/opt-out-choices) Advertise
(http://slashdotmedia.com)
Subscribe
I agree to receive quotes, newsletters and other

information from sourceforge.net and its partners
regarding IT services and products. I understand that I
can withdraw my consent at any time. Please refer to
our Privacy Policy (https://slashdotmedia.com/privacy-
statement/) or Contact Us (/support) for more details

Open Source Projects,
Conferences and News.
Sign up for the SourceForge
newsletter:
email@address.com
No, thanks ()

Audacity Point List

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Audacity Point List

Transféré par

Droits d'auteur :

Formats disponibles

Home (/) / Browse (/directory) / Audacity (/p/audacity/) / Mailing Lists

Re: [Audacity-devel] Plot spectrum function- suggested changes

Re: [Audacity-devel] Plot spectrum function- suggested changes (/p/audacity/mailman/message/34810277/)

On Sun, 31 Jan 2016, Roger Dannenberg wrote:

SourceForge Find and Develop Software Community Help

About (/about) Create a Project (/create/) Blog (/blog/) Site Documentation

I agree to receive quotes, newsletters and other

Get latest updates about

Country United Kingdom

Vous aimerez peut-être aussi