## audacity-devel

 Re: [Audacity-devel] Question about spectral analysis in Audacity (Julien F. Vanegue) From: Roger Dannenberg - 2008-07-18 18:16:25 ```> When selecting the content of a track and requesting Audacity > to show the spectrum, I noticed that it wont work if the selection > is bigger than 23 seconds (or so). 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. -Roger ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Julien F. Vanegue - 2008-07-18 18:22:31 ```> 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] dynamic module example? From: Roger Dannenberg - 2008-07-18 18:24:36 ``` From early discussions, I had the impression there were some features in Audacity that are loaded dynamically. I'm still getting my head around the code, and I don't really understand how this is done or see where to look. As we are finally getting some traction on midi-to-score alignment, can someone point me to the best model to follow in introducing an experimental Audacity extension like this? We're making good progress, but I don't want to check anything in until our changes can be safely and conveniently enabled and disabled or isolated from the main code base. -Roger ```
 Re: [Audacity-devel] dynamic module example? From: Leland - 2008-07-18 19:03:31 ```Roger Dannenberg wrote: > From early discussions, I had the impression there were some features > in Audacity that are loaded dynamically. I'm still getting my head > around the code, and I don't really understand how this is done or see > where to look. As we are finally getting some traction on midi-to-score > alignment, can someone point me to the best model to follow in > introducing an experimental Audacity extension like this? We're making > good progress, but I don't want to check anything in until our changes > can be safely and conveniently enabled and disabled or isolated from the > main code base. > Hi Roger, I'm (slowly) working on one right now and have another in the hopper after this first one. Remember though, this is VERY early in the game of loadable modules and you're bound to run into needing something that isn't currently provided. For instance, my first module needed to add a menu item to expose it to the user. Unfortunately, the way our menu system is written there wasn't an existing function to allow this. So, I added the InsertItem() method. For my next module, I will need to add another top level menu, so there's a new InsertMenu() method coming. I don't expect these "hacks" to remain forever, but until we start tinkering around with this new facility we won't know what interfaces we need in the main code. But, basically, you code your module just like you would if you were going to include the source directly in the main Audacity tree. Due to header dependencies, you have to add several of the Audacity subdirectories to the include path list. And it's similar for the library path list, just not as bad. You must also add "audacity.lib" (and wx libs) to your list of library dependencies. Once you have it built, just put it in a subdirectory called "modules" wherever Audacity.exe resides. I'll try to get my code presentable in the next few days and I'll post it somewhere for you to peruse. It currently works on Windows and OSX, but it shouldn't take me too long to get the Linux bits put in. Leland ```
 Re: [Audacity-devel] dynamic module example? From: Martyn Shaw - 2008-07-23 00:25:58 ```Hi Leland I'm looking forward to this, 'cos then I can put my 'convolver' somewhere, but not in the main code to confuse most people. It needs to go on the effects menu somewhere, and call up a simple dialog, then use an external dll to do the processing. Is that in the realms of possibility? TTFN Martyn Leland wrote: > Roger Dannenberg wrote: >> From early discussions, I had the impression there were some features >> in Audacity that are loaded dynamically. I'm still getting my head >> around the code, and I don't really understand how this is done or see >> where to look. As we are finally getting some traction on midi-to-score >> alignment, can someone point me to the best model to follow in >> introducing an experimental Audacity extension like this? We're making >> good progress, but I don't want to check anything in until our changes >> can be safely and conveniently enabled and disabled or isolated from the >> main code base. >> > Hi Roger, > > I'm (slowly) working on one right now and have another in the hopper > after this first one. Remember though, this is VERY early in the game > of loadable modules and you're bound to run into needing something that > isn't currently provided. > > For instance, my first module needed to add a menu item to expose it to > the user. Unfortunately, the way our menu system is written there > wasn't an existing function to allow this. So, I added the InsertItem() > method. For my next module, I will need to add another top level menu, > so there's a new InsertMenu() method coming. > > I don't expect these "hacks" to remain forever, but until we start > tinkering around with this new facility we won't know what interfaces we > need in the main code. > > But, basically, you code your module just like you would if you were > going to include the source directly in the main Audacity tree. Due to > header dependencies, you have to add several of the Audacity > subdirectories to the include path list. And it's similar for the > library path list, just not as bad. > > You must also add "audacity.lib" (and wx libs) to your list of library > dependencies. > > Once you have it built, just put it in a subdirectory called "modules" > wherever Audacity.exe resides. > > I'll try to get my code presentable in the next few days and I'll post > it somewhere for you to peruse. It currently works on Windows and OSX, > but it shouldn't take me too long to get the Linux bits put in. > > Leland > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-devel] dynamic module example? From: Leland - 2008-07-25 03:46:51 ```Martyn Shaw wrote: > Hi Leland > > I'm looking forward to this, 'cos then I can put my 'convolver' > somewhere, but not in the main code to confuse most people. It needs > to go on the effects menu somewhere, and call up a simple dialog, then > use an external dll to do the processing. Is that in the realms of > possibility? > Sorry Martyn, Been on my death bed for that past week. :-) Anyway, yes, that is absolutely possible and I'm guessing will probably be one of the most common uses for this new fangled doohickey. I've gotten a bit further on my module, but I didn't feel much like working on it while ill. All perky again, so I should be able to get back to it now. Actually, if you want, I can send it to you as-is so you can get started on yours as well. There's nothing to it really. Especially since you already have a working effect. All you'd have to do is put in the glue. Leland ```
 Re: [Audacity-devel] dynamic module example? From: Martyn Shaw - 2008-07-25 23:24:33 ```Hi Leland Sorry to hear you've been unwell, but glad to hear you're mended now. Recent commits seem to indicate that you are back on form! I'll pass for now on an early send, since I'm off on holiday shortly and have a door to paint and install etc etc. But I am still looking forward to it! Martyn Leland wrote: > Martyn Shaw wrote: >> Hi Leland >> >> I'm looking forward to this, 'cos then I can put my 'convolver' >> somewhere, but not in the main code to confuse most people. It needs >> to go on the effects menu somewhere, and call up a simple dialog, then >> use an external dll to do the processing. Is that in the realms of >> possibility? >> > Sorry Martyn, > > Been on my death bed for that past week. :-) > > Anyway, yes, that is absolutely possible and I'm guessing will probably > be one of the most common uses for this new fangled doohickey. > > I've gotten a bit further on my module, but I didn't feel much like > working on it while ill. All perky again, so I should be able to get > back to it now. > > Actually, if you want, I can send it to you as-is so you can get started > on yours as well. There's nothing to it really. Especially since you > already have a working effect. All you'd have to do is put in the glue. > > Leland > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-devel] dynamic module example? From: James Crook - 2008-07-18 23:17:45 ```mod-script-pipe is currently the only wxWidgets aware module that is dynamically loaded. Like Leland's initial modules, it's very hackery and isn't a blueprint for the future. The general plan is to have a scheme for registering 'things' where things can be - menu items - commands (not the same thing as menu items!) - main-page-pages - preference-page-pages - track types - images - toolbars - buttons -..... The general plan is also to be able to request 'things' as dependencies. At initialisation there will be cycles of making resources available and of requesting resources. For now though we'll just add facilities as we need them until the requirements become clearer. To avoid issues with version mismatches, we'll mandate that modules are only compatible with Audacity of the same version number - until we have time to evolve a more flexible scheme. For the analysis (non GUI) part of alignment, please use a Vamp effect. How to do this may need further discussion! That way we can later plug in different alignment routines to the new GUI elements you produce. The fastest way forward is to tell us what facilities you need, what the interface you would like to have is. Discussion will probably happen mostly on wiki. --James. Roger Dannenberg wrote: > From early discussions, I had the impression there were some features > in Audacity that are loaded dynamically. I'm still getting my head > around the code, and I don't really understand how this is done or see > where to look. As we are finally getting some traction on midi-to-score > alignment, can someone point me to the best model to follow in > introducing an experimental Audacity extension like this? We're making > good progress, but I don't want to check anything in until our changes > can be safely and conveniently enabled and disabled or isolated from the > main code base. > > -Roger ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: - 2009-06-29 21:43:19 ```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 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 ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Martyn Shaw - 2009-07-01 01:13:12 ``` gale@... 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 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 > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Gale Andrews - 2009-07-01 21:10:56 ```| From Martyn Shaw | Wed, 01 Jul 2009 01:47:37 +0100 | Subject: [Audacity-devel] Question about spectral analysis in Audacity > gale@... 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 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 > > audacity-devel@... > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > ------------------------------------------------------------------------------ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Martyn Shaw - 2009-07-01 22:38:35 ``` Gale Andrews wrote: > | From Martyn Shaw > | 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 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 >>> audacity-devel@... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> audacity-devel mailing list >> audacity-devel@... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > ------------------------------------------------------------------------------ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Gale Andrews - 2009-07-03 01:21:22 ```| From Martyn Shaw | Wed, 01 Jul 2009 23:37:39 +0100 | Subject: [Audacity-devel] Question about spectral analysis in Audacity > Gale Andrews wrote: > > | From Martyn Shaw > > | 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 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 > >>> audacity-devel@... > >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel > >>> > >> ------------------------------------------------------------------------------ > >> _______________________________________________ > >> audacity-devel mailing list > >> audacity-devel@... > >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > > audacity-devel mailing list > > audacity-devel@... > > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > ------------------------------------------------------------------------------ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Martyn Shaw - 2009-07-04 01:17:32 ``` Gale Andrews wrote: > | From Martyn Shaw > | Wed, 01 Jul 2009 23:37:39 +0100 > | Subject: [Audacity-devel] Question about spectral analysis in Audacity >> Gale Andrews wrote: >>> | From Martyn Shaw >>> | 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 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 >>>>> audacity-devel@... >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> audacity-devel mailing list >>>> audacity-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> audacity-devel mailing list >>> audacity-devel@... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> audacity-devel mailing list >> audacity-devel@... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > ------------------------------------------------------------------------------ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Gale Andrews - 2009-07-04 02:35:01 ```| From Martyn Shaw | Sat, 04 Jul 2009 01:28:32 +0100 | Subject: [Audacity-devel] Question about spectral analysis in Audacity > Gale Andrews wrote: > > | From Martyn Shaw > > | Wed, 01 Jul 2009 23:37:39 +0100 > > | Subject: [Audacity-devel] Question about spectral analysis in Audacity > >> Gale Andrews wrote: > >>> | From Martyn Shaw > >>> | 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 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 ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Philip Van Baren - 2009-07-06 16:42:11 ```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:martynshaw99@...] Sent: Wednesday, July 01, 2009 6:38 PM To: audacity-devel@... Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity Gale Andrews wrote: > | From Martyn Shaw > | 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 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 >>> audacity-devel@... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >> ---------------------------------------------------------------------------- -- >> _______________________________________________ >> audacity-devel mailing list >> audacity-devel@... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > > ---------------------------------------------------------------------------- -- > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ---------------------------------------------------------------------------- -- _______________________________________________ audacity-devel mailing list audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Gale Andrews - 2009-07-06 19:54:40 ```| From "Philip Van Baren" | 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:martynshaw99@...] > Sent: Wednesday, July 01, 2009 6:38 PM > To: audacity-devel@... > Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity > > > > Gale Andrews wrote: > > | From Martyn Shaw > > | 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 > 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 > >>> ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Philip Van Baren - 2009-07-06 22:26:20 ```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:gale@...] Sent: Monday, July 06, 2009 3:55 PM To: audacity-devel@... Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity | From "Philip Van Baren" | 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:martynshaw99@...] > Sent: Wednesday, July 01, 2009 6:38 PM > To: audacity-devel@... > Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity > > > > Gale Andrews wrote: > > | From Martyn Shaw > > | 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 > 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 audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Martyn Shaw - 2009-07-07 00:42:46 ```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:gale@...] > Sent: Monday, July 06, 2009 3:55 PM > To: audacity-devel@... > Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity > > > | From "Philip Van Baren" > | 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:martynshaw99@...] >> Sent: Wednesday, July 01, 2009 6:38 PM >> To: audacity-devel@... >> Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity >> >> >> >> Gale Andrews wrote: >>> | From Martyn Shaw >>> | 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 >> 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 > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > > > ------------------------------------------------------------------------------ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Gale Andrews - 2009-07-07 03:03:50 ```| From Martyn Shaw | 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:gale@...] > > Sent: Monday, July 06, 2009 3:55 PM > > To: audacity-devel@... > > Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity > > > > > > | From "Philip Van Baren" > > | 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:martynshaw99@...] > >> Sent: Wednesday, July 01, 2009 6:38 PM > >> To: audacity-devel@... > >> Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity > >> > >> > >> > >> Gale Andrews wrote: > >>> | From Martyn Shaw > >>> | 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 > >> 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 ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Philip Van Baren - 2009-07-07 16:04:17 ```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:gale@...] Sent: Monday, July 06, 2009 10:47 PM To: audacity-devel@... Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity | From Martyn Shaw | 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:gale@...] > > Sent: Monday, July 06, 2009 3:55 PM > > To: audacity-devel@... > > Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity > > > > > > | From "Philip Van Baren" > > | 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:martynshaw99@...] > >> Sent: Wednesday, July 01, 2009 6:38 PM > >> To: audacity-devel@... > >> Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity > >> > >> > >> > >> Gale Andrews wrote: > >>> | From Martyn Shaw > >>> | 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 > >> 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 audacity-devel@... https://lists.sourceforge.net/lists/listinfo/audacity-devel ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Martyn Shaw - 2009-07-07 21:10:37 ```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:gale@...] > Sent: Monday, July 06, 2009 10:47 PM > To: audacity-devel@... > Subject: Re: [Audacity-devel] Question about spectral analysis in Audacity > > > | From Martyn Shaw > | 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:gale@...] >>> Sent: Monday, July 06, 2009 3:55 PM >>> To: audacity-devel@... >>> Subject: Re: [Audacity-devel] Question about spectral analysis in > Audacity >>> >>> | From "Philip Van Baren" >>> | 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:martynshaw99@...] >>>> Sent: Wednesday, July 01, 2009 6:38 PM >>>> To: audacity-devel@... >>>> Subject: Re: [Audacity-devel] Question about spectral analysis in > Audacity >>>> >>>> >>>> Gale Andrews wrote: >>>>> | From Martyn Shaw >>>>> | 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 > >>>> 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 > audacity-devel@... > 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 > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Michael Chinen - 2008-07-18 18:51:57 ```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 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 > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```
 Re: [Audacity-devel] Question about spectral analysis in Audacity From: Martyn Shaw - 2008-07-18 23:59:56 ```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. HTH Martyn 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 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 >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> audacity-devel mailing list >> audacity-devel@... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > audacity-devel mailing list > audacity-devel@... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > ```