Audacity › audacity-devel

Re: Question about spectral analysis in Audacity

Classic

List

Threaded

14 messages Options

Gale

Re: Question about spectral analysis in Audacity

Administrator

Martyn Shaw wrote:

>
> Julien
>
> I have implemented a 'convolve' effect in Audacity here (but I never
> put all the 'bells and whistles' in to finish it off). However it is
> usable for basic benchmarking the speed of an fft. I used fftw3.
>
> Convolving 2 60s samples takes about 9-10s here. This involves taking
> an FFT of 60*2*44100 samples, doing the complex multiplications,
> taking the inverse transform and then normalising. That's equivalent
> to FFTing a 2 minute, 44100Hz sampled signal in less than 3s.
>
> http://www.fftw.org/ is open source and not too difficult to get going
> with Audacity (I managed it!). If you want to use 'long' FFT lengths
> then I think it's the way to go. Just a POV.

I noticed we now analyze up to the first 237.8 seconds of audio in 1.3.8
(must have missed that someplace). On my XP box (2.6 GHz 1 GB RAM)
if I select that much or longer it takes 10 -18 seconds before anything
happens. If the audio is over 237.8, the "anything" is the length warning,
after which the Spectrum displays at once.

Should this be progress dialogued? And maybe the selected length
calculated and the warning thrown before starting the calculation?

Gale

> Michael Chinen wrote:
> Are you trying to take THE spectrum of a 60 second segment (with one
> FFT,) or are you interested in finding the average spectrum by taking
> many small FFTs over the duration and averaging it out? These may
> yield similar results but the process is very different.
>
> You probably know this, but I just want to point out that in O(n log
> n), n is in samples, not seconds, so each second adds a big factor to
> the running time of the algorithm. I would be willing to bet you
> aren't going to be able to finish a FFT of size 44100*60 for a very
> long time.
>
> The Plot Spectrum command appears to take many small ones and average
> them, since you can select the FFT size in the popup window, with a
> maximum of 16384. If that's the case I'm not sure why it has a 24
> second limit either.
>
>
> Michael
>
>
>
> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]> wrote:
>>> Computing the spectrum requires all samples to be in memory at once
>>> and costs n*log(n), so operating on many seconds of sound is unusual.
>>> If the spectrum is very stable, e.g. a steady tone, then you probably
>>> don't need to look at many seconds to extract the spectral
>>> information. If the spectrum is changing, then grabbing the spectrum
>>> of a large interval is in some sense going to smear out or average the
>>> overall energy, so again, it's not so useful. Finally, there are
>>> numerical issues to worry about when doing a very large Fourier
>>> transform to compute the spectrum. What might be useful is to compute
>>> a sequence of short-term spectra and average their magnitudes to get a
>>> long-term average spectrum. Audacity could do this in principle, but
>>> the user would have to provide more parameters and confirm that he/she
>>> really wants to do an expensive computation on a long segment of audio.
>> Alright. So if I understand well, there is no hidden reason to forbid
>> spectral analysis on
>> a larger sample. O(n log n) is a very reasonable complexity for a
>> fourier transform and
>> I am ready to wait some more seconds to compute the spectrum for 60
>> seconds instead
>> of 24 seconds. I will modify the audacity source code for my own needs
>> in that direction.
>>
>> Thanks for your quick answer
>>
>> Julien

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Question about spectral analysis in Audacity

[hidden email] wrote:

> Martyn Shaw wrote:
>> Julien
>>
>> I have implemented a 'convolve' effect in Audacity here (but I never
>> put all the 'bells and whistles' in to finish it off). However it is
>> usable for basic benchmarking the speed of an fft. I used fftw3.
>>
>> Convolving 2 60s samples takes about 9-10s here. This involves taking
>> an FFT of 60*2*44100 samples, doing the complex multiplications,
>> taking the inverse transform and then normalising. That's equivalent
>> to FFTing a 2 minute, 44100Hz sampled signal in less than 3s.
>>
>> http://www.fftw.org/ is open source and not too difficult to get going
>> with Audacity (I managed it!). If you want to use 'long' FFT lengths
>> then I think it's the way to go. Just a POV.

The above is more than likely irrelevant to Gale's comment.

> I noticed we now analyze up to the first 237.8 seconds of audio in 1.3.8
> (must have missed that someplace).

I did that back on Tue Feb 24 23:12:18 2009 UTC
http://audacity.cvs.sourceforge.net/viewvc/audacity/audacity-src/src/FreqWindow.cpp?r1=1.65&r2=1.66&sortby=date

but managed to post this to myself only, doh! The audacity-cvs
message is there however.

================
Further improvements...

We now have a tick-box to turn the grids on and off.
All the parameters are stored in prefs.
I have increased the length of audio that can be analysed by a (rather
arbitrary) factor of 10, I don't see why it shouldn't be higher, other
than processing time.
The scale of 'Spectrum' stays the same as you change the 'Size'
parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
refers). I didn't adjust the others as I'm not sure what they do and
if they are 'right' or 'wrong'.

TTFN
Martyn
================

and got no responses (no, really Martyn? Try mailing others as well
as yourself!)!

On my XP box (2.6 GHz 1 GB RAM)
> if I select that much or longer it takes 10 -18 seconds before anything
> happens. If the audio is over 237.8, the "anything" is the length warning,
> after which the Spectrum displays at once.

'tis less than a second here (for a 1hr 15s file). I get the warning,
then the spectrum, as anticipated.

Are you still seeing this?

Martyn

> Should this be progress dialogued? And maybe the selected length
> calculated and the warning thrown before starting the calculation?
>
>
>
>
> Gale
>
>
>
>> Michael Chinen wrote:
>> Are you trying to take THE spectrum of a 60 second segment (with one
>> FFT,) or are you interested in finding the average spectrum by taking
>> many small FFTs over the duration and averaging it out? These may
>> yield similar results but the process is very different.
>>
>> You probably know this, but I just want to point out that in O(n log
>> n), n is in samples, not seconds, so each second adds a big factor to
>> the running time of the algorithm. I would be willing to bet you
>> aren't going to be able to finish a FFT of size 44100*60 for a very
>> long time.
>>
>> The Plot Spectrum command appears to take many small ones and average
>> them, since you can select the FFT size in the popup window, with a
>> maximum of 16384. If that's the case I'm not sure why it has a 24
>> second limit either.
>>
>>
>> Michael
>>
>>
>>
>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]> wrote:
>>>> Computing the spectrum requires all samples to be in memory at once
>>>> and costs n*log(n), so operating on many seconds of sound is unusual.
>>>> If the spectrum is very stable, e.g. a steady tone, then you probably
>>>> don't need to look at many seconds to extract the spectral
>>>> information. If the spectrum is changing, then grabbing the spectrum
>>>> of a large interval is in some sense going to smear out or average the
>>>> overall energy, so again, it's not so useful. Finally, there are
>>>> numerical issues to worry about when doing a very large Fourier
>>>> transform to compute the spectrum. What might be useful is to compute
>>>> a sequence of short-term spectra and average their magnitudes to get a
>>>> long-term average spectrum. Audacity could do this in principle, but
>>>> the user would have to provide more parameters and confirm that he/she
>>>> really wants to do an expensive computation on a long segment of audio.
>>> Alright. So if I understand well, there is no hidden reason to forbid
>>> spectral analysis on
>>> a larger sample. O(n log n) is a very reasonable complexity for a
>>> fourier transform and
>>> I am ready to wait some more seconds to compute the spectrum for 60
>>> seconds instead
>>> of 24 seconds. I will modify the audacity source code for my own needs
>>> in that direction.
>>>
>>> Thanks for your quick answer
>>>
>>> Julien
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Gale

Re: Question about spectral analysis in Audacity

Administrator

| From Martyn Shaw <[hidden email]>
| Wed, 01 Jul 2009 01:47:37 +0100
| Subject: [Audacity-devel] Question about spectral analysis in Audacity
> [hidden email] wrote:
> > I noticed we now analyze up to the first 237.8 seconds of audio in 1.3.8
> > (must have missed that someplace).
>
> I did that back on Tue Feb 24 23:12:18 2009 UTC
> http://audacity.cvs.sourceforge.net/viewvc/audacity/audacity-src/src/FreqWindow.cpp?r1=1.65&r2=1.66&sortby=date
>
> but managed to post this to myself only, doh! The audacity-cvs
> message is there however.

Thanks, Martyn. I saw the CVS message but didn't pick up the
significance of the "increase possible audio length", sorry.

> The scale of 'Spectrum' stays the same as you change the 'Size'
> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
> refers). I didn't adjust the others as I'm not sure what they do and
> if they are 'right' or 'wrong'

Adobe9 does not seem capable of opening that PDF here (missing
components) so can you explain what you mean for the stupid (me)?
If I change size from 128 to 16384 the increments of both scales
change (except that for frequency, if I use the linear option). And if
I look at a particular peak, the dB value is much lower with the
largest size (is that expected)?

Did you make progress trying to make the dB values displayed more
like those in 1.2.6 where the low frequencies are close to -0 dB?
Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
shows about -30 dB less in 1.3.8. Have we got a good explanation
when we are asked about this?

> > On my XP box (2.6 GHz 1 GB RAM)
> > if I select that much or longer it takes 10 -18 seconds before anything
> > happens. If the audio is over 237.8, the "anything" is the length warning,
> > after which the Spectrum displays at once.
>
> 'tis less than a second here (for a 1hr 15s file). I get the warning,
> then the spectrum, as anticipated.
>
> Are you still seeing this?

No, not in my recent ANSI build using wx 2.8.10. The wait is about
3 - 5 seconds for an hour long file (FF is running as it was before and
it has about 40 tabs open as usual, but if I had the upcoming local
Manual open, FF would have to be running anyway). I got the results
I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
that was both with the XP machine several hours after boot and on a
fresh boot (made no difference). Is that Windows variability again?
I will try on the Vista machine too.

But anyway, wouldn't you suppose on slow machines with little RAM
that the waiting time would exceed that where we usually give an .
effect progress dialogue? Our nominal minimum system requirements
for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.

Also I've found what seems to be un-necessary window-switching
behaviour (is in 1.3.7 as well):

1. Open Audacity and generate a tone
2. Plot Spectrum (close it or leave it open)
3. File > New (you will have to task switch or click on the
correct section of the Taskbar button to see the new
window, due to another bug we have)
4. Import an audio file (because easy to see the difference)
5. Plot Spectrum and it appears with the plot of the audio
file, but the window switches to that for the tone, which
is confusing.

Thanks

Gale

> >> Michael Chinen wrote:
> >> Are you trying to take THE spectrum of a 60 second segment (with one
> >> FFT,) or are you interested in finding the average spectrum by taking
> >> many small FFTs over the duration and averaging it out? These may
> >> yield similar results but the process is very different.
> >>
> >> You probably know this, but I just want to point out that in O(n log
> >> n), n is in samples, not seconds, so each second adds a big factor to
> >> the running time of the algorithm. I would be willing to bet you
> >> aren't going to be able to finish a FFT of size 44100*60 for a very
> >> long time.
> >>
> >> The Plot Spectrum command appears to take many small ones and average
> >> them, since you can select the FFT size in the popup window, with a
> >> maximum of 16384. If that's the case I'm not sure why it has a 24
> >> second limit either.
> >>
> >>
> >> Michael
> >>
> >>
> >>
> >> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]> wrote:
> >>>> Computing the spectrum requires all samples to be in memory at once
> >>>> and costs n*log(n), so operating on many seconds of sound is unusual.
> >>>> If the spectrum is very stable, e.g. a steady tone, then you probably
> >>>> don't need to look at many seconds to extract the spectral
> >>>> information. If the spectrum is changing, then grabbing the spectrum
> >>>> of a large interval is in some sense going to smear out or average the
> >>>> overall energy, so again, it's not so useful. Finally, there are
> >>>> numerical issues to worry about when doing a very large Fourier
> >>>> transform to compute the spectrum. What might be useful is to compute
> >>>> a sequence of short-term spectra and average their magnitudes to get a
> >>>> long-term average spectrum. Audacity could do this in principle, but
> >>>> the user would have to provide more parameters and confirm that he/she
> >>>> really wants to do an expensive computation on a long segment of audio.
> >>> Alright. So if I understand well, there is no hidden reason to forbid
> >>> spectral analysis on
> >>> a larger sample. O(n log n) is a very reasonable complexity for a
> >>> fourier transform and
> >>> I am ready to wait some more seconds to compute the spectrum for 60
> >>> seconds instead
> >>> of 24 seconds. I will modify the audacity source code for my own needs
> >>> in that direction.
> >>>
> >>> Thanks for your quick answer
> >>>
> >>> Julien
> >
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Question about spectral analysis in Audacity

Gale Andrews wrote:
> | From Martyn Shaw <[hidden email]>
> | Wed, 01 Jul 2009 01:47:37 +0100
...
>> The scale of 'Spectrum' stays the same as you change the 'Size'
>> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
>> refers). I didn't adjust the others as I'm not sure what they do and
>> if they are 'right' or 'wrong'
>
> Adobe9 does not seem capable of opening that PDF here (missing
> components) so can you explain what you mean for the stupid (me)?

I never did like pdf files. Suggest that you get a reader capable of
opening it, or get the rest of the components you need. Works fine
here in Adobe Reader 8.0. The book is excellent, if technical.

I'll try in two sentences, but this isn't the place for a long
explanation:
If you generate a sine wave and look at it's amplitude with different
window lengths, you'll get about the same value since it 'always'
falls in one frequency bin. If you have a random signal then you can
expect the amplitude to fall by 3dB for every doubling of the FFT
size, since the bins are half the size and so contain only half the
energy.

> If I change size from 128 to 16384 the increments of both scales
> change (except that for frequency, if I use the linear option).

Again related to the size of the bins. More bins, greater resolution.

And if
> I look at a particular peak, the dB value is much lower with the
> largest size (is that expected)?

Depends on signal, see above.

> Did you make progress trying to make the dB values displayed more
> like those in 1.2.6 where the low frequencies are close to -0 dB?
> Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
> shows about -30 dB less in 1.3.8. Have we got a good explanation
> when we are asked about this?

Normalisation. Read the book.

>>> On my XP box (2.6 GHz 1 GB RAM)
>>> if I select that much or longer it takes 10 -18 seconds before anything
>>> happens. If the audio is over 237.8, the "anything" is the length warning,
>>> after which the Spectrum displays at once.
>> 'tis less than a second here (for a 1hr 15s file). I get the warning,
>> then the spectrum, as anticipated.
>>
>> Are you still seeing this?
>
> No, not in my recent ANSI build using wx 2.8.10. The wait is about
> 3 - 5 seconds for an hour long file (FF is running as it was before and
> it has about 40 tabs open as usual, but if I had the upcoming local
> Manual open, FF would have to be running anyway). I got the results
> I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
> that was both with the XP machine several hours after boot and on a
> fresh boot (made no difference). Is that Windows variability again?
> I will try on the Vista machine too.
>
> But anyway, wouldn't you suppose on slow machines with little RAM
> that the waiting time would exceed that where we usually give an .
> effect progress dialogue? Our nominal minimum system requirements
> for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.

We should up that, perhaps. A progress dialogue would be good, but
low priority (for me at least).

> Also I've found what seems to be un-necessary window-switching
> behaviour (is in 1.3.7 as well):
>
> 1. Open Audacity and generate a tone
> 2. Plot Spectrum (close it or leave it open)
> 3. File > New (you will have to task switch or click on the
> correct section of the Taskbar button to see the new
> window, due to another bug we have)
> 4. Import an audio file (because easy to see the difference)
> 5. Plot Spectrum and it appears with the plot of the audio
> file, but the window switches to that for the tone, which
> is confusing.

So it does. I guess these are both on Release_Checklist for our
students to take a hit at?

TTFN
Martyn

> Thanks
>
>
> Gale
>
>
>>>> Michael Chinen wrote:
>>>> Are you trying to take THE spectrum of a 60 second segment (with one
>>>> FFT,) or are you interested in finding the average spectrum by taking
>>>> many small FFTs over the duration and averaging it out? These may
>>>> yield similar results but the process is very different.
>>>>
>>>> You probably know this, but I just want to point out that in O(n log
>>>> n), n is in samples, not seconds, so each second adds a big factor to
>>>> the running time of the algorithm. I would be willing to bet you
>>>> aren't going to be able to finish a FFT of size 44100*60 for a very
>>>> long time.
>>>>
>>>> The Plot Spectrum command appears to take many small ones and average
>>>> them, since you can select the FFT size in the popup window, with a
>>>> maximum of 16384. If that's the case I'm not sure why it has a 24
>>>> second limit either.
>>>>
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]> wrote:
>>>>>> Computing the spectrum requires all samples to be in memory at once
>>>>>> and costs n*log(n), so operating on many seconds of sound is unusual.
>>>>>> If the spectrum is very stable, e.g. a steady tone, then you probably
>>>>>> don't need to look at many seconds to extract the spectral
>>>>>> information. If the spectrum is changing, then grabbing the spectrum
>>>>>> of a large interval is in some sense going to smear out or average the
>>>>>> overall energy, so again, it's not so useful. Finally, there are
>>>>>> numerical issues to worry about when doing a very large Fourier
>>>>>> transform to compute the spectrum. What might be useful is to compute
>>>>>> a sequence of short-term spectra and average their magnitudes to get a
>>>>>> long-term average spectrum. Audacity could do this in principle, but
>>>>>> the user would have to provide more parameters and confirm that he/she
>>>>>> really wants to do an expensive computation on a long segment of audio.
>>>>> Alright. So if I understand well, there is no hidden reason to forbid
>>>>> spectral analysis on
>>>>> a larger sample. O(n log n) is a very reasonable complexity for a
>>>>> fourier transform and
>>>>> I am ready to wait some more seconds to compute the spectrum for 60
>>>>> seconds instead
>>>>> of 24 seconds. I will modify the audacity source code for my own needs
>>>>> in that direction.
>>>>>
>>>>> Thanks for your quick answer
>>>>>
>>>>> Julien
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Gale

Re: Question about spectral analysis in Audacity

Administrator

| From Martyn Shaw <[hidden email]>
| Wed, 01 Jul 2009 23:37:39 +0100
| Subject: [Audacity-devel] Question about spectral analysis in Audacity

> Gale Andrews wrote:
> > | From Martyn Shaw <[hidden email]>
> > | Wed, 01 Jul 2009 01:47:37 +0100
> ...
> >> The scale of 'Spectrum' stays the same as you change the 'Size'
> >> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
> >> refers). I didn't adjust the others as I'm not sure what they do and
> >> if they are 'right' or 'wrong'
> >
> > Adobe9 does not seem capable of opening that PDF here (missing
> > components) so can you explain what you mean for the stupid (me)?
>
> I never did like pdf files. Suggest that you get a reader capable of
> opening it, or get the rest of the components you need. Works fine
> here in Adobe Reader 8.0. The book is excellent, if technical.

Hi Martyn

All the PDFs from that site fail here - tried Foxit too. One of the
PDF's gave an explicit error that you have to subscribe (pay money).
Are you sure that isn't the problem?

> I'll try in two sentences, but this isn't the place for a long
> explanation:
>
> If you generate a sine wave and look at its amplitude with different
> window lengths, you'll get about the same value since it 'always'
> falls in one frequency bin. If you have a random signal then you can
> expect the amplitude to fall by 3dB for every doubling of the FFT
> size, since the bins are half the size and so contain only half the
> energy.
>
> > If I change size from 128 to 16384 the increments of both scales
> > change (except that for frequency, if I use the linear option).
>
> Again related to the size of the bins. More bins, greater resolution.
>
> > And if I look at a particular peak, the dB value is much lower with the
> > largest size (is that expected)?
>
> Depends on signal, see above.

Thanks. I was looking at a short bit of "real music", but your "bins"
explanation makes sense, and I can see with Generate > Tone: Sine
(default settings) that the increments on the dB scale don't change
with larger size, nor do the amplitudes of the peaks to any great .
extent.

> > Did you make progress trying to make the dB values displayed more
> > like those in 1.2.6 where the low frequencies are close to -0 dB?
> > Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
> > shows about -30 dB less in 1.3.8. Have we got a good explanation
> > when we are asked about this?
>
> Normalisation. Read the book.

Obviously I can't read the book I'm afraid, but I note you proposed on
April 17th:
http://n2.nabble.com/Freq-Window-vertical-scales-td2649299.html#a2649299

" 'A sinusoid of amplitude 1.0 gives 0dB for all windows and FFT sizes'

...(not that I know how to do that, but it can be an 'aim')
(and probably I should add 'within a dB'). "

Well we seem to be at about -6 dB at the moment.

I'll try and read up a bit somewhere, but if you mean we normalised
before so that the highest point of the scale for "real music" was
around 0 dB, and now we don't (so that typically it's now about
-30 dB at default window size), I'm suggesting there may be some
"consumer resistance" or "misunderstanding" (already voiced). :=)

But if what we have now is really "less misleading" than before, we
should educate them with a succinct sentence in the Manual.

> >>> On my XP box (2.6 GHz 1 GB RAM)
> >>> if I select that much or longer it takes 10 -18 seconds before anything
> >>> happens. If the audio is over 237.8, the "anything" is the length warning,
> >>> after which the Spectrum displays at once.
> >> 'tis less than a second here (for a 1hr 15s file). I get the warning,
> >> then the spectrum, as anticipated.
> >>
> >> Are you still seeing this?
> >
> > No, not in my recent ANSI build using wx 2.8.10. The wait is about
> > 3 - 5 seconds for an hour long file (FF is running as it was before and
> > it has about 40 tabs open as usual, but if I had the upcoming local
> > Manual open, FF would have to be running anyway). I got the results
> > I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
> > that was both with the XP machine several hours after boot and on a
> > fresh boot (made no difference). Is that Windows variability again?
> > I will try on the Vista machine too.
> >
> > But anyway, wouldn't you suppose on slow machines with little RAM
> > that the waiting time would exceed that where we usually give an .
> > effect progress dialogue? Our nominal minimum system requirements
> > for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
>
> We should up that, perhaps. A progress dialogue would be good, but
> low priority (for me at least).

I'm quite minded to make the progress dialogue (say) a P4...

> > Also I've found what seems to be un-necessary window-switching
> > behaviour (is in 1.3.7 as well):
> >
> > 1. Open Audacity and generate a tone
> > 2. Plot Spectrum (close it or leave it open)
> > 3. File > New (you will have to task switch or click on the
> > correct section of the Taskbar button to see the new
> > window, due to another bug we have)
> > 4. Import an audio file (because easy to see the difference)
> > 5. Plot Spectrum and it appears with the plot of the audio
> > file, but the window switches to that for the tone, which
> > is confusing.
>
> So it does. I guess these are both on Release_Checklist for our
> students to take a hit at?

They are now (the "new window" P1 already was).

Gale

> >>>> Michael Chinen wrote:
> >>>> Are you trying to take THE spectrum of a 60 second segment (with one
> >>>> FFT,) or are you interested in finding the average spectrum by taking
> >>>> many small FFTs over the duration and averaging it out? These may
> >>>> yield similar results but the process is very different.
> >>>>
> >>>> You probably know this, but I just want to point out that in O(n log
> >>>> n), n is in samples, not seconds, so each second adds a big factor to
> >>>> the running time of the algorithm. I would be willing to bet you
> >>>> aren't going to be able to finish a FFT of size 44100*60 for a very
> >>>> long time.
> >>>>
> >>>> The Plot Spectrum command appears to take many small ones and average
> >>>> them, since you can select the FFT size in the popup window, with a
> >>>> maximum of 16384. If that's the case I'm not sure why it has a 24
> >>>> second limit either.
> >>>>
> >>>>
> >>>> Michael
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]> wrote:
> >>>>>> Computing the spectrum requires all samples to be in memory at once
> >>>>>> and costs n*log(n), so operating on many seconds of sound is unusual.
> >>>>>> If the spectrum is very stable, e.g. a steady tone, then you probably
> >>>>>> don't need to look at many seconds to extract the spectral
> >>>>>> information. If the spectrum is changing, then grabbing the spectrum
> >>>>>> of a large interval is in some sense going to smear out or average the
> >>>>>> overall energy, so again, it's not so useful. Finally, there are
> >>>>>> numerical issues to worry about when doing a very large Fourier
> >>>>>> transform to compute the spectrum. What might be useful is to compute
> >>>>>> a sequence of short-term spectra and average their magnitudes to get a
> >>>>>> long-term average spectrum. Audacity could do this in principle, but
> >>>>>> the user would have to provide more parameters and confirm that he/she
> >>>>>> really wants to do an expensive computation on a long segment of audio.
> >>>>> Alright. So if I understand well, there is no hidden reason to forbid
> >>>>> spectral analysis on
> >>>>> a larger sample. O(n log n) is a very reasonable complexity for a
> >>>>> fourier transform and
> >>>>> I am ready to wait some more seconds to compute the spectrum for 60
> >>>>> seconds instead
> >>>>> of 24 seconds. I will modify the audacity source code for my own needs
> >>>>> in that direction.
> >>>>>
> >>>>> Thanks for your quick answer
> >>>>>
> >>>>> Julien
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> _______________________________________________
> >>> audacity-devel mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >>>
> >> ------------------------------------------------------------------------------
> >> _______________________________________________
> >> audacity-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> >
> >
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Question about spectral analysis in Audacity

Gale Andrews wrote:

> | From Martyn Shaw <[hidden email]>
> | Wed, 01 Jul 2009 23:37:39 +0100
> | Subject: [Audacity-devel] Question about spectral analysis in Audacity
>> Gale Andrews wrote:
>>> | From Martyn Shaw <[hidden email]>
>>> | Wed, 01 Jul 2009 01:47:37 +0100
>> ...
>>>> The scale of 'Spectrum' stays the same as you change the 'Size'
>>>> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
>>>> refers). I didn't adjust the others as I'm not sure what they do and
>>>> if they are 'right' or 'wrong'
>>> Adobe9 does not seem capable of opening that PDF here (missing
>>> components) so can you explain what you mean for the stupid (me)?
>> I never did like pdf files. Suggest that you get a reader capable of
>> opening it, or get the rest of the components you need. Works fine
>> here in Adobe Reader 8.0. The book is excellent, if technical.
>
> Hi Martyn
>
> All the PDFs from that site fail here - tried Foxit too. One of the
> PDF's gave an explicit error that you have to subscribe (pay money).
> Are you sure that isn't the problem?

Well, here I can go to
http://www.nrbook.com/a/
click on
Numerical Recipes in C Numerical Recipes in C, Second Edition (1992)
and get to
http://www.nrbook.com/a/bookcpdf.php
then click on
13.4 Power Spectrum Estimation Using the FFT 549
and get to
http://www.nrbook.com/a/bookcpdf/c13-4.pdf
and I don't remember giving them any money. I also have a hard-copy
of the book, which has a few good laughs in it. I can also look at
pages that I've never seen before and certainly have not paid for. So
why you can't is certainly a mystery to me, except we have different
versions of Adobe sw.

Martyn

>> I'll try in two sentences, but this isn't the place for a long
>> explanation:
>>
>> If you generate a sine wave and look at its amplitude with different
>> window lengths, you'll get about the same value since it 'always'
>> falls in one frequency bin. If you have a random signal then you can
>> expect the amplitude to fall by 3dB for every doubling of the FFT
>> size, since the bins are half the size and so contain only half the
>> energy.
>>
>>> If I change size from 128 to 16384 the increments of both scales
>>> change (except that for frequency, if I use the linear option).
>> Again related to the size of the bins. More bins, greater resolution.
>>
>>> And if I look at a particular peak, the dB value is much lower with the
>>> largest size (is that expected)?
>> Depends on signal, see above.
>
> Thanks. I was looking at a short bit of "real music", but your "bins"
> explanation makes sense, and I can see with Generate > Tone: Sine
> (default settings) that the increments on the dB scale don't change
> with larger size, nor do the amplitudes of the peaks to any great .
> extent.
>
>
>>> Did you make progress trying to make the dB values displayed more
>>> like those in 1.2.6 where the low frequencies are close to -0 dB?
>>> Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
>>> shows about -30 dB less in 1.3.8. Have we got a good explanation
>>> when we are asked about this?
>> Normalisation. Read the book.
>
> Obviously I can't read the book I'm afraid, but I note you proposed on
> April 17th:
> http://n2.nabble.com/Freq-Window-vertical-scales-td2649299.html#a2649299
>
> " 'A sinusoid of amplitude 1.0 gives 0dB for all windows and FFT sizes'
>
> ...(not that I know how to do that, but it can be an 'aim')
> (and probably I should add 'within a dB'). "
>
> Well we seem to be at about -6 dB at the moment.
>
> I'll try and read up a bit somewhere, but if you mean we normalised
> before so that the highest point of the scale for "real music" was
> around 0 dB, and now we don't (so that typically it's now about
> -30 dB at default window size), I'm suggesting there may be some
> "consumer resistance" or "misunderstanding" (already voiced). :=)
>
> But if what we have now is really "less misleading" than before, we
> should educate them with a succinct sentence in the Manual.
>
>
>>>>> On my XP box (2.6 GHz 1 GB RAM)
>>>>> if I select that much or longer it takes 10 -18 seconds before anything
>>>>> happens. If the audio is over 237.8, the "anything" is the length warning,
>>>>> after which the Spectrum displays at once.
>>>> 'tis less than a second here (for a 1hr 15s file). I get the warning,
>>>> then the spectrum, as anticipated.
>>>>
>>>> Are you still seeing this?
>>> No, not in my recent ANSI build using wx 2.8.10. The wait is about
>>> 3 - 5 seconds for an hour long file (FF is running as it was before and
>>> it has about 40 tabs open as usual, but if I had the upcoming local
>>> Manual open, FF would have to be running anyway). I got the results
>>> I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
>>> that was both with the XP machine several hours after boot and on a
>>> fresh boot (made no difference). Is that Windows variability again?
>>> I will try on the Vista machine too.
>>>
>>> But anyway, wouldn't you suppose on slow machines with little RAM
>>> that the waiting time would exceed that where we usually give an .
>>> effect progress dialogue? Our nominal minimum system requirements
>>> for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
>> We should up that, perhaps. A progress dialogue would be good, but
>> low priority (for me at least).
>
> I'm quite minded to make the progress dialogue (say) a P4...
>
>
>>> Also I've found what seems to be un-necessary window-switching
>>> behaviour (is in 1.3.7 as well):
>>>
>>> 1. Open Audacity and generate a tone
>>> 2. Plot Spectrum (close it or leave it open)
>>> 3. File > New (you will have to task switch or click on the
>>> correct section of the Taskbar button to see the new
>>> window, due to another bug we have)
>>> 4. Import an audio file (because easy to see the difference)
>>> 5. Plot Spectrum and it appears with the plot of the audio
>>> file, but the window switches to that for the tone, which
>>> is confusing.
>> So it does. I guess these are both on Release_Checklist for our
>> students to take a hit at?
>
> They are now (the "new window" P1 already was).
>
>
>
> Gale
>
>
>
>
>
>>>>>> Michael Chinen wrote:
>>>>>> Are you trying to take THE spectrum of a 60 second segment (with one
>>>>>> FFT,) or are you interested in finding the average spectrum by taking
>>>>>> many small FFTs over the duration and averaging it out? These may
>>>>>> yield similar results but the process is very different.
>>>>>>
>>>>>> You probably know this, but I just want to point out that in O(n log
>>>>>> n), n is in samples, not seconds, so each second adds a big factor to
>>>>>> the running time of the algorithm. I would be willing to bet you
>>>>>> aren't going to be able to finish a FFT of size 44100*60 for a very
>>>>>> long time.
>>>>>>
>>>>>> The Plot Spectrum command appears to take many small ones and average
>>>>>> them, since you can select the FFT size in the popup window, with a
>>>>>> maximum of 16384. If that's the case I'm not sure why it has a 24
>>>>>> second limit either.
>>>>>>
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]> wrote:
>>>>>>>> Computing the spectrum requires all samples to be in memory at once
>>>>>>>> and costs n*log(n), so operating on many seconds of sound is unusual.
>>>>>>>> If the spectrum is very stable, e.g. a steady tone, then you probably
>>>>>>>> don't need to look at many seconds to extract the spectral
>>>>>>>> information. If the spectrum is changing, then grabbing the spectrum
>>>>>>>> of a large interval is in some sense going to smear out or average the
>>>>>>>> overall energy, so again, it's not so useful. Finally, there are
>>>>>>>> numerical issues to worry about when doing a very large Fourier
>>>>>>>> transform to compute the spectrum. What might be useful is to compute
>>>>>>>> a sequence of short-term spectra and average their magnitudes to get a
>>>>>>>> long-term average spectrum. Audacity could do this in principle, but
>>>>>>>> the user would have to provide more parameters and confirm that he/she
>>>>>>>> really wants to do an expensive computation on a long segment of audio.
>>>>>>> Alright. So if I understand well, there is no hidden reason to forbid
>>>>>>> spectral analysis on
>>>>>>> a larger sample. O(n log n) is a very reasonable complexity for a
>>>>>>> fourier transform and
>>>>>>> I am ready to wait some more seconds to compute the spectrum for 60
>>>>>>> seconds instead
>>>>>>> of 24 seconds. I will modify the audacity source code for my own needs
>>>>>>> in that direction.
>>>>>>>
>>>>>>> Thanks for your quick answer
>>>>>>>
>>>>>>> Julien
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> audacity-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Gale

Re: Question about spectral analysis in Audacity

Administrator

| From Martyn Shaw <[hidden email]>
| Sat, 04 Jul 2009 01:28:32 +0100
| Subject: [Audacity-devel] Question about spectral analysis in Audacity

> Gale Andrews wrote:
> > | From Martyn Shaw <[hidden email]>
> > | Wed, 01 Jul 2009 23:37:39 +0100
> > | Subject: [Audacity-devel] Question about spectral analysis in Audacity
> >> Gale Andrews wrote:
> >>> | From Martyn Shaw <[hidden email]>
> >>> | Wed, 01 Jul 2009 01:47:37 +0100
> >> ...
> >>>> The scale of 'Spectrum' stays the same as you change the 'Size'
> >>>> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
> >>>> refers). I didn't adjust the others as I'm not sure what they do and
> >>>> if they are 'right' or 'wrong'
> >>> Adobe9 does not seem capable of opening that PDF here (missing
> >>> components) so can you explain what you mean for the stupid (me)?
> >> I never did like pdf files. Suggest that you get a reader capable of
> >> opening it, or get the rest of the components you need. Works fine
> >> here in Adobe Reader 8.0. The book is excellent, if technical.
> >
> > Hi Martyn
> >
> > All the PDFs from that site fail here - tried Foxit too. One of the
> > PDF's gave an explicit error that you have to subscribe (pay money).
> > Are you sure that isn't the problem?
>
> Well, here I can go to
> http://www.nrbook.com/a/
> click on
> Numerical Recipes in C Numerical Recipes in C, Second Edition (1992)
> and get to
> http://www.nrbook.com/a/bookcpdf.php
> then click on
> 13.4 Power Spectrum Estimation Using the FFT 549
> and get to
> http://www.nrbook.com/a/bookcpdf/c13-4.pdf
>
> and I don't remember giving them any money. I also have a hard-copy
> of the book, which has a few good laughs in it. I can also look at
> pages that I've never seen before and certainly have not paid for. So
> why you can't is certainly a mystery to me, except we have different
> versions of Adobe sw.

Navigating that route and "save link as" works fine here. Before that,
I had already got the "FileOpen" plug-in they require (the "missing
components" Adobe was complaining about), and my file still gave
errors, though clearly the correct size.

Then I navigated to it via some other route that gave me a directory
listing and "saved link as". That also failed here.

I tested on my Vista machine by just clicking the direct link:
http://www.nrbook.com/a/bookcpdf/c13-4.pdf

then tried to open (or save and open) in Adobe9 with the plug-in
installed, and got the same issue. But if I now alter the "4" in the
above link to "2" and download it on this machine, it works.

So I do think they are playing some kind of games (not letting you
click on a direct link the first time)?

Now I've got the PDF, it doesn't quite look like "bedtime reading" but
I'll take a look...

Thanks

Gale

> >> I'll try in two sentences, but this isn't the place for a long
> >> explanation:
> >>
> >> If you generate a sine wave and look at its amplitude with different
> >> window lengths, you'll get about the same value since it 'always'
> >> falls in one frequency bin. If you have a random signal then you can
> >> expect the amplitude to fall by 3dB for every doubling of the FFT
> >> size, since the bins are half the size and so contain only half the
> >> energy.
> >>
> >>> If I change size from 128 to 16384 the increments of both scales
> >>> change (except that for frequency, if I use the linear option).
> >> Again related to the size of the bins. More bins, greater resolution.
> >>
> >>> And if I look at a particular peak, the dB value is much lower with the
> >>> largest size (is that expected)?
> >> Depends on signal, see above.
> >
> > Thanks. I was looking at a short bit of "real music", but your "bins"
> > explanation makes sense, and I can see with Generate > Tone: Sine
> > (default settings) that the increments on the dB scale don't change
> > with larger size, nor do the amplitudes of the peaks to any great .
> > extent.
> >
> >
> >>> Did you make progress trying to make the dB values displayed more
> >>> like those in 1.2.6 where the low frequencies are close to -0 dB?
> >>> Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
> >>> shows about -30 dB less in 1.3.8. Have we got a good explanation
> >>> when we are asked about this?
> >> Normalisation. Read the book.
> >
> > Obviously I can't read the book I'm afraid, but I note you proposed on
> > April 17th:
> > http://n2.nabble.com/Freq-Window-vertical-scales-td2649299.html#a2649299
> >
> > " 'A sinusoid of amplitude 1.0 gives 0dB for all windows and FFT sizes'
> >
> > ...(not that I know how to do that, but it can be an 'aim')
> > (and probably I should add 'within a dB'). "
> >
> > Well we seem to be at about -6 dB at the moment.
> >
> > I'll try and read up a bit somewhere, but if you mean we normalised
> > before so that the highest point of the scale for "real music" was
> > around 0 dB, and now we don't (so that typically it's now about
> > -30 dB at default window size), I'm suggesting there may be some
> > "consumer resistance" or "misunderstanding" (already voiced). :=)
> >
> > But if what we have now is really "less misleading" than before, we
> > should educate them with a succinct sentence in the Manual.
> >
> >
> >>>>> On my XP box (2.6 GHz 1 GB RAM)
> >>>>> if I select that much or longer it takes 10 -18 seconds before anything
> >>>>> happens. If the audio is over 237.8, the "anything" is the length warning,
> >>>>> after which the Spectrum displays at once.
> >>>> 'tis less than a second here (for a 1hr 15s file). I get the warning,
> >>>> then the spectrum, as anticipated.
> >>>>
> >>>> Are you still seeing this?
> >>> No, not in my recent ANSI build using wx 2.8.10. The wait is about
> >>> 3 - 5 seconds for an hour long file (FF is running as it was before and
> >>> it has about 40 tabs open as usual, but if I had the upcoming local
> >>> Manual open, FF would have to be running anyway). I got the results
> >>> I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
> >>> that was both with the XP machine several hours after boot and on a
> >>> fresh boot (made no difference). Is that Windows variability again?
> >>> I will try on the Vista machine too.
> >>>
> >>> But anyway, wouldn't you suppose on slow machines with little RAM
> >>> that the waiting time would exceed that where we usually give an .
> >>> effect progress dialogue? Our nominal minimum system requirements
> >>> for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
> >> We should up that, perhaps. A progress dialogue would be good, but
> >> low priority (for me at least).
> >
> > I'm quite minded to make the progress dialogue (say) a P4...
> >
> >
> >>> Also I've found what seems to be un-necessary window-switching
> >>> behaviour (is in 1.3.7 as well):
> >>>
> >>> 1. Open Audacity and generate a tone
> >>> 2. Plot Spectrum (close it or leave it open)
> >>> 3. File > New (you will have to task switch or click on the
> >>> correct section of the Taskbar button to see the new
> >>> window, due to another bug we have)
> >>> 4. Import an audio file (because easy to see the difference)
> >>> 5. Plot Spectrum and it appears with the plot of the audio
> >>> file, but the window switches to that for the tone, which
> >>> is confusing.
> >> So it does. I guess these are both on Release_Checklist for our
> >> students to take a hit at?
> >
> > They are now (the "new window" P1 already was).
> >
> >
> >
> > Gale
> >
> >
> >
> >
> >
> >>>>>> Michael Chinen wrote:
> >>>>>> Are you trying to take THE spectrum of a 60 second segment (with one
> >>>>>> FFT,) or are you interested in finding the average spectrum by taking
> >>>>>> many small FFTs over the duration and averaging it out? These may
> >>>>>> yield similar results but the process is very different.
> >>>>>>
> >>>>>> You probably know this, but I just want to point out that in O(n log
> >>>>>> n), n is in samples, not seconds, so each second adds a big factor to
> >>>>>> the running time of the algorithm. I would be willing to bet you
> >>>>>> aren't going to be able to finish a FFT of size 44100*60 for a very
> >>>>>> long time.
> >>>>>>
> >>>>>> The Plot Spectrum command appears to take many small ones and average
> >>>>>> them, since you can select the FFT size in the popup window, with a
> >>>>>> maximum of 16384. If that's the case I'm not sure why it has a 24
> >>>>>> second limit either.
> >>>>>>
> >>>>>>
> >>>>>> Michael
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]> wrote:
> >>>>>>>> Computing the spectrum requires all samples to be in memory at once
> >>>>>>>> and costs n*log(n), so operating on many seconds of sound is unusual.
> >>>>>>>> If the spectrum is very stable, e.g. a steady tone, then you probably
> >>>>>>>> don't need to look at many seconds to extract the spectral
> >>>>>>>> information. If the spectrum is changing, then grabbing the spectrum
> >>>>>>>> of a large interval is in some sense going to smear out or average the
> >>>>>>>> overall energy, so again, it's not so useful. Finally, there are
> >>>>>>>> numerical issues to worry about when doing a very large Fourier
> >>>>>>>> transform to compute the spectrum. What might be useful is to compute
> >>>>>>>> a sequence of short-term spectra and average their magnitudes to get a
> >>>>>>>> long-term average spectrum. Audacity could do this in principle, but
> >>>>>>>> the user would have to provide more parameters and confirm that he/she
> >>>>>>>> really wants to do an expensive computation on a long segment of audio.
> >>>>>>> Alright. So if I understand well, there is no hidden reason to forbid
> >>>>>>> spectral analysis on
> >>>>>>> a larger sample. O(n log n) is a very reasonable complexity for a
> >>>>>>> fourier transform and
> >>>>>>> I am ready to wait some more seconds to compute the spectrum for 60
> >>>>>>> seconds instead
> >>>>>>> of 24 seconds. I will modify the audacity source code for my own needs
> >>>>>>> in that direction.
> >>>>>>>
> >>>>>>> Thanks for your quick answer
> >>>>>>>
> >>>>>>> Julien

Philip Van Baren

Re: Question about spectral analysis in Audacity

In reply to this post by Martyn Shaw-2

If the goal is to get a full scale sine tone to show 0dB in the spectrum
window, the normalization factor which achieves this is to make the sum of
the window function values = 2.0. (The 2.0 factor comes from the average
value of sin^2 = 0.5)

The current code normalizes the sum of the squares of the window function
values. This is appropriate if you are trying to normalize for random
signals (it maintains RMS), but it won't give a consistent normalization for
fixed frequency sine tones.

I've made and tested a patch for this, and verified that it gives 0dB for
full scale sine tones at all FFT lengths. Is this the goal for Audacity
1.3.8, and if so, should I go ahead and submit the change?

Phil

-----Original Message-----
From: Martyn Shaw [mailto:[hidden email]]
Sent: Wednesday, July 01, 2009 6:38 PM
To: [hidden email]
Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity

Gale Andrews wrote:
> | From Martyn Shaw <[hidden email]>
> | Wed, 01 Jul 2009 01:47:37 +0100
...
>> The scale of 'Spectrum' stays the same as you change the 'Size'
>> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
>> refers). I didn't adjust the others as I'm not sure what they do and
>> if they are 'right' or 'wrong'
>
> Adobe9 does not seem capable of opening that PDF here (missing
> components) so can you explain what you mean for the stupid (me)?

I never did like pdf files. Suggest that you get a reader capable of
opening it, or get the rest of the components you need. Works fine
here in Adobe Reader 8.0. The book is excellent, if technical.

I'll try in two sentences, but this isn't the place for a long
explanation:
If you generate a sine wave and look at it's amplitude with different
window lengths, you'll get about the same value since it 'always'
falls in one frequency bin. If you have a random signal then you can
expect the amplitude to fall by 3dB for every doubling of the FFT
size, since the bins are half the size and so contain only half the
energy.

> If I change size from 128 to 16384 the increments of both scales
> change (except that for frequency, if I use the linear option).

Again related to the size of the bins. More bins, greater resolution.

And if
> I look at a particular peak, the dB value is much lower with the
> largest size (is that expected)?

Depends on signal, see above.

> Did you make progress trying to make the dB values displayed more
> like those in 1.2.6 where the low frequencies are close to -0 dB?
> Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
> shows about -30 dB less in 1.3.8. Have we got a good explanation
> when we are asked about this?

Normalisation. Read the book.

>>> On my XP box (2.6 GHz 1 GB RAM)
>>> if I select that much or longer it takes 10 -18 seconds before anything

>>> happens. If the audio is over 237.8, the "anything" is the length
warning,

>>> after which the Spectrum displays at once.
>> 'tis less than a second here (for a 1hr 15s file). I get the warning,
>> then the spectrum, as anticipated.
>>
>> Are you still seeing this?
>
> No, not in my recent ANSI build using wx 2.8.10. The wait is about
> 3 - 5 seconds for an hour long file (FF is running as it was before and
> it has about 40 tabs open as usual, but if I had the upcoming local
> Manual open, FF would have to be running anyway). I got the results
> I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
> that was both with the XP machine several hours after boot and on a
> fresh boot (made no difference). Is that Windows variability again?
> I will try on the Vista machine too.
>
> But anyway, wouldn't you suppose on slow machines with little RAM
> that the waiting time would exceed that where we usually give an .
> effect progress dialogue? Our nominal minimum system requirements
> for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.

We should up that, perhaps. A progress dialogue would be good, but
low priority (for me at least).

So it does. I guess these are both on Release_Checklist for our
students to take a hit at?

TTFN
Martyn

wrote:
>>>>>> Computing the spectrum requires all samples to be in memory at once
>>>>>> and costs n*log(n), so operating on many seconds of sound is unusual.
>>>>>> If the spectrum is very stable, e.g. a steady tone, then you probably
>>>>>> don't need to look at many seconds to extract the spectral
>>>>>> information. If the spectrum is changing, then grabbing the spectrum
>>>>>> of a large interval is in some sense going to smear out or average
the
>>>>>> overall energy, so again, it's not so useful. Finally, there are
>>>>>> numerical issues to worry about when doing a very large Fourier
>>>>>> transform to compute the spectrum. What might be useful is to compute
>>>>>> a sequence of short-term spectra and average their magnitudes to get
a
>>>>>> long-term average spectrum. Audacity could do this in principle, but
>>>>>> the user would have to provide more parameters and confirm that
he/she
>>>>>> really wants to do an expensive computation on a long segment of
audio.

>>>>> Alright. So if I understand well, there is no hidden reason to forbid
>>>>> spectral analysis on
>>>>> a larger sample. O(n log n) is a very reasonable complexity for a
>>>>> fourier transform and
>>>>> I am ready to wait some more seconds to compute the spectrum for 60
>>>>> seconds instead
>>>>> of 24 seconds. I will modify the audacity source code for my own needs
>>>>> in that direction.
>>>>>
>>>>> Thanks for your quick answer
>>>>>
>>>>> Julien
>>>
>>>
>>>

----------------------------------------------------------------------------
--
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
----------------------------------------------------------------------------
--
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
>
>
----------------------------------------------------------------------------
--
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

----------------------------------------------------------------------------
--
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale

Re: Question about spectral analysis in Audacity

Administrator

| From "Philip Van Baren" <[hidden email]>
| Mon, 6 Jul 2009 12:41:48 -0400
| Subject: [Audacity-devel] Question about spectral analysis in Audacity

> If the goal is to get a full scale sine tone to show 0dB in the spectrum
> window, the normalization factor which achieves this is to make the sum of
> the window function values = 2.0. (The 2.0 factor comes from the average
> value of sin^2 = 0.5)
>
> The current code normalizes the sum of the squares of the window function
> values. This is appropriate if you are trying to normalize for random
> signals (it maintains RMS), but it won't give a consistent normalization for
> fixed frequency sine tones.
>
> I've made and tested a patch for this, and verified that it gives 0dB for
> full scale sine tones at all FFT lengths. Is this the goal for Audacity
> 1.3.8, and if so, should I go ahead and submit the change?

Just to refer back to 1.2.6 behaviour (most users of 2.0 will be
migrating from 1.2.6), a full scale sine peaked at about +15 dB,
while 23.8 seconds of a "typical" pop track peaked at about 0 dB.

My assumption would be that people who are analysing tones would
be more savvy than those looking at pieces of music. Those looking
at pieces of music are probably looking for noise spikes to attenuate.
They are likely to be confused if a track normalised to 0 dB peaks at
-30 dB in Plot Spectrum, even though the amplitude scale in Spectrum
does not relate to the waveform scale. 1.2.6 behaviour "appears
intuitive" for music, but are you saying this is inappropriate because
RMS is not maintained? Could or should normalisation be different if a
tone is presented for analysis (which could be an imported file)?

Maybe as you suggest in the "New FFT function" thread, a preference
for full scale configuration would be good (we should state against each
option what that one is "best for"). Note the lower end of the dB range
in the spectrum is already directly affected by the "Meter/Waveform dB range"
preference, but the user comments I've seen about this have been
negative (on the basis the waveform and spectrum scales aren't really
comparable, so it is not "expected" this preference would affect the
Spectrum plot).

Gale

> -----Original Message-----
> From: Martyn Shaw [mailto:[hidden email]]
> Sent: Wednesday, July 01, 2009 6:38 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity
>
>
>
> Gale Andrews wrote:
> > | From Martyn Shaw <[hidden email]>
> > | Wed, 01 Jul 2009 01:47:37 +0100
> ...
> >> The scale of 'Spectrum' stays the same as you change the 'Size'
> >> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
> >> refers). I didn't adjust the others as I'm not sure what they do and
> >> if they are 'right' or 'wrong'
> >
> > Adobe9 does not seem capable of opening that PDF here (missing
> > components) so can you explain what you mean for the stupid (me)?
>
> I never did like pdf files. Suggest that you get a reader capable of
> opening it, or get the rest of the components you need. Works fine
> here in Adobe Reader 8.0. The book is excellent, if technical.
>
> I'll try in two sentences, but this isn't the place for a long
> explanation:
> If you generate a sine wave and look at it's amplitude with different
> window lengths, you'll get about the same value since it 'always'
> falls in one frequency bin. If you have a random signal then you can
> expect the amplitude to fall by 3dB for every doubling of the FFT
> size, since the bins are half the size and so contain only half the
> energy.
>
> > If I change size from 128 to 16384 the increments of both scales
> > change (except that for frequency, if I use the linear option).
>
> Again related to the size of the bins. More bins, greater resolution.
>
> And if
> > I look at a particular peak, the dB value is much lower with the
> > largest size (is that expected)?
>
> Depends on signal, see above.
>
> > Did you make progress trying to make the dB values displayed more
> > like those in 1.2.6 where the low frequencies are close to -0 dB?
> > Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
> > shows about -30 dB less in 1.3.8. Have we got a good explanation
> > when we are asked about this?
>
> Normalisation. Read the book.
>
> >>> On my XP box (2.6 GHz 1 GB RAM)
> >>> if I select that much or longer it takes 10 -18 seconds before anything
>
> >>> happens. If the audio is over 237.8, the "anything" is the length
> warning,
> >>> after which the Spectrum displays at once.
> >> 'tis less than a second here (for a 1hr 15s file). I get the warning,
> >> then the spectrum, as anticipated.
> >>
> >> Are you still seeing this?
> >
> > No, not in my recent ANSI build using wx 2.8.10. The wait is about
> > 3 - 5 seconds for an hour long file (FF is running as it was before and
> > it has about 40 tabs open as usual, but if I had the upcoming local
> > Manual open, FF would have to be running anyway). I got the results
> > I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
> > that was both with the XP machine several hours after boot and on a
> > fresh boot (made no difference). Is that Windows variability again?
> > I will try on the Vista machine too.
> >
> > But anyway, wouldn't you suppose on slow machines with little RAM
> > that the waiting time would exceed that where we usually give an .
> > effect progress dialogue? Our nominal minimum system requirements
> > for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
>
> We should up that, perhaps. A progress dialogue would be good, but
> low priority (for me at least).
>
> > Also I've found what seems to be un-necessary window-switching
> > behaviour (is in 1.3.7 as well):
> >
> > 1. Open Audacity and generate a tone
> > 2. Plot Spectrum (close it or leave it open)
> > 3. File > New (you will have to task switch or click on the
> > correct section of the Taskbar button to see the new
> > window, due to another bug we have)
> > 4. Import an audio file (because easy to see the difference)
> > 5. Plot Spectrum and it appears with the plot of the audio
> > file, but the window switches to that for the tone, which
> > is confusing.
>
> So it does. I guess these are both on Release_Checklist for our
> students to take a hit at?
>
> TTFN
> Martyn
>
> > Thanks
> >
> >
> > Gale
> >
> >
> >>>> Michael Chinen wrote:
> >>>> Are you trying to take THE spectrum of a 60 second segment (with one
> >>>> FFT,) or are you interested in finding the average spectrum by taking
> >>>> many small FFTs over the duration and averaging it out? These may
> >>>> yield similar results but the process is very different.
> >>>>
> >>>> You probably know this, but I just want to point out that in O(n log
> >>>> n), n is in samples, not seconds, so each second adds a big factor to
> >>>> the running time of the algorithm. I would be willing to bet you
> >>>> aren't going to be able to finish a FFT of size 44100*60 for a very
> >>>> long time.
> >>>>
> >>>> The Plot Spectrum command appears to take many small ones and average
> >>>> them, since you can select the FFT size in the popup window, with a
> >>>> maximum of 16384. If that's the case I'm not sure why it has a 24
> >>>> second limit either.
> >>>>
> >>>>
> >>>> Michael
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]>
> wrote:
> >>>>>> Computing the spectrum requires all samples to be in memory at once
> >>>>>> and costs n*log(n), so operating on many seconds of sound is unusual.
> >>>>>> If the spectrum is very stable, e.g. a steady tone, then you probably
> >>>>>> don't need to look at many seconds to extract the spectral
> >>>>>> information. If the spectrum is changing, then grabbing the spectrum
> >>>>>> of a large interval is in some sense going to smear out or average
> the
> >>>>>> overall energy, so again, it's not so useful. Finally, there are
> >>>>>> numerical issues to worry about when doing a very large Fourier
> >>>>>> transform to compute the spectrum. What might be useful is to compute
> >>>>>> a sequence of short-term spectra and average their magnitudes to get
> a
> >>>>>> long-term average spectrum. Audacity could do this in principle, but
> >>>>>> the user would have to provide more parameters and confirm that
> he/she
> >>>>>> really wants to do an expensive computation on a long segment of
> audio.
> >>>>> Alright. So if I understand well, there is no hidden reason to forbid
> >>>>> spectral analysis on
> >>>>> a larger sample. O(n log n) is a very reasonable complexity for a
> >>>>> fourier transform and
> >>>>> I am ready to wait some more seconds to compute the spectrum for 60
> >>>>> seconds instead
> >>>>> of 24 seconds. I will modify the audacity source code for my own needs
> >>>>> in that direction.
> >>>>>
> >>>>> Thanks for your quick answer
> >>>>>
> >>>>> Julien
> >>>

Philip Van Baren

Re: Question about spectral analysis in Audacity

Given the previous conversation it looks like the decision was made to
change behavior in 1.3.8 such that a full scale sine wave gives 0dB on the
'plot spectrum' graph, and not duplicate the 1.2.6 behavior.

My point is, if this is the goal for 1.3.8, then there is a known
normalization factor which will give exactly 0dB peaks for sine tones.
Normalizing with sum-of-squares times the window length will get it close,
but it won't be exactly 0dB for all window functions and all window lengths.

Phil

-----Original Message-----
From: Gale Andrews [mailto:[hidden email]]
Sent: Monday, July 06, 2009 3:55 PM
To: [hidden email]
Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity

| From "Philip Van Baren" <[hidden email]>
| Mon, 6 Jul 2009 12:41:48 -0400
| Subject: [Audacity-devel] Question about spectral analysis in Audacity
> If the goal is to get a full scale sine tone to show 0dB in the spectrum
> window, the normalization factor which achieves this is to make the sum of
> the window function values = 2.0. (The 2.0 factor comes from the average
> value of sin^2 = 0.5)
>
> The current code normalizes the sum of the squares of the window function
> values. This is appropriate if you are trying to normalize for random
> signals (it maintains RMS), but it won't give a consistent normalization
for
> fixed frequency sine tones.
>
> I've made and tested a patch for this, and verified that it gives 0dB for
> full scale sine tones at all FFT lengths. Is this the goal for Audacity
> 1.3.8, and if so, should I go ahead and submit the change?

Just to refer back to 1.2.6 behaviour (most users of 2.0 will be
migrating from 1.2.6), a full scale sine peaked at about +15 dB,
while 23.8 seconds of a "typical" pop track peaked at about 0 dB.

My assumption would be that people who are analysing tones would
be more savvy than those looking at pieces of music. Those looking
at pieces of music are probably looking for noise spikes to attenuate.
They are likely to be confused if a track normalised to 0 dB peaks at
-30 dB in Plot Spectrum, even though the amplitude scale in Spectrum
does not relate to the waveform scale. 1.2.6 behaviour "appears
intuitive" for music, but are you saying this is inappropriate because
RMS is not maintained? Could or should normalisation be different if a
tone is presented for analysis (which could be an imported file)?

Maybe as you suggest in the "New FFT function" thread, a preference
for full scale configuration would be good (we should state against each
option what that one is "best for"). Note the lower end of the dB range
in the spectrum is already directly affected by the "Meter/Waveform dB
range"
preference, but the user comments I've seen about this have been
negative (on the basis the waveform and spectrum scales aren't really
comparable, so it is not "expected" this preference would affect the
Spectrum plot).

Gale

anything

>
> >>> happens. If the audio is over 237.8, the "anything" is the length
> warning,
> >>> after which the Spectrum displays at once.
> >> 'tis less than a second here (for a 1hr 15s file). I get the warning,
> >> then the spectrum, as anticipated.
> >>
> >> Are you still seeing this?
> >
> > No, not in my recent ANSI build using wx 2.8.10. The wait is about
> > 3 - 5 seconds for an hour long file (FF is running as it was before and
> > it has about 40 tabs open as usual, but if I had the upcoming local
> > Manual open, FF would have to be running anyway). I got the results
> > I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
> > that was both with the XP machine several hours after boot and on a
> > fresh boot (made no difference). Is that Windows variability again?
> > I will try on the Vista machine too.
> >
> > But anyway, wouldn't you suppose on slow machines with little RAM
> > that the waiting time would exceed that where we usually give an .
> > effect progress dialogue? Our nominal minimum system requirements
> > for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
>
> We should up that, perhaps. A progress dialogue would be good, but
> low priority (for me at least).
>
> > Also I've found what seems to be un-necessary window-switching
> > behaviour (is in 1.3.7 as well):
> >
> > 1. Open Audacity and generate a tone
> > 2. Plot Spectrum (close it or leave it open)
> > 3. File > New (you will have to task switch or click on the
> > correct section of the Taskbar button to see the new
> > window, due to another bug we have)
> > 4. Import an audio file (because easy to see the difference)
> > 5. Plot Spectrum and it appears with the plot of the audio
> > file, but the window switches to that for the tone, which
> > is confusing.
>
> So it does. I guess these are both on Release_Checklist for our
> students to take a hit at?
>
> TTFN
> Martyn
>
> > Thanks
> >
> >
> > Gale
> >
> >
> >>>> Michael Chinen wrote:
> >>>> Are you trying to take THE spectrum of a 60 second segment (with one
> >>>> FFT,) or are you interested in finding the average spectrum by taking
> >>>> many small FFTs over the duration and averaging it out? These may
> >>>> yield similar results but the process is very different.
> >>>>
> >>>> You probably know this, but I just want to point out that in O(n log
> >>>> n), n is in samples, not seconds, so each second adds a big factor to
> >>>> the running time of the algorithm. I would be willing to bet you
> >>>> aren't going to be able to finish a FFT of size 44100*60 for a very
> >>>> long time.
> >>>>
> >>>> The Plot Spectrum command appears to take many small ones and average
> >>>> them, since you can select the FFT size in the popup window, with a
> >>>> maximum of 16384. If that's the case I'm not sure why it has a 24
> >>>> second limit either.
> >>>>
> >>>>
> >>>> Michael
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]>
> wrote:
> >>>>>> Computing the spectrum requires all samples to be in memory at once
> >>>>>> and costs n*log(n), so operating on many seconds of sound is

unusual.
> >>>>>> If the spectrum is very stable, e.g. a steady tone, then you
probably
> >>>>>> don't need to look at many seconds to extract the spectral
> >>>>>> information. If the spectrum is changing, then grabbing the
spectrum
> >>>>>> of a large interval is in some sense going to smear out or average
> the
> >>>>>> overall energy, so again, it's not so useful. Finally, there are
> >>>>>> numerical issues to worry about when doing a very large Fourier
> >>>>>> transform to compute the spectrum. What might be useful is to
compute
> >>>>>> a sequence of short-term spectra and average their magnitudes to
get
> a
> >>>>>> long-term average spectrum. Audacity could do this in principle,
but
> >>>>>> the user would have to provide more parameters and confirm that
> he/she
> >>>>>> really wants to do an expensive computation on a long segment of
> audio.
> >>>>> Alright. So if I understand well, there is no hidden reason to
forbid
> >>>>> spectral analysis on
> >>>>> a larger sample. O(n log n) is a very reasonable complexity for a
> >>>>> fourier transform and
> >>>>> I am ready to wait some more seconds to compute the spectrum for 60
> >>>>> seconds instead
> >>>>> of 24 seconds. I will modify the audacity source code for my own
needs
> >>>>> in that direction.
> >>>>>
> >>>>> Thanks for your quick answer
> >>>>>
> >>>>> Julien
> >>>

----------------------------------------------------------------------------
--
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Question about spectral analysis in Audacity

Hi Phil

Thanks for your input here, very valuable and nice to have somebody on
board who understands the problems.

I think I probably put in that 'sum-of-squares' code, and I seem to
remember struggling with it at the time, and that was the best I could do.

Gale is correct in that most people will be looking at music, not
sinusoids, so we need to have a sensible compromise on actual scale.

Personally I am a 'sinusoid analyser' rather than a 'music analyser',
but I don't like to admit it ;-).

Obviously we don't want the scale to change with the window type or
length so fixing the code would be good, for both types of user.

Is it possible to give 0dB peaks for +-1 sinusoids, then offset that
by a fixed number of dBs to give 'near 0dB' for typical modern
over-compressed, limited BW, full of spectral holes, 96-128kbps MP3
file that people seem to love. I suspect not as window types /
lengths are changed. But if you know a way then let us know by doing
it...

Maybe an option (music/sines?) in the window? (but I used up all the
space with the 'Replot' and 'Grids' options I think). Maybe we could
save some space by calling 'Function:' 'Window:' then loosing the
'window' word off the choices? Or by loosing 'frequency' in the
'Axis:' box?

I appreciate you input here!

TTFN
Martyn

Philip Van Baren wrote:

> Given the previous conversation it looks like the decision was made to
> change behavior in 1.3.8 such that a full scale sine wave gives 0dB on the
> 'plot spectrum' graph, and not duplicate the 1.2.6 behavior.
>
> My point is, if this is the goal for 1.3.8, then there is a known
> normalization factor which will give exactly 0dB peaks for sine tones.
> Normalizing with sum-of-squares times the window length will get it close,
> but it won't be exactly 0dB for all window functions and all window lengths.
>
> Phil
>
> -----Original Message-----
> From: Gale Andrews [mailto:[hidden email]]
> Sent: Monday, July 06, 2009 3:55 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity
>
>
> | From "Philip Van Baren" <[hidden email]>
> | Mon, 6 Jul 2009 12:41:48 -0400
> | Subject: [Audacity-devel] Question about spectral analysis in Audacity
>> If the goal is to get a full scale sine tone to show 0dB in the spectrum
>> window, the normalization factor which achieves this is to make the sum of
>> the window function values = 2.0. (The 2.0 factor comes from the average
>> value of sin^2 = 0.5)
>>
>> The current code normalizes the sum of the squares of the window function
>> values. This is appropriate if you are trying to normalize for random
>> signals (it maintains RMS), but it won't give a consistent normalization
> for
>> fixed frequency sine tones.
>>
>> I've made and tested a patch for this, and verified that it gives 0dB for
>> full scale sine tones at all FFT lengths. Is this the goal for Audacity
>> 1.3.8, and if so, should I go ahead and submit the change?
>
> Just to refer back to 1.2.6 behaviour (most users of 2.0 will be
> migrating from 1.2.6), a full scale sine peaked at about +15 dB,
> while 23.8 seconds of a "typical" pop track peaked at about 0 dB.
>
> My assumption would be that people who are analysing tones would
> be more savvy than those looking at pieces of music. Those looking
> at pieces of music are probably looking for noise spikes to attenuate.
> They are likely to be confused if a track normalised to 0 dB peaks at
> -30 dB in Plot Spectrum, even though the amplitude scale in Spectrum
> does not relate to the waveform scale. 1.2.6 behaviour "appears
> intuitive" for music, but are you saying this is inappropriate because
> RMS is not maintained? Could or should normalisation be different if a
> tone is presented for analysis (which could be an imported file)?
>
> Maybe as you suggest in the "New FFT function" thread, a preference
> for full scale configuration would be good (we should state against each
> option what that one is "best for"). Note the lower end of the dB range
> in the spectrum is already directly affected by the "Meter/Waveform dB
> range"
> preference, but the user comments I've seen about this have been
> negative (on the basis the waveform and spectrum scales aren't really
> comparable, so it is not "expected" this preference would affect the
> Spectrum plot).
>
>
>
> Gale
>
>
>
>> -----Original Message-----
>> From: Martyn Shaw [mailto:[hidden email]]
>> Sent: Wednesday, July 01, 2009 6:38 PM
>> To: [hidden email]
>> Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity
>>
>>
>>
>> Gale Andrews wrote:
>>> | From Martyn Shaw <[hidden email]>
>>> | Wed, 01 Jul 2009 01:47:37 +0100
>> ...
>>>> The scale of 'Spectrum' stays the same as you change the 'Size'
>>>> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
>>>> refers). I didn't adjust the others as I'm not sure what they do and
>>>> if they are 'right' or 'wrong'
>>> Adobe9 does not seem capable of opening that PDF here (missing
>>> components) so can you explain what you mean for the stupid (me)?
>> I never did like pdf files. Suggest that you get a reader capable of
>> opening it, or get the rest of the components you need. Works fine
>> here in Adobe Reader 8.0. The book is excellent, if technical.
>>
>> I'll try in two sentences, but this isn't the place for a long
>> explanation:
>> If you generate a sine wave and look at it's amplitude with different
>> window lengths, you'll get about the same value since it 'always'
>> falls in one frequency bin. If you have a random signal then you can
>> expect the amplitude to fall by 3dB for every doubling of the FFT
>> size, since the bins are half the size and so contain only half the
>> energy.
>>
>>> If I change size from 128 to 16384 the increments of both scales
>>> change (except that for frequency, if I use the linear option).
>> Again related to the size of the bins. More bins, greater resolution.
>>
>> And if
>>> I look at a particular peak, the dB value is much lower with the
>>> largest size (is that expected)?
>> Depends on signal, see above.
>>
>>> Did you make progress trying to make the dB values displayed more
>>> like those in 1.2.6 where the low frequencies are close to -0 dB?
>>> Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
>>> shows about -30 dB less in 1.3.8. Have we got a good explanation
>>> when we are asked about this?
>> Normalisation. Read the book.
>>
>>>>> On my XP box (2.6 GHz 1 GB RAM)
>>>>> if I select that much or longer it takes 10 -18 seconds before
> anything
>>>>> happens. If the audio is over 237.8, the "anything" is the length
>> warning,
>>>>> after which the Spectrum displays at once.
>>>> 'tis less than a second here (for a 1hr 15s file). I get the warning,
>>>> then the spectrum, as anticipated.
>>>>
>>>> Are you still seeing this?
>>> No, not in my recent ANSI build using wx 2.8.10. The wait is about
>>> 3 - 5 seconds for an hour long file (FF is running as it was before and
>>> it has about 40 tabs open as usual, but if I had the upcoming local
>>> Manual open, FF would have to be running anyway). I got the results
>>> I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
>>> that was both with the XP machine several hours after boot and on a
>>> fresh boot (made no difference). Is that Windows variability again?
>>> I will try on the Vista machine too.
>>>
>>> But anyway, wouldn't you suppose on slow machines with little RAM
>>> that the waiting time would exceed that where we usually give an .
>>> effect progress dialogue? Our nominal minimum system requirements
>>> for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
>> We should up that, perhaps. A progress dialogue would be good, but
>> low priority (for me at least).
>>
>>> Also I've found what seems to be un-necessary window-switching
>>> behaviour (is in 1.3.7 as well):
>>>
>>> 1. Open Audacity and generate a tone
>>> 2. Plot Spectrum (close it or leave it open)
>>> 3. File > New (you will have to task switch or click on the
>>> correct section of the Taskbar button to see the new
>>> window, due to another bug we have)
>>> 4. Import an audio file (because easy to see the difference)
>>> 5. Plot Spectrum and it appears with the plot of the audio
>>> file, but the window switches to that for the tone, which
>>> is confusing.
>> So it does. I guess these are both on Release_Checklist for our
>> students to take a hit at?
>>
>> TTFN
>> Martyn
>>
>>> Thanks
>>>
>>>
>>> Gale
>>>
>>>
>>>>>> Michael Chinen wrote:
>>>>>> Are you trying to take THE spectrum of a 60 second segment (with one
>>>>>> FFT,) or are you interested in finding the average spectrum by taking
>>>>>> many small FFTs over the duration and averaging it out? These may
>>>>>> yield similar results but the process is very different.
>>>>>>
>>>>>> You probably know this, but I just want to point out that in O(n log
>>>>>> n), n is in samples, not seconds, so each second adds a big factor to
>>>>>> the running time of the algorithm. I would be willing to bet you
>>>>>> aren't going to be able to finish a FFT of size 44100*60 for a very
>>>>>> long time.
>>>>>>
>>>>>> The Plot Spectrum command appears to take many small ones and average
>>>>>> them, since you can select the FFT size in the popup window, with a
>>>>>> maximum of 16384. If that's the case I'm not sure why it has a 24
>>>>>> second limit either.
>>>>>>
>>>>>>
>>>>>> Michael
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]>
>> wrote:
>>>>>>>> Computing the spectrum requires all samples to be in memory at once
>>>>>>>> and costs n*log(n), so operating on many seconds of sound is
> unusual.
>>>>>>>> If the spectrum is very stable, e.g. a steady tone, then you
> probably
>>>>>>>> don't need to look at many seconds to extract the spectral
>>>>>>>> information. If the spectrum is changing, then grabbing the
> spectrum
>>>>>>>> of a large interval is in some sense going to smear out or average
>> the
>>>>>>>> overall energy, so again, it's not so useful. Finally, there are
>>>>>>>> numerical issues to worry about when doing a very large Fourier
>>>>>>>> transform to compute the spectrum. What might be useful is to
> compute
>>>>>>>> a sequence of short-term spectra and average their magnitudes to
> get
>> a
>>>>>>>> long-term average spectrum. Audacity could do this in principle,
> but
>>>>>>>> the user would have to provide more parameters and confirm that
>> he/she
>>>>>>>> really wants to do an expensive computation on a long segment of
>> audio.
>>>>>>> Alright. So if I understand well, there is no hidden reason to
> forbid
>>>>>>> spectral analysis on
>>>>>>> a larger sample. O(n log n) is a very reasonable complexity for a
>>>>>>> fourier transform and
>>>>>>> I am ready to wait some more seconds to compute the spectrum for 60
>>>>>>> seconds instead
>>>>>>> of 24 seconds. I will modify the audacity source code for my own
> needs
>>>>>>> in that direction.
>>>>>>>
>>>>>>> Thanks for your quick answer
>>>>>>>
>>>>>>> Julien
>
>
>
> ----------------------------------------------------------------------------
> --
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale

Re: Question about spectral analysis in Audacity

Administrator

| From Martyn Shaw <[hidden email]>
| Tue, 07 Jul 2009 01:21:18 +0100
| Subject: [Audacity-devel] Question about spectral analysis in Audacity

> Hi Phil
>
> Thanks for your input here, very valuable and nice to have somebody on
> board who understands the problems.
>
> I think I probably put in that 'sum-of-squares' code, and I seem to
> remember struggling with it at the time, and that was the best I could do.
>
> Gale is correct in that most people will be looking at music, not
> sinusoids, so we need to have a sensible compromise on actual scale.

> Philip Van Baren wrote:
> > Given the previous conversation it looks like the decision was made to
> > change behavior in 1.3.8 such that a full scale sine wave gives 0dB on the
> > 'plot spectrum' graph, and not duplicate the 1.2.6 behavior.
> >
> > My point is, if this is the goal for 1.3.8, then there is a known
> > normalization factor which will give exactly 0dB peaks for sine tones.
> > Normalizing with sum-of-squares times the window length will get it close,
> > but it won't be exactly 0dB for all window functions and all window lengths.
> >
> > Phil
> >
> > -----Original Message-----
> > From: Gale Andrews [mailto:[hidden email]]
> > Sent: Monday, July 06, 2009 3:55 PM
> > To: [hidden email]
> > Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity
> >
> >
> > | From "Philip Van Baren" <[hidden email]>
> > | Mon, 6 Jul 2009 12:41:48 -0400
> > | Subject: [Audacity-devel] Question about spectral analysis in Audacity
> >> If the goal is to get a full scale sine tone to show 0dB in the spectrum
> >> window, the normalization factor which achieves this is to make the sum of
> >> the window function values = 2.0. (The 2.0 factor comes from the average
> >> value of sin^2 = 0.5)
> >>
> >> The current code normalizes the sum of the squares of the window function
> >> values. This is appropriate if you are trying to normalize for random
> >> signals (it maintains RMS), but it won't give a consistent normalization
> > for
> >> fixed frequency sine tones.
> >>
> >> I've made and tested a patch for this, and verified that it gives 0dB for
> >> full scale sine tones at all FFT lengths. Is this the goal for Audacity
> >> 1.3.8, and if so, should I go ahead and submit the change?
> >
> > Just to refer back to 1.2.6 behaviour (most users of 2.0 will be
> > migrating from 1.2.6), a full scale sine peaked at about +15 dB,
> > while 23.8 seconds of a "typical" pop track peaked at about 0 dB.
> >
> > My assumption would be that people who are analysing tones would
> > be more savvy than those looking at pieces of music. Those looking
> > at pieces of music are probably looking for noise spikes to attenuate.
> > They are likely to be confused if a track normalised to 0 dB peaks at
> > -30 dB in Plot Spectrum, even though the amplitude scale in Spectrum
> > does not relate to the waveform scale. 1.2.6 behaviour "appears
> > intuitive" for music, but are you saying this is inappropriate because
> > RMS is not maintained? Could or should normalisation be different if a
> > tone is presented for analysis (which could be an imported file)?
> >
> > Maybe as you suggest in the "New FFT function" thread, a preference
> > for full scale configuration would be good (we should state against each
> > option what that one is "best for"). Note the lower end of the dB range
> > in the spectrum is already directly affected by the "Meter/Waveform dB
> > range"
> > preference, but the user comments I've seen about this have been
> > negative (on the basis the waveform and spectrum scales aren't really
> > comparable, so it is not "expected" this preference would affect the
> > Spectrum plot).
> >
> >
> >
> > Gale
> >
> >
> >
> >> -----Original Message-----
> >> From: Martyn Shaw [mailto:[hidden email]]
> >> Sent: Wednesday, July 01, 2009 6:38 PM
> >> To: [hidden email]
> >> Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity
> >>
> >>
> >>
> >> Gale Andrews wrote:
> >>> | From Martyn Shaw <[hidden email]>
> >>> | Wed, 01 Jul 2009 01:47:37 +0100
> >> ...
> >>>> The scale of 'Spectrum' stays the same as you change the 'Size'
> >>>> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
> >>>> refers). I didn't adjust the others as I'm not sure what they do and
> >>>> if they are 'right' or 'wrong'
> >>> Adobe9 does not seem capable of opening that PDF here (missing
> >>> components) so can you explain what you mean for the stupid (me)?
> >> I never did like pdf files. Suggest that you get a reader capable of
> >> opening it, or get the rest of the components you need. Works fine
> >> here in Adobe Reader 8.0. The book is excellent, if technical.
> >>
> >> I'll try in two sentences, but this isn't the place for a long
> >> explanation:
> >> If you generate a sine wave and look at it's amplitude with different
> >> window lengths, you'll get about the same value since it 'always'
> >> falls in one frequency bin. If you have a random signal then you can
> >> expect the amplitude to fall by 3dB for every doubling of the FFT
> >> size, since the bins are half the size and so contain only half the
> >> energy.
> >>
> >>> If I change size from 128 to 16384 the increments of both scales
> >>> change (except that for frequency, if I use the linear option).
> >> Again related to the size of the bins. More bins, greater resolution.
> >>
> >> And if
> >>> I look at a particular peak, the dB value is much lower with the
> >>> largest size (is that expected)?
> >> Depends on signal, see above.
> >>
> >>> Did you make progress trying to make the dB values displayed more
> >>> like those in 1.2.6 where the low frequencies are close to -0 dB?
> >>> Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
> >>> shows about -30 dB less in 1.3.8. Have we got a good explanation
> >>> when we are asked about this?
> >> Normalisation. Read the book.
> >>
> >>>>> On my XP box (2.6 GHz 1 GB RAM)
> >>>>> if I select that much or longer it takes 10 -18 seconds before
> > anything
> >>>>> happens. If the audio is over 237.8, the "anything" is the length
> >> warning,
> >>>>> after which the Spectrum displays at once.
> >>>> 'tis less than a second here (for a 1hr 15s file). I get the warning,
> >>>> then the spectrum, as anticipated.
> >>>>
> >>>> Are you still seeing this?
> >>> No, not in my recent ANSI build using wx 2.8.10. The wait is about
> >>> 3 - 5 seconds for an hour long file (FF is running as it was before and
> >>> it has about 40 tabs open as usual, but if I had the upcoming local
> >>> Manual open, FF would have to be running anyway). I got the results
> >>> I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
> >>> that was both with the XP machine several hours after boot and on a
> >>> fresh boot (made no difference). Is that Windows variability again?
> >>> I will try on the Vista machine too.
> >>>
> >>> But anyway, wouldn't you suppose on slow machines with little RAM
> >>> that the waiting time would exceed that where we usually give an .
> >>> effect progress dialogue? Our nominal minimum system requirements
> >>> for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
> >> We should up that, perhaps. A progress dialogue would be good, but
> >> low priority (for me at least).
> >>
> >>> Also I've found what seems to be un-necessary window-switching
> >>> behaviour (is in 1.3.7 as well):
> >>>
> >>> 1. Open Audacity and generate a tone
> >>> 2. Plot Spectrum (close it or leave it open)
> >>> 3. File > New (you will have to task switch or click on the
> >>> correct section of the Taskbar button to see the new
> >>> window, due to another bug we have)
> >>> 4. Import an audio file (because easy to see the difference)
> >>> 5. Plot Spectrum and it appears with the plot of the audio
> >>> file, but the window switches to that for the tone, which
> >>> is confusing.
> >> So it does. I guess these are both on Release_Checklist for our
> >> students to take a hit at?
> >>
> >> TTFN
> >> Martyn
> >>
> >>> Thanks
> >>>
> >>>
> >>> Gale
> >>>
> >>>
> >>>>>> Michael Chinen wrote:
> >>>>>> Are you trying to take THE spectrum of a 60 second segment (with one
> >>>>>> FFT,) or are you interested in finding the average spectrum by taking
> >>>>>> many small FFTs over the duration and averaging it out? These may
> >>>>>> yield similar results but the process is very different.
> >>>>>>
> >>>>>> You probably know this, but I just want to point out that in O(n log
> >>>>>> n), n is in samples, not seconds, so each second adds a big factor to
> >>>>>> the running time of the algorithm. I would be willing to bet you
> >>>>>> aren't going to be able to finish a FFT of size 44100*60 for a very
> >>>>>> long time.
> >>>>>>
> >>>>>> The Plot Spectrum command appears to take many small ones and average
> >>>>>> them, since you can select the FFT size in the popup window, with a
> >>>>>> maximum of 16384. If that's the case I'm not sure why it has a 24
> >>>>>> second limit either.
> >>>>>>
> >>>>>>
> >>>>>> Michael
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue <[hidden email]>
> >> wrote:
> >>>>>>>> Computing the spectrum requires all samples to be in memory at once
> >>>>>>>> and costs n*log(n), so operating on many seconds of sound is
> > unusual.
> >>>>>>>> If the spectrum is very stable, e.g. a steady tone, then you
> > probably
> >>>>>>>> don't need to look at many seconds to extract the spectral
> >>>>>>>> information. If the spectrum is changing, then grabbing the
> > spectrum
> >>>>>>>> of a large interval is in some sense going to smear out or average
> >> the
> >>>>>>>> overall energy, so again, it's not so useful. Finally, there are
> >>>>>>>> numerical issues to worry about when doing a very large Fourier
> >>>>>>>> transform to compute the spectrum. What might be useful is to
> > compute
> >>>>>>>> a sequence of short-term spectra and average their magnitudes to
> > get
> >> a
> >>>>>>>> long-term average spectrum. Audacity could do this in principle,
> > but
> >>>>>>>> the user would have to provide more parameters and confirm that
> >> he/she
> >>>>>>>> really wants to do an expensive computation on a long segment of
> >> audio.
> >>>>>>> Alright. So if I understand well, there is no hidden reason to
> > forbid
> >>>>>>> spectral analysis on
> >>>>>>> a larger sample. O(n log n) is a very reasonable complexity for a
> >>>>>>> fourier transform and
> >>>>>>> I am ready to wait some more seconds to compute the spectrum for 60
> >>>>>>> seconds instead
> >>>>>>> of 24 seconds. I will modify the audacity source code for my own
> > needs
> >>>>>>> in that direction.
> >>>>>>>
> >>>>>>> Thanks for your quick answer
> >>>>>>>
> >>>>>>> Julien

Philip Van Baren

Re: Question about spectral analysis in Audacity

I've submitted the change which normalizes the window such that full scale
sine tones show 0dB for all window functions and all lengths.

If the sine tone doesn't exactly match one of the frequencies in the FFT,
the energy will be split between two bins, and neither will be exactly 0dB
in that case. However, there is a peak interpolation which attempts to
report the actual peak amplitude and frequency. It looks like that
interpolation could use a little touch-up too, because it tends to report
the interpolated peak amplitude a little high.

Phil

-----Original Message-----
From: Gale Andrews [mailto:[hidden email]]
Sent: Monday, July 06, 2009 10:47 PM
To: [hidden email]
Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity

| From Martyn Shaw <[hidden email]>
| Tue, 07 Jul 2009 01:21:18 +0100
| Subject: [Audacity-devel] Question about spectral analysis in Audacity

That is indeed my only point. I'm not suggesting we go back to
1.2.6 behaviour (which you can argue looks "intuitively wrong" for
sinusoids). So getting full scale sinusoids to peak at circa 0 dB
rather than + 15 dB will be an improvement in my view.

But what I am strongly suggesting is that users familiar with 1.2.6
will question the current 1.3.8 scale when looking at music, and
have been doing so.

> Obviously we don't want the scale to change with the window type or
> length so fixing the code would be good, for both types of user.
>
> Is it possible to give 0dB peaks for +-1 sinusoids, then offset that
> by a fixed number of dBs to give 'near 0dB' for typical modern
> over-compressed, limited BW, full of spectral holes, 96-128kbps MP3
> file that people seem to love. I suspect not as window types /
> lengths are changed. But if you know a way then let us know by doing
> it...

I think an "average user" might well accept amplitude falling away with
increased window lengths or changing with window types (especially
since they may rarely switch sizes). Can we aim to get it "near 0 dB" at
the default 128 size, which is the smallest?

> Maybe an option (music/sines?) in the window? (but I used up all the
> space with the 'Replot' and 'Grids' options I think). Maybe we could
> save some space by calling 'Function:' 'Window:' then loosing the
> 'window' word off the choices?
> Or by loosing 'frequency' in the 'Axis:' box?

Looks like we need the space for "Autocorrelation" in the "Algorithm"
text, though. Could we assume that "music" is the default, so we only
need the one checkbox "Sine view" or similar?

Gale

> Philip Van Baren wrote:
> > Given the previous conversation it looks like the decision was made to
> > change behavior in 1.3.8 such that a full scale sine wave gives 0dB on
the
> > 'plot spectrum' graph, and not duplicate the 1.2.6 behavior.
> >
> > My point is, if this is the goal for 1.3.8, then there is a known
> > normalization factor which will give exactly 0dB peaks for sine tones.
> > Normalizing with sum-of-squares times the window length will get it
close,
> > but it won't be exactly 0dB for all window functions and all window
lengths.
> >
> > Phil
> >
> > -----Original Message-----
> > From: Gale Andrews [mailto:[hidden email]]
> > Sent: Monday, July 06, 2009 3:55 PM
> > To: [hidden email]
> > Subject: Re: [Audacity-devel] Question about spectral analysis in
Audacity
> >
> >
> > | From "Philip Van Baren" <[hidden email]>
> > | Mon, 6 Jul 2009 12:41:48 -0400
> > | Subject: [Audacity-devel] Question about spectral analysis in Audacity
> >> If the goal is to get a full scale sine tone to show 0dB in the
spectrum
> >> window, the normalization factor which achieves this is to make the sum
of
> >> the window function values = 2.0. (The 2.0 factor comes from the
average
> >> value of sin^2 = 0.5)
> >>
> >> The current code normalizes the sum of the squares of the window
function
> >> values. This is appropriate if you are trying to normalize for random
> >> signals (it maintains RMS), but it won't give a consistent
normalization
> > for
> >> fixed frequency sine tones.
> >>
> >> I've made and tested a patch for this, and verified that it gives 0dB
for
> >> full scale sine tones at all FFT lengths. Is this the goal for
Audacity

> >> 1.3.8, and if so, should I go ahead and submit the change?
> >
> > Just to refer back to 1.2.6 behaviour (most users of 2.0 will be
> > migrating from 1.2.6), a full scale sine peaked at about +15 dB,
> > while 23.8 seconds of a "typical" pop track peaked at about 0 dB.
> >
> > My assumption would be that people who are analysing tones would
> > be more savvy than those looking at pieces of music. Those looking
> > at pieces of music are probably looking for noise spikes to attenuate.
> > They are likely to be confused if a track normalised to 0 dB peaks at
> > -30 dB in Plot Spectrum, even though the amplitude scale in Spectrum
> > does not relate to the waveform scale. 1.2.6 behaviour "appears
> > intuitive" for music, but are you saying this is inappropriate because
> > RMS is not maintained? Could or should normalisation be different if a
> > tone is presented for analysis (which could be an imported file)?
> >
> > Maybe as you suggest in the "New FFT function" thread, a preference
> > for full scale configuration would be good (we should state against each
> > option what that one is "best for"). Note the lower end of the dB range
> > in the spectrum is already directly affected by the "Meter/Waveform dB
> > range"
> > preference, but the user comments I've seen about this have been
> > negative (on the basis the waveform and spectrum scales aren't really
> > comparable, so it is not "expected" this preference would affect the
> > Spectrum plot).
> >
> >
> >
> > Gale
> >
> >
> >
> >> -----Original Message-----
> >> From: Martyn Shaw [mailto:[hidden email]]
> >> Sent: Wednesday, July 01, 2009 6:38 PM
> >> To: [hidden email]
> >> Subject: Re: [Audacity-devel] Question about spectral analysis in

Audacity

> >>
> >>
> >>
> >> Gale Andrews wrote:
> >>> | From Martyn Shaw <[hidden email]>
> >>> | Wed, 01 Jul 2009 01:47:37 +0100
> >> ...
> >>>> The scale of 'Spectrum' stays the same as you change the 'Size'
> >>>> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
> >>>> refers). I didn't adjust the others as I'm not sure what they do and

> >>>> if they are 'right' or 'wrong'
> >>> Adobe9 does not seem capable of opening that PDF here (missing
> >>> components) so can you explain what you mean for the stupid (me)?
> >> I never did like pdf files. Suggest that you get a reader capable of
> >> opening it, or get the rest of the components you need. Works fine
> >> here in Adobe Reader 8.0. The book is excellent, if technical.
> >>
> >> I'll try in two sentences, but this isn't the place for a long
> >> explanation:
> >> If you generate a sine wave and look at it's amplitude with different
> >> window lengths, you'll get about the same value since it 'always'
> >> falls in one frequency bin. If you have a random signal then you can
> >> expect the amplitude to fall by 3dB for every doubling of the FFT
> >> size, since the bins are half the size and so contain only half the
> >> energy.
> >>
> >>> If I change size from 128 to 16384 the increments of both scales
> >>> change (except that for frequency, if I use the linear option).
> >> Again related to the size of the bins. More bins, greater resolution.
> >>
> >> And if
> >>> I look at a particular peak, the dB value is much lower with the
> >>> largest size (is that expected)?
> >> Depends on signal, see above.
> >>
> >>> Did you make progress trying to make the dB values displayed more
> >>> like those in 1.2.6 where the low frequencies are close to -0 dB?
> >>> Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
> >>> shows about -30 dB less in 1.3.8. Have we got a good explanation
> >>> when we are asked about this?
> >> Normalisation. Read the book.
> >>
> >>>>> On my XP box (2.6 GHz 1 GB RAM)
> >>>>> if I select that much or longer it takes 10 -18 seconds before
> > anything
> >>>>> happens. If the audio is over 237.8, the "anything" is the length
> >> warning,
> >>>>> after which the Spectrum displays at once.
> >>>> 'tis less than a second here (for a 1hr 15s file). I get the

warning,
> >>>> then the spectrum, as anticipated.
> >>>>
> >>>> Are you still seeing this?
> >>> No, not in my recent ANSI build using wx 2.8.10. The wait is about
> >>> 3 - 5 seconds for an hour long file (FF is running as it was before
and

> >>> it has about 40 tabs open as usual, but if I had the upcoming local
> >>> Manual open, FF would have to be running anyway). I got the results
> >>> I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
> >>> that was both with the XP machine several hours after boot and on a
> >>> fresh boot (made no difference). Is that Windows variability again?
> >>> I will try on the Vista machine too.
> >>>
> >>> But anyway, wouldn't you suppose on slow machines with little RAM
> >>> that the waiting time would exceed that where we usually give an .
> >>> effect progress dialogue? Our nominal minimum system requirements
> >>> for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
> >> We should up that, perhaps. A progress dialogue would be good, but
> >> low priority (for me at least).
> >>
> >>> Also I've found what seems to be un-necessary window-switching
> >>> behaviour (is in 1.3.7 as well):
> >>>
> >>> 1. Open Audacity and generate a tone
> >>> 2. Plot Spectrum (close it or leave it open)
> >>> 3. File > New (you will have to task switch or click on the
> >>> correct section of the Taskbar button to see the new
> >>> window, due to another bug we have)
> >>> 4. Import an audio file (because easy to see the difference)
> >>> 5. Plot Spectrum and it appears with the plot of the audio
> >>> file, but the window switches to that for the tone, which
> >>> is confusing.
> >> So it does. I guess these are both on Release_Checklist for our
> >> students to take a hit at?
> >>
> >> TTFN
> >> Martyn
> >>
> >>> Thanks
> >>>
> >>>
> >>> Gale
> >>>
> >>>
> >>>>>> Michael Chinen wrote:
> >>>>>> Are you trying to take THE spectrum of a 60 second segment (with

one
> >>>>>> FFT,) or are you interested in finding the average spectrum by
taking
> >>>>>> many small FFTs over the duration and averaging it out? These may
> >>>>>> yield similar results but the process is very different.
> >>>>>>
> >>>>>> You probably know this, but I just want to point out that in O(n
log
> >>>>>> n), n is in samples, not seconds, so each second adds a big factor
to
> >>>>>> the running time of the algorithm. I would be willing to bet you
> >>>>>> aren't going to be able to finish a FFT of size 44100*60 for a very
> >>>>>> long time.
> >>>>>>
> >>>>>> The Plot Spectrum command appears to take many small ones and
average

> >>>>>> them, since you can select the FFT size in the popup window, with a
> >>>>>> maximum of 16384. If that's the case I'm not sure why it has a 24
> >>>>>> second limit either.
> >>>>>>
> >>>>>>
> >>>>>> Michael
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue

<[hidden email]>
> >> wrote:
> >>>>>>>> Computing the spectrum requires all samples to be in memory at
once
> >>>>>>>> and costs n*log(n), so operating on many seconds of sound is
> > unusual.
> >>>>>>>> If the spectrum is very stable, e.g. a steady tone, then you
> > probably
> >>>>>>>> don't need to look at many seconds to extract the spectral
> >>>>>>>> information. If the spectrum is changing, then grabbing the
> > spectrum
> >>>>>>>> of a large interval is in some sense going to smear out or
average

> >> the
> >>>>>>>> overall energy, so again, it's not so useful. Finally, there are
> >>>>>>>> numerical issues to worry about when doing a very large Fourier
> >>>>>>>> transform to compute the spectrum. What might be useful is to
> > compute
> >>>>>>>> a sequence of short-term spectra and average their magnitudes to
> > get
> >> a
> >>>>>>>> long-term average spectrum. Audacity could do this in principle,
> > but
> >>>>>>>> the user would have to provide more parameters and confirm that
> >> he/she
> >>>>>>>> really wants to do an expensive computation on a long segment of
> >> audio.
> >>>>>>> Alright. So if I understand well, there is no hidden reason to
> > forbid
> >>>>>>> spectral analysis on
> >>>>>>> a larger sample. O(n log n) is a very reasonable complexity for a
> >>>>>>> fourier transform and
> >>>>>>> I am ready to wait some more seconds to compute the spectrum for

60
> >>>>>>> seconds instead
> >>>>>>> of 24 seconds. I will modify the audacity source code for my own
> > needs
> >>>>>>> in that direction.
> >>>>>>>
> >>>>>>> Thanks for your quick answer
> >>>>>>>
> >>>>>>> Julien

----------------------------------------------------------------------------
--
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: Question about spectral analysis in Audacity

Thanks Phil!

Martyn

Philip Van Baren wrote:

> I've submitted the change which normalizes the window such that full scale
> sine tones show 0dB for all window functions and all lengths.
>
> If the sine tone doesn't exactly match one of the frequencies in the FFT,
> the energy will be split between two bins, and neither will be exactly 0dB
> in that case. However, there is a peak interpolation which attempts to
> report the actual peak amplitude and frequency. It looks like that
> interpolation could use a little touch-up too, because it tends to report
> the interpolated peak amplitude a little high.
>
> Phil
>
> -----Original Message-----
> From: Gale Andrews [mailto:[hidden email]]
> Sent: Monday, July 06, 2009 10:47 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity
>
>
> | From Martyn Shaw <[hidden email]>
> | Tue, 07 Jul 2009 01:21:18 +0100
> | Subject: [Audacity-devel] Question about spectral analysis in Audacity
>> Hi Phil
>>
>> Thanks for your input here, very valuable and nice to have somebody on
>> board who understands the problems.
>>
>> I think I probably put in that 'sum-of-squares' code, and I seem to
>> remember struggling with it at the time, and that was the best I could do.
>>
>> Gale is correct in that most people will be looking at music, not
>> sinusoids, so we need to have a sensible compromise on actual scale.
>
> That is indeed my only point. I'm not suggesting we go back to
> 1.2.6 behaviour (which you can argue looks "intuitively wrong" for
> sinusoids). So getting full scale sinusoids to peak at circa 0 dB
> rather than + 15 dB will be an improvement in my view.
>
> But what I am strongly suggesting is that users familiar with 1.2.6
> will question the current 1.3.8 scale when looking at music, and
> have been doing so.
>
>
>> Obviously we don't want the scale to change with the window type or
>> length so fixing the code would be good, for both types of user.
>>
>> Is it possible to give 0dB peaks for +-1 sinusoids, then offset that
>> by a fixed number of dBs to give 'near 0dB' for typical modern
>> over-compressed, limited BW, full of spectral holes, 96-128kbps MP3
>> file that people seem to love. I suspect not as window types /
>> lengths are changed. But if you know a way then let us know by doing
>> it...
>
> I think an "average user" might well accept amplitude falling away with
> increased window lengths or changing with window types (especially
> since they may rarely switch sizes). Can we aim to get it "near 0 dB" at
> the default 128 size, which is the smallest?
>
>
>> Maybe an option (music/sines?) in the window? (but I used up all the
>> space with the 'Replot' and 'Grids' options I think). Maybe we could
>> save some space by calling 'Function:' 'Window:' then loosing the
>> 'window' word off the choices?
>> Or by loosing 'frequency' in the 'Axis:' box?
>
> Looks like we need the space for "Autocorrelation" in the "Algorithm"
> text, though. Could we assume that "music" is the default, so we only
> need the one checkbox "Sine view" or similar?
>
>
> Gale
>
>
>
>> Philip Van Baren wrote:
>>> Given the previous conversation it looks like the decision was made to
>>> change behavior in 1.3.8 such that a full scale sine wave gives 0dB on
> the
>>> 'plot spectrum' graph, and not duplicate the 1.2.6 behavior.
>>>
>>> My point is, if this is the goal for 1.3.8, then there is a known
>>> normalization factor which will give exactly 0dB peaks for sine tones.
>>> Normalizing with sum-of-squares times the window length will get it
> close,
>>> but it won't be exactly 0dB for all window functions and all window
> lengths.
>>> Phil
>>>
>>> -----Original Message-----
>>> From: Gale Andrews [mailto:[hidden email]]
>>> Sent: Monday, July 06, 2009 3:55 PM
>>> To: [hidden email]
>>> Subject: Re: [Audacity-devel] Question about spectral analysis in
> Audacity
>>>
>>> | From "Philip Van Baren" <[hidden email]>
>>> | Mon, 6 Jul 2009 12:41:48 -0400
>>> | Subject: [Audacity-devel] Question about spectral analysis in Audacity
>>>> If the goal is to get a full scale sine tone to show 0dB in the
> spectrum
>>>> window, the normalization factor which achieves this is to make the sum
> of
>>>> the window function values = 2.0. (The 2.0 factor comes from the
> average
>>>> value of sin^2 = 0.5)
>>>>
>>>> The current code normalizes the sum of the squares of the window
> function
>>>> values. This is appropriate if you are trying to normalize for random
>>>> signals (it maintains RMS), but it won't give a consistent
> normalization
>>> for
>>>> fixed frequency sine tones.
>>>>
>>>> I've made and tested a patch for this, and verified that it gives 0dB
> for
>>>> full scale sine tones at all FFT lengths. Is this the goal for
> Audacity
>>>> 1.3.8, and if so, should I go ahead and submit the change?
>>> Just to refer back to 1.2.6 behaviour (most users of 2.0 will be
>>> migrating from 1.2.6), a full scale sine peaked at about +15 dB,
>>> while 23.8 seconds of a "typical" pop track peaked at about 0 dB.
>>>
>>> My assumption would be that people who are analysing tones would
>>> be more savvy than those looking at pieces of music. Those looking
>>> at pieces of music are probably looking for noise spikes to attenuate.
>>> They are likely to be confused if a track normalised to 0 dB peaks at
>>> -30 dB in Plot Spectrum, even though the amplitude scale in Spectrum
>>> does not relate to the waveform scale. 1.2.6 behaviour "appears
>>> intuitive" for music, but are you saying this is inappropriate because
>>> RMS is not maintained? Could or should normalisation be different if a
>>> tone is presented for analysis (which could be an imported file)?
>>>
>>> Maybe as you suggest in the "New FFT function" thread, a preference
>>> for full scale configuration would be good (we should state against each
>>> option what that one is "best for"). Note the lower end of the dB range
>>> in the spectrum is already directly affected by the "Meter/Waveform dB
>>> range"
>>> preference, but the user comments I've seen about this have been
>>> negative (on the basis the waveform and spectrum scales aren't really
>>> comparable, so it is not "expected" this preference would affect the
>>> Spectrum plot).
>>>
>>>
>>>
>>> Gale
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Martyn Shaw [mailto:[hidden email]]
>>>> Sent: Wednesday, July 01, 2009 6:38 PM
>>>> To: [hidden email]
>>>> Subject: Re: [Audacity-devel] Question about spectral analysis in
> Audacity
>>>>
>>>>
>>>> Gale Andrews wrote:
>>>>> | From Martyn Shaw <[hidden email]>
>>>>> | Wed, 01 Jul 2009 01:47:37 +0100
>>>> ...
>>>>>> The scale of 'Spectrum' stays the same as you change the 'Size'
>>>>>> parameter (13.4.5 of http://www.nrbook.com/a/bookcpdf/c13-4.pdf
>>>>>> refers). I didn't adjust the others as I'm not sure what they do and
>
>>>>>> if they are 'right' or 'wrong'
>>>>> Adobe9 does not seem capable of opening that PDF here (missing
>>>>> components) so can you explain what you mean for the stupid (me)?
>>>> I never did like pdf files. Suggest that you get a reader capable of
>>>> opening it, or get the rest of the components you need. Works fine
>>>> here in Adobe Reader 8.0. The book is excellent, if technical.
>>>>
>>>> I'll try in two sentences, but this isn't the place for a long
>>>> explanation:
>>>> If you generate a sine wave and look at it's amplitude with different
>>>> window lengths, you'll get about the same value since it 'always'
>>>> falls in one frequency bin. If you have a random signal then you can
>>>> expect the amplitude to fall by 3dB for every doubling of the FFT
>>>> size, since the bins are half the size and so contain only half the
>>>> energy.
>>>>
>>>>> If I change size from 128 to 16384 the increments of both scales
>>>>> change (except that for frequency, if I use the linear option).
>>>> Again related to the size of the bins. More bins, greater resolution.
>>>>
>>>> And if
>>>>> I look at a particular peak, the dB value is much lower with the
>>>>> largest size (is that expected)?
>>>> Depends on signal, see above.
>>>>
>>>>> Did you make progress trying to make the dB values displayed more
>>>>> like those in 1.2.6 where the low frequencies are close to -0 dB?
>>>>> Doing an identical plot of the same audio in 1.2.6 and 1.3.8 still
>>>>> shows about -30 dB less in 1.3.8. Have we got a good explanation
>>>>> when we are asked about this?
>>>> Normalisation. Read the book.
>>>>
>>>>>>> On my XP box (2.6 GHz 1 GB RAM)
>>>>>>> if I select that much or longer it takes 10 -18 seconds before
>>> anything
>>>>>>> happens. If the audio is over 237.8, the "anything" is the length
>>>> warning,
>>>>>>> after which the Spectrum displays at once.
>>>>>> 'tis less than a second here (for a 1hr 15s file). I get the
> warning,
>>>>>> then the spectrum, as anticipated.
>>>>>>
>>>>>> Are you still seeing this?
>>>>> No, not in my recent ANSI build using wx 2.8.10. The wait is about
>>>>> 3 - 5 seconds for an hour long file (FF is running as it was before
> and
>>>>> it has about 40 tabs open as usual, but if I had the upcoming local
>>>>> Manual open, FF would have to be running anyway). I got the results
>>>>> I gave (10 - 18 seconds delay) in my 2.8.9 build from yesterday, and
>>>>> that was both with the XP machine several hours after boot and on a
>>>>> fresh boot (made no difference). Is that Windows variability again?
>>>>> I will try on the Vista machine too.
>>>>>
>>>>> But anyway, wouldn't you suppose on slow machines with little RAM
>>>>> that the waiting time would exceed that where we usually give an .
>>>>> effect progress dialogue? Our nominal minimum system requirements
>>>>> for Windows XP and earlier are still only 64 - 128 MB RAM, 300 MHz.
>>>> We should up that, perhaps. A progress dialogue would be good, but
>>>> low priority (for me at least).
>>>>
>>>>> Also I've found what seems to be un-necessary window-switching
>>>>> behaviour (is in 1.3.7 as well):
>>>>>
>>>>> 1. Open Audacity and generate a tone
>>>>> 2. Plot Spectrum (close it or leave it open)
>>>>> 3. File > New (you will have to task switch or click on the
>>>>> correct section of the Taskbar button to see the new
>>>>> window, due to another bug we have)
>>>>> 4. Import an audio file (because easy to see the difference)
>>>>> 5. Plot Spectrum and it appears with the plot of the audio
>>>>> file, but the window switches to that for the tone, which
>>>>> is confusing.
>>>> So it does. I guess these are both on Release_Checklist for our
>>>> students to take a hit at?
>>>>
>>>> TTFN
>>>> Martyn
>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>>>>> Michael Chinen wrote:
>>>>>>>> Are you trying to take THE spectrum of a 60 second segment (with
> one
>>>>>>>> FFT,) or are you interested in finding the average spectrum by
> taking
>>>>>>>> many small FFTs over the duration and averaging it out? These may
>>>>>>>> yield similar results but the process is very different.
>>>>>>>>
>>>>>>>> You probably know this, but I just want to point out that in O(n
> log
>>>>>>>> n), n is in samples, not seconds, so each second adds a big factor
> to
>>>>>>>> the running time of the algorithm. I would be willing to bet you
>>>>>>>> aren't going to be able to finish a FFT of size 44100*60 for a very
>>>>>>>> long time.
>>>>>>>>
>>>>>>>> The Plot Spectrum command appears to take many small ones and
> average
>>>>>>>> them, since you can select the FFT size in the popup window, with a
>>>>>>>> maximum of 16384. If that's the case I'm not sure why it has a 24
>>>>>>>> second limit either.
>>>>>>>>
>>>>>>>>
>>>>>>>> Michael
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Fri, Jul 18, 2008 at 2:24 PM, Julien F. Vanegue
> <[hidden email]>
>>>> wrote:
>>>>>>>>>> Computing the spectrum requires all samples to be in memory at
> once
>>>>>>>>>> and costs n*log(n), so operating on many seconds of sound is
>>> unusual.
>>>>>>>>>> If the spectrum is very stable, e.g. a steady tone, then you
>>> probably
>>>>>>>>>> don't need to look at many seconds to extract the spectral
>>>>>>>>>> information. If the spectrum is changing, then grabbing the
>>> spectrum
>>>>>>>>>> of a large interval is in some sense going to smear out or
> average
>>>> the
>>>>>>>>>> overall energy, so again, it's not so useful. Finally, there are
>>>>>>>>>> numerical issues to worry about when doing a very large Fourier
>>>>>>>>>> transform to compute the spectrum. What might be useful is to
>>> compute
>>>>>>>>>> a sequence of short-term spectra and average their magnitudes to
>>> get
>>>> a
>>>>>>>>>> long-term average spectrum. Audacity could do this in principle,
>>> but
>>>>>>>>>> the user would have to provide more parameters and confirm that
>>>> he/she
>>>>>>>>>> really wants to do an expensive computation on a long segment of
>>>> audio.
>>>>>>>>> Alright. So if I understand well, there is no hidden reason to
>>> forbid
>>>>>>>>> spectral analysis on
>>>>>>>>> a larger sample. O(n log n) is a very reasonable complexity for a
>>>>>>>>> fourier transform and
>>>>>>>>> I am ready to wait some more seconds to compute the spectrum for
> 60
>>>>>>>>> seconds instead
>>>>>>>>> of 24 seconds. I will modify the audacity source code for my own
>>> needs
>>>>>>>>> in that direction.
>>>>>>>>>
>>>>>>>>> Thanks for your quick answer
>>>>>>>>>
>>>>>>>>> Julien
>
>
>
> ----------------------------------------------------------------------------
> --
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>