New FFT function

[Philip Van Baren]

I'm adding a configuration for gain and range on the spectrogram, but
running into a problem: The display does not refresh when changes are
applied.  This is also true of the existing min/max frequency settings.  Is
there a proper way to force a display refresh here?

As for the frequency plot, my opinion is you scale it so an amplitude 1.0
sine wave shows 0dB on the spectrum, as that is the definition of "0dB"
here - a full scale sine wave.  If you are looking at the frequency spectrum
of an MP3 the expectation (or at least my expectation) would be that
everything would be below 0dB, or some amplitude less than full scale.  If
the individual components of waveform were all full scale, then the sum of
them would clip.

The record and play level meters on the toolbar operate under the same
principle: a full scale sine wave reads 0dB.

Phil

--------------------------------------------------
From: "Martyn Shaw" <[hidden email]>
Sent: Monday, July 06, 2009 8:44 PM
To: <[hidden email]>
Subject: Re: [Audacity-devel] New FFT function

> Hi Phil (again)
>
> Philip Van Baren wrote:
>> I've gone ahead and turned on EXPERIMENTAL_USE_REALFFTF by default.
>
> Good.  If you aren't around in (say) a years time and somebody does a
> cleanup they'll say 'Yo, that been in here a year and hasn't caused a
> problem, we'll get rid of the EXPERIMENTAL.  Or not.
>
>> I also submitted a change (also controlled via this flag) to WaveClip.*
>> which optimizes the SpecCache calculations.  By my benchmarks this gives
>> a
>> 1.6x speedup in the SpecCache updates.
>>
>> A few notes on the WaveClip patch:
>>
>> 1) I changed the scaling of the Spectrogram such that a full scale sine
>> wave
>> will give a full scale (white) line on the spectrogram.  The previous
>> code
>> didn't scale at all, so the amplitudes depended on the FFT length, and
>> generally clipped the spectrum at somewhere around -40dB.
>
> Still look 'OKish' to me.  Some more colour resolution would be good.
>
>> 2) Due to (1) the spectrum will look darker than before.  I think the
>> proper
>> thing to do would be to define full scale and dB range configuration
>> variables in the spectrogram preferences dialog, so individual users can
>> tune the display to their taste.
>
> That's a good idea, and plenty of room on the spectrogram preferences
> dialog.
>
> TTFN
> Martyn
>
>> 3) I didn't modify the autocorrelation=1 code yet, so that will be as
>> slow
>> as before (except for the gains from the previously the submitted
>> RealFFTf
>> changes).
>>
>> 4) The previous ComputeSpectrum() code had provisions for computing the
>> average spectrum of larger blocks of data (i.e. the data width could be
>> longer than the FFT length).  This averaging function is not active (data
>> width and FFT length are passed from the same variable) so I did not
>> implement it in my new code.
>>
>>
>> -----Original Message-----
>> From: Martyn Shaw [mailto:[hidden email]]
>> Sent: Friday, July 03, 2009 7:49 PM
>> To: [hidden email]
>> Subject: Re: [Audacity-devel] New FFT function
>>
>> Phil
>>
>> I think you should turn it on, nobody else is going to as they don't
>> know the code as well as you do.  If things go wrong then you/we can
>> always turn it off again easily, or fix the problem.
>>
>> Or are you just parking it there for some future use?
>>
>> But I'm a 'commit and be dammed' sort of person.
>>
>> TTFN
>> Martyn
>>
>> Philip Van Baren wrote:
>>> I've committed a change which uses #define EXPERIMENTAL_USE_REALFFTF to
>>> switch the remaining FFT functions calls between the existing FFT
>>> function
>>
>>> and the new RealFFTf function.  It is commented out by default - enable
>>> it
>>
>>> in Experimental.h
>>>
>>> Rough benchmarking shows PlotSpectrum is about 1.2x faster with the
>> spectrum
>>> plot, and about 2x faster for the cepstrum and autocorrelation plots.
>>>
>>> Phil
>>>
>>>
>>>
>> ----------------------------------------------------------------------------
>> --
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>> ----------------------------------------------------------------------------
>> --
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full
> prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel 

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

[Philip Van Baren]

Never mind on the forced display refresh question - I figured it out: just
need to include the variables of concern in the SpecCache (like minFreq) and
include them in the SpecCache validity check.  After that it auto-refreshes
as expected after a preference change.

I committed changes to add a gain and range factor in the preferences for
the spectrogram display.  I set the defaults to gain=20dB, range=80dB which
should give results similar to previous versions.  Gain=20dB means 'white'
in the spectrogram corresponds to a signal 20dB below full scale.  If anyone
has opinions on what the default scaling should be, I'm all ears...

I also added a setting for 'Use a frequency-proportional scale factor'
(defaults to off).  What this does is multiply the spectrogram values by
(frequency^1.5).  This makes the spectrogram display more visually appealing
(in my opinion) because the typical spectrum amplitude falls off with
frequency.  The frequency-proportional scaling balances this so that the
high frequencies are more visible in the spectrogram, and the low
frequencies are somewhat muted.  The 1.5 power factor here is my personal
preference, but it should be somewhere between 1.0 and 2.0.  A power factor
of 1.0 would flatten out the spectrum of a square wave. The harmonics in the
typical music spectrum roll off a bit more those in a square wave, so I
chose 1.5.  Any feedback is appreciated.

Phil

--------------------------------------------------
From: "Philip Van Baren" <[hidden email]>
Sent: Monday, July 06, 2009 9:13 PM
To: <[hidden email]>
Subject: Re: [Audacity-devel] New FFT function

> I'm adding a configuration for gain and range on the spectrogram, but
> running into a problem: The display does not refresh when changes are
> applied.  This is also true of the existing min/max frequency settings.
> Is
> there a proper way to force a display refresh here?
>
> As for the frequency plot, my opinion is you scale it so an amplitude 1.0
> sine wave shows 0dB on the spectrum, as that is the definition of "0dB"
> here - a full scale sine wave.  If you are looking at the frequency
> spectrum
> of an MP3 the expectation (or at least my expectation) would be that
> everything would be below 0dB, or some amplitude less than full scale.  If
> the individual components of waveform were all full scale, then the sum of
> them would clip.
>
> The record and play level meters on the toolbar operate under the same
> principle: a full scale sine wave reads 0dB.
>
> Phil
>
> --------------------------------------------------
> From: "Martyn Shaw" <[hidden email]>
> Sent: Monday, July 06, 2009 8:44 PM
> To: <[hidden email]>
> Subject: Re: [Audacity-devel] New FFT function
>
>> Hi Phil (again)
>>
>> Philip Van Baren wrote:
>>> I've gone ahead and turned on EXPERIMENTAL_USE_REALFFTF by default.
>>
>> Good.  If you aren't around in (say) a years time and somebody does a
>> cleanup they'll say 'Yo, that been in here a year and hasn't caused a
>> problem, we'll get rid of the EXPERIMENTAL.  Or not.
>>
>>> I also submitted a change (also controlled via this flag) to WaveClip.*
>>> which optimizes the SpecCache calculations.  By my benchmarks this gives
>>> a
>>> 1.6x speedup in the SpecCache updates.
>>>
>>> A few notes on the WaveClip patch:
>>>
>>> 1) I changed the scaling of the Spectrogram such that a full scale sine
>>> wave
>>> will give a full scale (white) line on the spectrogram.  The previous
>>> code
>>> didn't scale at all, so the amplitudes depended on the FFT length, and
>>> generally clipped the spectrum at somewhere around -40dB.
>>
>> Still look 'OKish' to me.  Some more colour resolution would be good.
>>
>>> 2) Due to (1) the spectrum will look darker than before.  I think the
>>> proper
>>> thing to do would be to define full scale and dB range configuration
>>> variables in the spectrogram preferences dialog, so individual users can
>>> tune the display to their taste.
>>
>> That's a good idea, and plenty of room on the spectrogram preferences
>> dialog.
>>
>> TTFN
>> Martyn
>>
>>> 3) I didn't modify the autocorrelation=1 code yet, so that will be as
>>> slow
>>> as before (except for the gains from the previously the submitted
>>> RealFFTf
>>> changes).
>>>
>>> 4) The previous ComputeSpectrum() code had provisions for computing the
>>> average spectrum of larger blocks of data (i.e. the data width could be
>>> longer than the FFT length).  This averaging function is not active
>>> (data
>>> width and FFT length are passed from the same variable) so I did not
>>> implement it in my new code.
>>>
>>>
>>> -----Original Message-----
>>> From: Martyn Shaw [mailto:[hidden email]]
>>> Sent: Friday, July 03, 2009 7:49 PM
>>> To: [hidden email]
>>> Subject: Re: [Audacity-devel] New FFT function
>>>
>>> Phil
>>>
>>> I think you should turn it on, nobody else is going to as they don't
>>> know the code as well as you do.  If things go wrong then you/we can
>>> always turn it off again easily, or fix the problem.
>>>
>>> Or are you just parking it there for some future use?
>>>
>>> But I'm a 'commit and be dammed' sort of person.
>>>
>>> TTFN
>>> Martyn
>>>
>>> Philip Van Baren wrote:
>>>> I've committed a change which uses #define EXPERIMENTAL_USE_REALFFTF to
>>>> switch the remaining FFT functions calls between the existing FFT
>>>> function
>>>
>>>> and the new RealFFTf function.  It is commented out by default - enable
>>>> it
>>>
>>>> in Experimental.h
>>>>
>>>> Rough benchmarking shows PlotSpectrum is about 1.2x faster with the
>>> spectrum
>>>> plot, and about 2x faster for the cepstrum and autocorrelation plots.
>>>>
>>>> Phil
>>>>
>>>>
>>>>
>>> ----------------------------------------------------------------------------
>>> --
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>
>>> ----------------------------------------------------------------------------
>>> --
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge
>> This is your chance to win up to $100,000 in prizes! For a limited time,
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full
>> prize
>> details at: http://p.sf.net/sfu/blackberry
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full
> prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel 

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

[Martyn Shaw-2]

Hi Phil

I see you have been busy...

Philip Van Baren wrote:
...
> I committed changes to add a gain and range factor in the preferences for
> the spectrogram display.  I set the defaults to gain=20dB, range=80dB which
> should give results similar to previous versions.  Gain=20dB means 'white'
> in the spectrogram corresponds to a signal 20dB below full scale.  If anyone
> has opinions on what the default scaling should be, I'm all ears...

That would, I guess, be dependent on the source and what you were
looking for.  On the music I tried 25dB gain and 100dB range looked
better to me.  Or you could autoscale so that x% was white and y% was
grey.  Too many choices!...

> I also added a setting for 'Use a frequency-proportional scale factor'
> (defaults to off).  What this does is multiply the spectrogram values by
> (frequency^1.5).  This makes the spectrogram display more visually appealing
> (in my opinion) because the typical spectrum amplitude falls off with
> frequency.  The frequency-proportional scaling balances this so that the
> high frequencies are more visible in the spectrogram, and the low
> frequencies are somewhat muted.  The 1.5 power factor here is my personal
> preference, but it should be somewhere between 1.0 and 2.0.  A power factor
> of 1.0 would flatten out the spectrum of a square wave. The harmonics in the
> typical music spectrum roll off a bit more those in a square wave, so I
> chose 1.5.  Any feedback is appreciated.

I tried this with some music from a DAB radio and compared it on and
off, see here where the left-hand part is the 'new' scheme and the
right hand one is the 'old' scheme.

http://files.getdropbox.com/u/1327769/spectrograms.png

The old one shows the energy at low frequency, which is audibly
important but lost on the new one.  A power factor of 1 worked better
on this particular file.

So why not go the whole hog and put in sliders for the 3 new variables
  in prefs (like the 'Sound Activated Recording' one), plus a button
to reset to defaults.  If you do, I'd make the 'enhance higher
frequencies' slider go down to zero and lose the check box (default
would be zero).  I only suggest this because I think spectrograms are
pretty much a 'minority interest sport' but people who do use them (me
etc) deserve more functionality.

And while you are at it, could you please write up what spectrograms do on
http://manual.audacityteam.org/index.php?title=Spectrogram_Analysis&action=edit
which is entirely missing?

Oh yes, and why is maxFreq hardcoded like this?  Surely fs/2 is the max?
SpectrumPrefs.cpp 213:   if (maxFreq < 100 || maxFreq > 100000) {
should be an easy fix.

So some big asks, but you seem up to things!

Thanks
Martyn

> Phil
>
> --------------------------------------------------
> From: "Philip Van Baren" <[hidden email]>
> Sent: Monday, July 06, 2009 9:13 PM
> To: <[hidden email]>
> Subject: Re: [Audacity-devel] New FFT function
>
>> I'm adding a configuration for gain and range on the spectrogram, but
>> running into a problem: The display does not refresh when changes are
>> applied.  This is also true of the existing min/max frequency settings.
>> Is
>> there a proper way to force a display refresh here?
>>
>> As for the frequency plot, my opinion is you scale it so an amplitude 1.0
>> sine wave shows 0dB on the spectrum, as that is the definition of "0dB"
>> here - a full scale sine wave.  If you are looking at the frequency
>> spectrum
>> of an MP3 the expectation (or at least my expectation) would be that
>> everything would be below 0dB, or some amplitude less than full scale.  If
>> the individual components of waveform were all full scale, then the sum of
>> them would clip.
>>
>> The record and play level meters on the toolbar operate under the same
>> principle: a full scale sine wave reads 0dB.
>>
>> Phil
>>
>> --------------------------------------------------
>> From: "Martyn Shaw" <[hidden email]>
>> Sent: Monday, July 06, 2009 8:44 PM
>> To: <[hidden email]>
>> Subject: Re: [Audacity-devel] New FFT function
>>
>>> Hi Phil (again)
>>>
>>> Philip Van Baren wrote:
>>>> I've gone ahead and turned on EXPERIMENTAL_USE_REALFFTF by default.
>>> Good.  If you aren't around in (say) a years time and somebody does a
>>> cleanup they'll say 'Yo, that been in here a year and hasn't caused a
>>> problem, we'll get rid of the EXPERIMENTAL.  Or not.
>>>
>>>> I also submitted a change (also controlled via this flag) to WaveClip.*
>>>> which optimizes the SpecCache calculations.  By my benchmarks this gives
>>>> a
>>>> 1.6x speedup in the SpecCache updates.
>>>>
>>>> A few notes on the WaveClip patch:
>>>>
>>>> 1) I changed the scaling of the Spectrogram such that a full scale sine
>>>> wave
>>>> will give a full scale (white) line on the spectrogram.  The previous
>>>> code
>>>> didn't scale at all, so the amplitudes depended on the FFT length, and
>>>> generally clipped the spectrum at somewhere around -40dB.
>>> Still look 'OKish' to me.  Some more colour resolution would be good.
>>>
>>>> 2) Due to (1) the spectrum will look darker than before.  I think the
>>>> proper
>>>> thing to do would be to define full scale and dB range configuration
>>>> variables in the spectrogram preferences dialog, so individual users can
>>>> tune the display to their taste.
>>> That's a good idea, and plenty of room on the spectrogram preferences
>>> dialog.
>>>
>>> TTFN
>>> Martyn
>>>
>>>> 3) I didn't modify the autocorrelation=1 code yet, so that will be as
>>>> slow
>>>> as before (except for the gains from the previously the submitted
>>>> RealFFTf
>>>> changes).
>>>>
>>>> 4) The previous ComputeSpectrum() code had provisions for computing the
>>>> average spectrum of larger blocks of data (i.e. the data width could be
>>>> longer than the FFT length).  This averaging function is not active
>>>> (data
>>>> width and FFT length are passed from the same variable) so I did not
>>>> implement it in my new code.
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Martyn Shaw [mailto:[hidden email]]
>>>> Sent: Friday, July 03, 2009 7:49 PM
>>>> To: [hidden email]
>>>> Subject: Re: [Audacity-devel] New FFT function
>>>>
>>>> Phil
>>>>
>>>> I think you should turn it on, nobody else is going to as they don't
>>>> know the code as well as you do.  If things go wrong then you/we can
>>>> always turn it off again easily, or fix the problem.
>>>>
>>>> Or are you just parking it there for some future use?
>>>>
>>>> But I'm a 'commit and be dammed' sort of person.
>>>>
>>>> TTFN
>>>> Martyn
>>>>
>>>> Philip Van Baren wrote:
>>>>> I've committed a change which uses #define EXPERIMENTAL_USE_REALFFTF to
>>>>> switch the remaining FFT functions calls between the existing FFT
>>>>> function
>>>>> and the new RealFFTf function.  It is commented out by default - enable
>>>>> it
>>>>> in Experimental.h
>>>>>
>>>>> Rough benchmarking shows PlotSpectrum is about 1.2x faster with the
>>>> spectrum
>>>>> plot, and about 2x faster for the cepstrum and autocorrelation plots.
>>>>>
>>>>> Phil
>>>>>
>>>>>
>>>>>
>>>> ----------------------------------------------------------------------------
>>>> --
>>>>> _______________________________________________
>>>>> audacity-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>>
>>>> ----------------------------------------------------------------------------
>>>> --
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>>
>>> ------------------------------------------------------------------------------
>>> Enter the BlackBerry Developer Challenge
>>> This is your chance to win up to $100,000 in prizes! For a limited time,
>>> vendors submitting new applications to BlackBerry App World(TM) will have
>>> the opportunity to enter the BlackBerry Developer Challenge. See full
>>> prize
>>> details at: http://p.sf.net/sfu/blackberry
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge
>> This is your chance to win up to $100,000 in prizes! For a limited time,
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full
>> prize
>> details at: http://p.sf.net/sfu/blackberry
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel 
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

[Gale (Audacity Team)]

| From Martyn Shaw <[hidden email]>
| Tue, 07 Jul 2009 23:40:20 +0100
| Subject: [Audacity-devel] New FFT function
> Hi Phil
>
> I see you have been busy...
>
> and while you are at it, could you please write up what spectrograms do on
> http://manual.audacityteam.org/index.php?title=Spectrogram_Analysis&action=edit
> which is entirely missing?...
 
> Thanks
> Martyn


Hi Phil (and Martyn)

We do need to complete the Spectrograms Preferences page that
already exists (when the Preferences improvements are finished):
http://manual.audacityteam.org/manual/index.php?title=Spectrogram_Preferences

This need to give a succinct, user-facing explanation of what the
three new preferences in the GUI do. I'd saved some information from
your posts, but you or Martyn are the best men for the job I fancy.
Similarly:
http://manual.audacityteam.org/manual/index.php?title=Analyze_Menu#Plot_Spectrum...

has been left with some unanswered questions by Gary Nelson which
can't be left like that, and if we have a "music/sine" option here that
will need a description. If we don't, we need a sentence explaining
why a typical selection of "music" (WAV) will tend to peak at -12 dB
or lower (with default window size), and maybe lower still for MP3.
That level is certainly looking much better now than it was, and I'm
fairly happy, thinking about it some more.

If more detailed explanations are needed for what spectrograms in
Audacity do, then Martyn's idea (linked to from
http://manual.audacityteam.org/manual/index.php?title=Spectrogram_Preferences )

is fine.

[I believe we are/were intending to script the updating of all the preferences
and some other images.]

Phil, as far as I know you don't have an account on the manual, which is
needed to edit. If you need one, please drop me a line off-list.  


Thanks


Gale

> > --------------------------------------------------
> > From: "Philip Van Baren" <[hidden email]>
> > Sent: Monday, July 06, 2009 9:13 PM
> > To: <[hidden email]>
> > Subject: Re: [Audacity-devel] New FFT function
> >
> >> I'm adding a configuration for gain and range on the spectrogram, but
> >> running into a problem: The display does not refresh when changes are
> >> applied.  This is also true of the existing min/max frequency settings.
> >> Is
> >> there a proper way to force a display refresh here?
> >>
> >> As for the frequency plot, my opinion is you scale it so an amplitude 1.0
> >> sine wave shows 0dB on the spectrum, as that is the definition of "0dB"
> >> here - a full scale sine wave.  If you are looking at the frequency
> >> spectrum
> >> of an MP3 the expectation (or at least my expectation) would be that
> >> everything would be below 0dB, or some amplitude less than full scale.  If
> >> the individual components of waveform were all full scale, then the sum of
> >> them would clip.
> >>
> >> The record and play level meters on the toolbar operate under the same
> >> principle: a full scale sine wave reads 0dB.
> >>
> >> Phil
> >>
> >> --------------------------------------------------
> >> From: "Martyn Shaw" <[hidden email]>
> >> Sent: Monday, July 06, 2009 8:44 PM
> >> To: <[hidden email]>
> >> Subject: Re: [Audacity-devel] New FFT function
> >>
> >>> Hi Phil (again)
> >>>
> >>> Philip Van Baren wrote:
> >>>> I've gone ahead and turned on EXPERIMENTAL_USE_REALFFTF by default.
> >>> Good.  If you aren't around in (say) a years time and somebody does a
> >>> cleanup they'll say 'Yo, that been in here a year and hasn't caused a
> >>> problem, we'll get rid of the EXPERIMENTAL.  Or not.
> >>>
> >>>> I also submitted a change (also controlled via this flag) to WaveClip.*
> >>>> which optimizes the SpecCache calculations.  By my benchmarks this gives
> >>>> a
> >>>> 1.6x speedup in the SpecCache updates.
> >>>>
> >>>> A few notes on the WaveClip patch:
> >>>>
> >>>> 1) I changed the scaling of the Spectrogram such that a full scale sine
> >>>> wave
> >>>> will give a full scale (white) line on the spectrogram.  The previous
> >>>> code
> >>>> didn't scale at all, so the amplitudes depended on the FFT length, and
> >>>> generally clipped the spectrum at somewhere around -40dB.
> >>> Still look 'OKish' to me.  Some more colour resolution would be good.
> >>>
> >>>> 2) Due to (1) the spectrum will look darker than before.  I think the
> >>>> proper
> >>>> thing to do would be to define full scale and dB range configuration
> >>>> variables in the spectrogram preferences dialog, so individual users can
> >>>> tune the display to their taste.
> >>> That's a good idea, and plenty of room on the spectrogram preferences
> >>> dialog.
> >>>
> >>> TTFN
> >>> Martyn
> >>>
> >>>> 3) I didn't modify the autocorrelation=1 code yet, so that will be as
> >>>> slow
> >>>> as before (except for the gains from the previously the submitted
> >>>> RealFFTf
> >>>> changes).
> >>>>
> >>>> 4) The previous ComputeSpectrum() code had provisions for computing the
> >>>> average spectrum of larger blocks of data (i.e. the data width could be
> >>>> longer than the FFT length).  This averaging function is not active
> >>>> (data
> >>>> width and FFT length are passed from the same variable) so I did not
> >>>> implement it in my new code.
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Martyn Shaw [mailto:[hidden email]]
> >>>> Sent: Friday, July 03, 2009 7:49 PM
> >>>> To: [hidden email]
> >>>> Subject: Re: [Audacity-devel] New FFT function
> >>>>
> >>>> Phil
> >>>>
> >>>> I think you should turn it on, nobody else is going to as they don't
> >>>> know the code as well as you do.  If things go wrong then you/we can
> >>>> always turn it off again easily, or fix the problem.
> >>>>
> >>>> Or are you just parking it there for some future use?
> >>>>
> >>>> But I'm a 'commit and be dammed' sort of person.
> >>>>
> >>>> TTFN
> >>>> Martyn
> >>>>
> >>>> Philip Van Baren wrote:
> >>>>> I've committed a change which uses #define EXPERIMENTAL_USE_REALFFTF to
> >>>>> switch the remaining FFT functions calls between the existing FFT
> >>>>> function
> >>>>> and the new RealFFTf function.  It is commented out by default - enable
> >>>>> it
> >>>>> in Experimental.h
> >>>>>
> >>>>> Rough benchmarking shows PlotSpectrum is about 1.2x faster with the
> >>>> spectrum
> >>>>> plot, and about 2x faster for the cepstrum and autocorrelation plots.
> >>>>>
> >>>>> Phil
> >>>>>
> >>>>>
> >>>>>
> >>>> ----------------------------------------------------------------------------
> >>>> --
> >>>>> _______________________________________________
> >>>>> audacity-devel mailing list
> >>>>> [hidden email]
> >>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >>>>>
> >>>> ----------------------------------------------------------------------------
> >>>> --
> >>>> _______________________________________________
> >>>> audacity-devel mailing list
> >>>> [hidden email]
> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >>>>
> >>>>
> >>>> ------------------------------------------------------------------------------
> >>>> _______________________________________________
> >>>> audacity-devel mailing list
> >>>> [hidden email]
> >>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >>>>
> >>> ------------------------------------------------------------------------------
> >>> Enter the BlackBerry Developer Challenge
> >>> This is your chance to win up to $100,000 in prizes! For a limited time,
> >>> vendors submitting new applications to BlackBerry App World(TM) will have
> >>> the opportunity to enter the BlackBerry Developer Challenge. See full
> >>> prize
> >>> details at: http://p.sf.net/sfu/blackberry
> >>> _______________________________________________
> >>> audacity-devel mailing list
> >>> [hidden email]
> >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >>
> >> ------------------------------------------------------------------------------
> >> Enter the BlackBerry Developer Challenge
> >> This is your chance to win up to $100,000 in prizes! For a limited time,
> >> vendors submitting new applications to BlackBerry App World(TM) will have
> >> the opportunity to enter the BlackBerry Developer Challenge. See full
> >> prize
> >> details at: http://p.sf.net/sfu/blackberry
> >> _______________________________________________
> >> audacity-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel 
> >
> >
> > ------------------------------------------------------------------------------
> > Enter the BlackBerry Developer Challenge  
> > This is your chance to win up to $100,000 in prizes! For a limited time,
> > vendors submitting new applications to BlackBerry App World(TM) will have
> > the opportunity to enter the BlackBerry Developer Challenge. See full prize
> > details at: http://p.sf.net/sfu/blackberry
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

[Philip Van Baren]

> I tried this with some music from a DAB radio and compared it on and
> off, see here where the left-hand part is the 'new' scheme and the
> right hand one is the 'old' scheme.
>
> http://files.getdropbox.com/u/1327769/spectrograms.png
>
> The old one shows the energy at low frequency, which is audibly
> important but lost on the new one.  A power factor of 1 worked better
> on this particular file.

I think this is more of an example of the midrange values all blurring
together in that red/magenta range of the color table.  Boosting the gain a
touch might bring it back up into the white zone, but some more color table
choices would probably help more.

> So why not go the whole hog and put in sliders for the 3 new variables
>   in prefs (like the 'Sound Activated Recording' one), plus a button
> to reset to defaults.  If you do, I'd make the 'enhance higher
> frequencies' slider go down to zero and lose the check box (default
> would be zero).

This is a great idea, and simple to implement.  I'll replace the check box
with a slider.

> Oh yes, and why is maxFreq hardcoded like this?  Surely fs/2 is the max?
> SpectrumPrefs.cpp 213:   if (maxFreq < 100 || maxFreq > 100000) {
should be an easy fix.

That isn't my code, but my guess is the prefs need to be global, and not
limited to the sample rate of the current project or audio track.

On another note, I would really like a "1-to-1" vertical zoom setting for
the spectrogram display.  The detail in the spectrogram display is much
sharper when you match the pixels 1-to-1 with the spectrum values, but with
the manual sizing it is hard to find the sweet spot.  Anyone familiar with
the vertical zoom code willing to take it on?  I can add a function to map
frequency range to number of pixels, if that helps...

Phil

> Thanks
> Martyn


------------------------------------------------------------------------------
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/Challenge
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Thanks Gale

Gale Andrews wrote:
...
> If more detailed explanations are needed for what spectrograms in
> Audacity do, then Martyn's idea (linked to from
> http://manual.audacityteam.org/manual/index.php?title=Spectrogram_Preferences )
>
> is fine.

Just for accuracy, that page wasn't my idea, I found a link to it on
http://manual.audacityteam.org/index.php?title=Index and see it's been
there as a 'Wanted Topic' since day one.

Martyn

------------------------------------------------------------------------------
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/Challenge
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Martyn Shaw-2]

Hi Phil

Philip Van Baren wrote:

>> I tried this with some music from a DAB radio and compared it on and
>> off, see here where the left-hand part is the 'new' scheme and the
>> right hand one is the 'old' scheme.
>>
>> http://files.getdropbox.com/u/1327769/spectrograms.png
>>
>> The old one shows the energy at low frequency, which is audibly
>> important but lost on the new one.  A power factor of 1 worked better
>> on this particular file.
>
> I think this is more of an example of the midrange values all blurring
> together in that red/magenta range of the color table.  Boosting the gain a
> touch might bring it back up into the white zone, but some more color table
> choices would probably help more.

You are probably right, I don't particularly like the current colour
scheme for spectrograms in Audacity.  Can you come up with a better one?

>> So why not go the whole hog and put in sliders for the 3 new variables
>>   in prefs (like the 'Sound Activated Recording' one), plus a button
>> to reset to defaults.  If you do, I'd make the 'enhance higher
>> frequencies' slider go down to zero and lose the check box (default
>> would be zero).
>
> This is a great idea, and simple to implement.  I'll replace the check box
> with a slider.

I think that an all-or-nothing on the 'reset to defaults' button then
(and rapidly approaching code freeze).

>> Oh yes, and why is maxFreq hardcoded like this?  Surely fs/2 is the max?
>> SpectrumPrefs.cpp 213:   if (maxFreq < 100 || maxFreq > 100000) {
> should be an easy fix.
>
> That isn't my code, but my guess is the prefs need to be global, and not
> limited to the sample rate of the current project or audio track.

I think writing the 'max' pref as 'max' would be good (rather than a
number), so that as the sample rate changed it would still go up to fs/2.

> On another note, I would really like a "1-to-1" vertical zoom setting for
> the spectrogram display.  The detail in the spectrogram display is much
> sharper when you match the pixels 1-to-1 with the spectrum values, but with
> the manual sizing it is hard to find the sweet spot.  Anyone familiar with
> the vertical zoom code willing to take it on?  I can add a function to map
> frequency range to number of pixels, if that helps...

I kind of see what you mean, but hadn't thought of it or seen the
problem.  Care to post some images of what you mean?

TTFN
Martyn

> Phil
>
>> Thanks
>> Martyn
>
>
> ------------------------------------------------------------------------------
> 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/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

[Philip Van Baren]

I submitted a change which allows you to enter a dB/decade frequency gain
setting as a number (between 0 and 60, default to 0) instead of the
checkbox.  I wanted to put a slider in there, but I don't know enough about
the GUI stuff to get the done in time for the code freeze.  If anyone wants
to jump in and make a slider out of it, I won't be offended ;)

As for color palettes, I'm thinking maybe the grayscale checkbox could be
changed to a drop list of different color palettes.  I've attached a number
of colormap definitions which are used by Matlab.  You just need to copy the
desired map into the GetColorGradient() function in AColor.cpp.  My top two
would be 'jet' and 'hot'.  There isn't time to get this in before the code
freeze, though.

Phil

--------------------------------------------------
From: "Martyn Shaw" <[hidden email]>
Sent: Wednesday, July 08, 2009 8:03 PM
To: <[hidden email]>
Subject: Re: [Audacity-devel] New FFT function

> Hi Phil
>
> Philip Van Baren wrote:
>>> I tried this with some music from a DAB radio and compared it on and
>>> off, see here where the left-hand part is the 'new' scheme and the
>>> right hand one is the 'old' scheme.
>>>
>>> http://files.getdropbox.com/u/1327769/spectrograms.png
>>>
>>> The old one shows the energy at low frequency, which is audibly
>>> important but lost on the new one.  A power factor of 1 worked better
>>> on this particular file.
>>
>> I think this is more of an example of the midrange values all blurring
>> together in that red/magenta range of the color table.  Boosting the gain
>> a
>> touch might bring it back up into the white zone, but some more color
>> table
>> choices would probably help more.
>
> You are probably right, I don't particularly like the current colour
> scheme for spectrograms in Audacity.  Can you come up with a better one?
>
>>> So why not go the whole hog and put in sliders for the 3 new variables
>>>   in prefs (like the 'Sound Activated Recording' one), plus a button
>>> to reset to defaults.  If you do, I'd make the 'enhance higher
>>> frequencies' slider go down to zero and lose the check box (default
>>> would be zero).
>>
>> This is a great idea, and simple to implement.  I'll replace the check
>> box
>> with a slider.
>
> I think that an all-or-nothing on the 'reset to defaults' button then
> (and rapidly approaching code freeze).
>
>>> Oh yes, and why is maxFreq hardcoded like this?  Surely fs/2 is the max?
>>> SpectrumPrefs.cpp 213:   if (maxFreq < 100 || maxFreq > 100000) {
>> should be an easy fix.
>>
>> That isn't my code, but my guess is the prefs need to be global, and not
>> limited to the sample rate of the current project or audio track.
>
> I think writing the 'max' pref as 'max' would be good (rather than a
> number), so that as the sample rate changed it would still go up to fs/2.
>
>> On another note, I would really like a "1-to-1" vertical zoom setting for
>> the spectrogram display.  The detail in the spectrogram display is much
>> sharper when you match the pixels 1-to-1 with the spectrum values, but
>> with
>> the manual sizing it is hard to find the sweet spot.  Anyone familiar
>> with
>> the vertical zoom code willing to take it on?  I can add a function to
>> map
>> frequency range to number of pixels, if that helps...
>
> I kind of see what you mean, but hadn't thought of it or seen the
> problem.  Care to post some images of what you mean?
>
> TTFN
> Martyn
>
>> Phil
>>
>>> Thanks
>>> Martyn
>>
>>
>> ------------------------------------------------------------------------------
>> 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/Challenge
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full
> prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel 

      /*
     // 'hot' colormap used by Matlab
      const int gsteps = 3;
      float gradient[gsteps + 1][3] = {
         //     Red          Green        Blue
         {float(0.00), float(0.00), float(0.00)},    // black
         {float(1.00), float(0.00), float(0.00)},    // red
         {float(1.00), float(1.00), float(0.00)},    // yellow
         {float(1.00), float(1.00), float(1.00)}     // white
      };
        */
     /*
      // 'cool' colormap used by Matlab
      const int gsteps = 1;
      float gradient[gsteps + 1][3] = {
         //     Red          Green        Blue
         {float(0.00), float(1.00), float(1.00)},    // cyan
         {float(1.00), float(0.00), float(1.00)},    // magenta
      };
      */
      /*
      // 'bone' colormap used by Matlab
      const int gsteps = 3;
      float gradient[gsteps + 1][3] = {
         //     Red          Green        Blue
         {float(0.0000), float(0.0000), float(0.0000)},
         {float(0.2917), float(0.2917), float(0.4167)},
         {float(0.5833), float(0.7083), float(0.7083)},
         {float(1.0000), float(1.0000), float(1.0000)}
      };
      */
      /*
      // 'copper' colormap used by Matlab
      const int gsteps = 5;
      float gradient[gsteps + 1][3] = {
         //     Red          Green        Blue
         {float(0.0000), float(0.0000), float(0.0000)},
         {float(0.2500), float(0.1562), float(0.0995)},
         {float(0.5000), float(0.3125), float(0.1990)},
         {float(0.7500), float(0.4687), float(0.2985)},
         {float(1.0000), float(0.6250), float(0.3980)},
         {float(1.0000), float(0.7812), float(0.4975)}
      };
      */
      /*
      // Approximation to rotating hue 'rainbow'
      const int gsteps = 6;
      float gradient[gsteps + 1][3] = {
         //     Red          Green        Blue
         {float(1.0), float(0.0), float(0.0)},  // Red
         {float(1.0), float(1.0), float(0.0)},  // Yellow
         {float(0.0), float(1.0), float(0.0)},  // Green
         {float(0.0), float(1.0), float(1.0)},  // Cyan
         {float(0.0), float(0.0), float(1.0)},  // Blue
         {float(1.0), float(0.0), float(1.0)},  // Magenta
         {float(1.0), float(0.0), float(0.0)}   // Red
      };
      */
      /*
      // Modification to 'rainbow' which starts at black and ends at white
      const int gsteps = 7;
      float gradient[gsteps + 1][3] = {
         //     Red          Green        Blue
         {float(0.0), float(0.0), float(0.0)},  // Black
         {float(1.0), float(0.0), float(0.0)},  // Red
         {float(1.0), float(1.0), float(0.0)},  // Yellow
         {float(0.0), float(1.0), float(0.0)},  // Green
         {float(0.0), float(1.0), float(1.0)},  // Cyan
         {float(0.0), float(0.0), float(1.0)},  // Blue
         {float(1.0), float(0.0), float(1.0)},  // Magenta
         {float(1.0), float(1.0), float(1.0)}   // White
      };
      */
      /*
       */
     // Approximation to 'jet' colormap used in Matlab
      const int gsteps = 6;
      float gradient[gsteps + 1][3] = {
         //     Red          Green        Blue
         {float(0.0), float(0.0), float(0.4)},  // Dark Blue
         {float(0.0), float(0.0), float(1.0)},  // Blue
         {float(0.0), float(1.0), float(1.0)},  // Cyan
         {float(0.0), float(1.0), float(0.0)},  // Green
         {float(1.0), float(1.0), float(0.0)},  // Yellow
         {float(1.0), float(0.0), float(0.0)},  // Red
         {float(0.5), float(0.0), float(0.0)}   // Dark Red
      };


------------------------------------------------------------------------------
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/Challenge
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Chinen]

Hi,

I've been trying to figure out the P2 EQ Bug - silence at end of EQ
(for around 26000 samples).  It's 100% replicable if you select
26000+- 1000 samples and do an EQ.  It looks like the Filter routine
generates a window with the beginning 2000 samples truncated to 0 or
very near zero values.  I don't see any part of
Equalization::ProcessOne() or Filter() that seem to affect these 2000
samples, so this looks like a problem in the InverseRealFFT call.  I
don't know the code well enough to fix it immediately.  As we have a
release coming up, Philip, would you be willing to take a look and
revert or fix this, or point me in some direction?

Best,

Michael

On Wed, Jul 8, 2009 at 9:19 PM, Philip Van
Baren<[hidden email]> wrote:

> I submitted a change which allows you to enter a dB/decade frequency gain
> setting as a number (between 0 and 60, default to 0) instead of the
> checkbox.  I wanted to put a slider in there, but I don't know enough about
> the GUI stuff to get the done in time for the code freeze.  If anyone wants
> to jump in and make a slider out of it, I won't be offended ;)
>
> As for color palettes, I'm thinking maybe the grayscale checkbox could be
> changed to a drop list of different color palettes.  I've attached a number
> of colormap definitions which are used by Matlab.  You just need to copy the
> desired map into the GetColorGradient() function in AColor.cpp.  My top two
> would be 'jet' and 'hot'.  There isn't time to get this in before the code
> freeze, though.
>
> Phil
>
> --------------------------------------------------
> From: "Martyn Shaw" <[hidden email]>
> Sent: Wednesday, July 08, 2009 8:03 PM
> To: <[hidden email]>
> Subject: Re: [Audacity-devel] New FFT function
>
>> Hi Phil
>>
>> Philip Van Baren wrote:
>>>>
>>>> I tried this with some music from a DAB radio and compared it on and
>>>> off, see here where the left-hand part is the 'new' scheme and the
>>>> right hand one is the 'old' scheme.
>>>>
>>>> http://files.getdropbox.com/u/1327769/spectrograms.png
>>>>
>>>> The old one shows the energy at low frequency, which is audibly
>>>> important but lost on the new one.  A power factor of 1 worked better
>>>> on this particular file.
>>>
>>> I think this is more of an example of the midrange values all blurring
>>> together in that red/magenta range of the color table.  Boosting the gain
>>> a
>>> touch might bring it back up into the white zone, but some more color
>>> table
>>> choices would probably help more.
>>
>> You are probably right, I don't particularly like the current colour
>> scheme for spectrograms in Audacity.  Can you come up with a better one?
>>
>>>> So why not go the whole hog and put in sliders for the 3 new variables
>>>>  in prefs (like the 'Sound Activated Recording' one), plus a button
>>>> to reset to defaults.  If you do, I'd make the 'enhance higher
>>>> frequencies' slider go down to zero and lose the check box (default
>>>> would be zero).
>>>
>>> This is a great idea, and simple to implement.  I'll replace the check
>>> box
>>> with a slider.
>>
>> I think that an all-or-nothing on the 'reset to defaults' button then
>> (and rapidly approaching code freeze).
>>
>>>> Oh yes, and why is maxFreq hardcoded like this?  Surely fs/2 is the max?
>>>> SpectrumPrefs.cpp 213:   if (maxFreq < 100 || maxFreq > 100000) {
>>>
>>> should be an easy fix.
>>>
>>> That isn't my code, but my guess is the prefs need to be global, and not
>>> limited to the sample rate of the current project or audio track.
>>
>> I think writing the 'max' pref as 'max' would be good (rather than a
>> number), so that as the sample rate changed it would still go up to fs/2.
>>
>>> On another note, I would really like a "1-to-1" vertical zoom setting for
>>> the spectrogram display.  The detail in the spectrogram display is much
>>> sharper when you match the pixels 1-to-1 with the spectrum values, but
>>> with
>>> the manual sizing it is hard to find the sweet spot.  Anyone familiar
>>> with
>>> the vertical zoom code willing to take it on?  I can add a function to
>>> map
>>> frequency range to number of pixels, if that helps...
>>
>> I kind of see what you mean, but hadn't thought of it or seen the
>> problem.  Care to post some images of what you mean?
>>
>> TTFN
>> Martyn
>>
>>> Phil
>>>
>>>> Thanks
>>>> Martyn
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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/Challenge
>>> _______________________________________________
>>> audacity-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Enter the BlackBerry Developer Challenge
>> This is your chance to win up to $100,000 in prizes! For a limited time,
>> vendors submitting new applications to BlackBerry App World(TM) will have
>> the opportunity to enter the BlackBerry Developer Challenge. See full
>> prize
>> details at: http://p.sf.net/sfu/Challenge
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>

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

[Gale (Audacity Team)]

| From Michael Chinen <[hidden email]>
| Sun, 12 Jul 2009 18:23:51 -0700
| Subject: [Audacity-devel] New FFT function

> I've been trying to figure out the P2 EQ Bug - silence at end of EQ
> (for around 26000 samples).  It's 100% replicable if you select
> 26000+- 1000 samples and do an EQ.  It looks like the Filter routine
> generates a window with the beginning 2000 samples truncated to 0 or
> very near zero values.  I don't see any part of
> Equalization::ProcessOne() or Filter() that seem to affect these 2000
> samples, so this looks like a problem in the InverseRealFFT call.  I
> don't know the code well enough to fix it immediately.  As we have a
> release coming up, Philip, would you be willing to take a look and
> revert or fix this, or point me in some direction?

Hi Michael

It may be relevant that 1.3.7 Release has the same bug. 1.3.7
was several months before Phil added RealFFTf, if that is what
you are suggesting should be reverted.

I was assuming 1.3.8 would be released with this bug, as it is not
a P1, and is noted in the README, so will be noted in the Release
Notes.


Gale
   

>
> On Wed, Jul 8, 2009 at 9:19 PM, Philip Van
> Baren<[hidden email]> wrote:
> > I submitted a change which allows you to enter a dB/decade frequency gain
> > setting as a number (between 0 and 60, default to 0) instead of the
> > checkbox.  I wanted to put a slider in there, but I don't know enough about
> > the GUI stuff to get the done in time for the code freeze.  If anyone wants
> > to jump in and make a slider out of it, I won't be offended ;)
> >
> > As for color palettes, I'm thinking maybe the grayscale checkbox could be
> > changed to a drop list of different color palettes.  I've attached a number
> > of colormap definitions which are used by Matlab.  You just need to copy the
> > desired map into the GetColorGradient() function in AColor.cpp.  My top two
> > would be 'jet' and 'hot'.  There isn't time to get this in before the code
> > freeze, though.
> >
> > Phil
> >
> > --------------------------------------------------
> > From: "Martyn Shaw" <[hidden email]>
> > Sent: Wednesday, July 08, 2009 8:03 PM
> > To: <[hidden email]>
> > Subject: Re: [Audacity-devel] New FFT function
> >
> >> Hi Phil
> >>
> >> Philip Van Baren wrote:
> >>>>
> >>>> I tried this with some music from a DAB radio and compared it on and
> >>>> off, see here where the left-hand part is the 'new' scheme and the
> >>>> right hand one is the 'old' scheme.
> >>>>
> >>>> http://files.getdropbox.com/u/1327769/spectrograms.png
> >>>>
> >>>> The old one shows the energy at low frequency, which is audibly
> >>>> important but lost on the new one.  A power factor of 1 worked better
> >>>> on this particular file.
> >>>
> >>> I think this is more of an example of the midrange values all blurring
> >>> together in that red/magenta range of the color table.  Boosting the gain
> >>> a
> >>> touch might bring it back up into the white zone, but some more color
> >>> table
> >>> choices would probably help more.
> >>
> >> You are probably right, I don't particularly like the current colour
> >> scheme for spectrograms in Audacity.  Can you come up with a better one?
> >>
> >>>> So why not go the whole hog and put in sliders for the 3 new variables
> >>>>  in prefs (like the 'Sound Activated Recording' one), plus a button
> >>>> to reset to defaults.  If you do, I'd make the 'enhance higher
> >>>> frequencies' slider go down to zero and lose the check box (default
> >>>> would be zero).
> >>>
> >>> This is a great idea, and simple to implement.  I'll replace the check
> >>> box
> >>> with a slider.
> >>
> >> I think that an all-or-nothing on the 'reset to defaults' button then
> >> (and rapidly approaching code freeze).
> >>
> >>>> Oh yes, and why is maxFreq hardcoded like this?  Surely fs/2 is the max?
> >>>> SpectrumPrefs.cpp 213:   if (maxFreq < 100 || maxFreq > 100000) {
> >>>
> >>> should be an easy fix.
> >>>
> >>> That isn't my code, but my guess is the prefs need to be global, and not
> >>> limited to the sample rate of the current project or audio track.
> >>
> >> I think writing the 'max' pref as 'max' would be good (rather than a
> >> number), so that as the sample rate changed it would still go up to fs/2.
> >>
> >>> On another note, I would really like a "1-to-1" vertical zoom setting for
> >>> the spectrogram display.  The detail in the spectrogram display is much
> >>> sharper when you match the pixels 1-to-1 with the spectrum values, but
> >>> with
> >>> the manual sizing it is hard to find the sweet spot.  Anyone familiar
> >>> with
> >>> the vertical zoom code willing to take it on?  I can add a function to
> >>> map
> >>> frequency range to number of pixels, if that helps...
> >>
> >> I kind of see what you mean, but hadn't thought of it or seen the
> >> problem.  Care to post some images of what you mean?
> >>
> >> TTFN
> >> Martyn
> >>
> >>> Phil
> >>>
> >>>> Thanks
> >>>> Martyn
> >>>
> >>>
> >>>
> >>> ------------------------------------------------------------------------------
> >>> 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/Challenge

 


------------------------------------------------------------------------------
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/Challenge
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Chinen]

On Sun, Jul 12, 2009 at 7:43 PM, Gale Andrews<[hidden email]> wrote:

>
> | From Michael Chinen <[hidden email]>
> | Sun, 12 Jul 2009 18:23:51 -0700
> | Subject: [Audacity-devel] New FFT function
>> I've been trying to figure out the P2 EQ Bug - silence at end of EQ
>> (for around 26000 samples).  It's 100% replicable if you select
>> 26000+- 1000 samples and do an EQ.  It looks like the Filter routine
>> generates a window with the beginning 2000 samples truncated to 0 or
>> very near zero values.  I don't see any part of
>> Equalization::ProcessOne() or Filter() that seem to affect these 2000
>> samples, so this looks like a problem in the InverseRealFFT call.  I
>> don't know the code well enough to fix it immediately.  As we have a
>> release coming up, Philip, would you be willing to take a look and
>> revert or fix this, or point me in some direction?
>
> Hi Michael
>
> It may be relevant that 1.3.7 Release has the same bug. 1.3.7
> was several months before Phil added RealFFTf, if that is what
> you are suggesting should be reverted.

In that case my comment needs to be edited.  I saw these comments
about a similar sounding bug so I thought this one might also be
related to the new code.  Still, I'd like to ask if anyone can explain
the member variables/DSP used here.

I guess part of the confusion is due to me not understand all the DSP
going on.  I have implemented parametric EQ before, but as peak/shelf
filters in series.  The difference between the two systems is quite
amazing, as the shelf/peak method does not worry about windows - which
makes the overall system less complicated.

The function I've been looking at is the InverseRealFFTf one.  The
issue I'm trying to understand is how the first 2000 samples (exactly
(mM - 1)/2, commented as the filter length) are zero values and then
suddenly the 2001st and beyond seem like normal values.  I don't
reallly understand what mM is, and how it is connected with the FFT
code - if anyone could help me out please do.


>
> I was assuming 1.3.8 would be released with this bug, as it is not
> a P1, and is noted in the README, so will be noted in the Release
> Notes.
That seems more probable.  I think I got a little too excited there,
with the half a bug I helped Dan fix, :)

Michael

>
>
> Gale
>
>
>
>
>>
>> On Wed, Jul 8, 2009 at 9:19 PM, Philip Van
>> Baren<[hidden email]> wrote:
>> > I submitted a change which allows you to enter a dB/decade frequency gain
>> > setting as a number (between 0 and 60, default to 0) instead of the
>> > checkbox.  I wanted to put a slider in there, but I don't know enough about
>> > the GUI stuff to get the done in time for the code freeze.  If anyone wants
>> > to jump in and make a slider out of it, I won't be offended ;)
>> >
>> > As for color palettes, I'm thinking maybe the grayscale checkbox could be
>> > changed to a drop list of different color palettes.  I've attached a number
>> > of colormap definitions which are used by Matlab.  You just need to copy the
>> > desired map into the GetColorGradient() function in AColor.cpp.  My top two
>> > would be 'jet' and 'hot'.  There isn't time to get this in before the code
>> > freeze, though.
>> >
>> > Phil
>> >
>> > --------------------------------------------------
>> > From: "Martyn Shaw" <[hidden email]>
>> > Sent: Wednesday, July 08, 2009 8:03 PM
>> > To: <[hidden email]>
>> > Subject: Re: [Audacity-devel] New FFT function
>> >
>> >> Hi Phil
>> >>
>> >> Philip Van Baren wrote:
>> >>>>
>> >>>> I tried this with some music from a DAB radio and compared it on and
>> >>>> off, see here where the left-hand part is the 'new' scheme and the
>> >>>> right hand one is the 'old' scheme.
>> >>>>
>> >>>> http://files.getdropbox.com/u/1327769/spectrograms.png
>> >>>>
>> >>>> The old one shows the energy at low frequency, which is audibly
>> >>>> important but lost on the new one.  A power factor of 1 worked better
>> >>>> on this particular file.
>> >>>
>> >>> I think this is more of an example of the midrange values all blurring
>> >>> together in that red/magenta range of the color table.  Boosting the gain
>> >>> a
>> >>> touch might bring it back up into the white zone, but some more color
>> >>> table
>> >>> choices would probably help more.
>> >>
>> >> You are probably right, I don't particularly like the current colour
>> >> scheme for spectrograms in Audacity.  Can you come up with a better one?
>> >>
>> >>>> So why not go the whole hog and put in sliders for the 3 new variables
>> >>>>  in prefs (like the 'Sound Activated Recording' one), plus a button
>> >>>> to reset to defaults.  If you do, I'd make the 'enhance higher
>> >>>> frequencies' slider go down to zero and lose the check box (default
>> >>>> would be zero).
>> >>>
>> >>> This is a great idea, and simple to implement.  I'll replace the check
>> >>> box
>> >>> with a slider.
>> >>
>> >> I think that an all-or-nothing on the 'reset to defaults' button then
>> >> (and rapidly approaching code freeze).
>> >>
>> >>>> Oh yes, and why is maxFreq hardcoded like this?  Surely fs/2 is the max?
>> >>>> SpectrumPrefs.cpp 213:   if (maxFreq < 100 || maxFreq > 100000) {
>> >>>
>> >>> should be an easy fix.
>> >>>
>> >>> That isn't my code, but my guess is the prefs need to be global, and not
>> >>> limited to the sample rate of the current project or audio track.
>> >>
>> >> I think writing the 'max' pref as 'max' would be good (rather than a
>> >> number), so that as the sample rate changed it would still go up to fs/2.
>> >>
>> >>> On another note, I would really like a "1-to-1" vertical zoom setting for
>> >>> the spectrogram display.  The detail in the spectrogram display is much
>> >>> sharper when you match the pixels 1-to-1 with the spectrum values, but
>> >>> with
>> >>> the manual sizing it is hard to find the sweet spot.  Anyone familiar
>> >>> with
>> >>> the vertical zoom code willing to take it on?  I can add a function to
>> >>> map
>> >>> frequency range to number of pixels, if that helps...
>> >>
>> >> I kind of see what you mean, but hadn't thought of it or seen the
>> >> problem.  Care to post some images of what you mean?
>> >>
>> >> TTFN
>> >> Martyn
>> >>
>> >>> Phil
>> >>>
>> >>>> Thanks
>> >>>> Martyn
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> 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/Challenge
>
>
>
>
> ------------------------------------------------------------------------------
> 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/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

[Philip Van Baren]

I've submitted a fix for this.  The problem was when wcopy < (mM-1) there is a buffer overrun and the final overlap-add doesn't work properly.  This happens whenever the number of samples selected is between 1 and mM greater than any integer multiple of the chosen processing block size.

Phil

-----Original Message-----
From: Michael Chinen [mailto:[hidden email]]
Sent: Sunday, July 12, 2009 11:27 PM
To: [hidden email]
Subject: Re: [Audacity-devel] New FFT function

On Sun, Jul 12, 2009 at 7:43 PM, Gale Andrews<[hidden email]> wrote:

>
> | From Michael Chinen <[hidden email]>
> | Sun, 12 Jul 2009 18:23:51 -0700
> | Subject: [Audacity-devel] New FFT function
>> I've been trying to figure out the P2 EQ Bug - silence at end of EQ
>> (for around 26000 samples). �It's 100% replicable if you select
>> 26000+- 1000 samples and do an EQ. �It looks like the Filter routine
>> generates a window with the beginning 2000 samples truncated to 0 or
>> very near zero values. �I don't see any part of
>> Equalization::ProcessOne() or Filter() that seem to affect these 2000
>> samples, so this looks like a problem in the InverseRealFFT call. �I
>> don't know the code well enough to fix it immediately. �As we have a
>> release coming up, Philip, would you be willing to take a look and
>> revert or fix this, or point me in some direction?
>
> Hi Michael
>
> It may be relevant that 1.3.7 Release has the same bug. 1.3.7
> was several months before Phil added RealFFTf, if that is what
> you are suggesting should be reverted.

In that case my comment needs to be edited.  I saw these comments
about a similar sounding bug so I thought this one might also be
related to the new code.  Still, I'd like to ask if anyone can explain
the member variables/DSP used here.

I guess part of the confusion is due to me not understand all the DSP
going on.  I have implemented parametric EQ before, but as peak/shelf
filters in series.  The difference between the two systems is quite
amazing, as the shelf/peak method does not worry about windows - which
makes the overall system less complicated.

The function I've been looking at is the InverseRealFFTf one.  The
issue I'm trying to understand is how the first 2000 samples (exactly
(mM - 1)/2, commented as the filter length) are zero values and then
suddenly the 2001st and beyond seem like normal values.  I don't
reallly understand what mM is, and how it is connected with the FFT
code - if anyone could help me out please do.


>
> I was assuming 1.3.8 would be released with this bug, as it is not
> a P1, and is noted in the README, so will be noted in the Release
> Notes.
That seems more probable.  I think I got a little too excited there,
with the half a bug I helped Dan fix, :)

Michael

>
>
> Gale
>
>
>
>
>>
>> On Wed, Jul 8, 2009 at 9:19 PM, Philip Van
>> Baren<[hidden email]> wrote:
>> > I submitted a change which allows you to enter a dB/decade frequency gain
>> > setting as a number (between 0 and 60, default to 0) instead of the
>> > checkbox. �I wanted to put a slider in there, but I don't know enough about
>> > the GUI stuff to get the done in time for the code freeze. �If anyone wants
>> > to jump in and make a slider out of it, I won't be offended ;)
>> >
>> > As for color palettes, I'm thinking maybe the grayscale checkbox could be
>> > changed to a drop list of different color palettes. �I've attached a number
>> > of colormap definitions which are used by Matlab. �You just need to copy the
>> > desired map into the GetColorGradient() function in AColor.cpp. �My top two
>> > would be 'jet' and 'hot'. �There isn't time to get this in before the code
>> > freeze, though.
>> >
>> > Phil
>> >
>> > --------------------------------------------------
>> > From: "Martyn Shaw" <[hidden email]>
>> > Sent: Wednesday, July 08, 2009 8:03 PM
>> > To: <[hidden email]>
>> > Subject: Re: [Audacity-devel] New FFT function
>> >
>> >> Hi Phil
>> >>
>> >> Philip Van Baren wrote:
>> >>>>
>> >>>> I tried this with some music from a DAB radio and compared it on and
>> >>>> off, see here where the left-hand part is the 'new' scheme and the
>> >>>> right hand one is the 'old' scheme.
>> >>>>
>> >>>> http://files.getdropbox.com/u/1327769/spectrograms.png
>> >>>>
>> >>>> The old one shows the energy at low frequency, which is audibly
>> >>>> important but lost on the new one. �A power factor of 1 worked better
>> >>>> on this particular file.
>> >>>
>> >>> I think this is more of an example of the midrange values all blurring
>> >>> together in that red/magenta range of the color table. �Boosting the gain
>> >>> a
>> >>> touch might bring it back up into the white zone, but some more color
>> >>> table
>> >>> choices would probably help more.
>> >>
>> >> You are probably right, I don't particularly like the current colour
>> >> scheme for spectrograms in Audacity. �Can you come up with a better one?
>> >>
>> >>>> So why not go the whole hog and put in sliders for the 3 new variables
>> >>>> �in prefs (like the 'Sound Activated Recording' one), plus a button
>> >>>> to reset to defaults. �If you do, I'd make the 'enhance higher
>> >>>> frequencies' slider go down to zero and lose the check box (default
>> >>>> would be zero).
>> >>>
>> >>> This is a great idea, and simple to implement. �I'll replace the check
>> >>> box
>> >>> with a slider.
>> >>
>> >> I think that an all-or-nothing on the 'reset to defaults' button then
>> >> (and rapidly approaching code freeze).
>> >>
>> >>>> Oh yes, and why is maxFreq hardcoded like this? �Surely fs/2 is the max?
>> >>>> SpectrumPrefs.cpp 213: � if (maxFreq < 100 || maxFreq > 100000) {
>> >>>
>> >>> should be an easy fix.
>> >>>
>> >>> That isn't my code, but my guess is the prefs need to be global, and not
>> >>> limited to the sample rate of the current project or audio track.
>> >>
>> >> I think writing the 'max' pref as 'max' would be good (rather than a
>> >> number), so that as the sample rate changed it would still go up to fs/2.
>> >>
>> >>> On another note, I would really like a "1-to-1" vertical zoom setting for
>> >>> the spectrogram display. �The detail in the spectrogram display is much
>> >>> sharper when you match the pixels 1-to-1 with the spectrum values, but
>> >>> with
>> >>> the manual sizing it is hard to find the sweet spot. �Anyone familiar
>> >>> with
>> >>> the vertical zoom code willing to take it on? �I can add a function to
>> >>> map
>> >>> frequency range to number of pixels, if that helps...
>> >>
>> >> I kind of see what you mean, but hadn't thought of it or seen the
>> >> problem. �Care to post some images of what you mean?
>> >>
>> >> TTFN
>> >> Martyn
>> >>
>> >>> Phil
>> >>>
>> >>>> Thanks
>> >>>> Martyn
>> >>>
>> >>>
>> >>>
>> >>> ------------------------------------------------------------------------------
>> >>> 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/Challenge
>
>
>
>
> ------------------------------------------------------------------------------
> 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/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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


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

[Michael Chinen]

On Mon, Jul 13, 2009 at 10:20 AM, Philip Van
Baren<[hidden email]> wrote:
> I've submitted a fix for this.  The problem was when wcopy < (mM-1) there is a buffer overrun and the final overlap-add doesn't work properly.  This happens whenever the number of samples selected is between 1 and mM greater than any integer multiple of the chosen processing block size.

Thanks Phil, I was and would have been staring at the wrong part of
the code to debug it.  If it hasn't been done I'll verify when I get
home in about 8 hours.

Michael

>
> Phil
>
> -----Original Message-----
> From: Michael Chinen [mailto:[hidden email]]
> Sent: Sunday, July 12, 2009 11:27 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] New FFT function
>
> On Sun, Jul 12, 2009 at 7:43 PM, Gale Andrews<[hidden email]> wrote:
>>
>> | From Michael Chinen <[hidden email]>
>> | Sun, 12 Jul 2009 18:23:51 -0700
>> | Subject: [Audacity-devel] New FFT function
>>> I've been trying to figure out the P2 EQ Bug - silence at end of EQ
>>> (for around 26000 samples). �It's 100% replicable if you select
>>> 26000+- 1000 samples and do an EQ. �It looks like the Filter routine
>>> generates a window with the beginning 2000 samples truncated to 0 or
>>> very near zero values. �I don't see any part of
>>> Equalization::ProcessOne() or Filter() that seem to affect these 2000
>>> samples, so this looks like a problem in the InverseRealFFT call. �I
>>> don't know the code well enough to fix it immediately. �As we have a
>>> release coming up, Philip, would you be willing to take a look and
>>> revert or fix this, or point me in some direction?
>>
>> Hi Michael
>>
>> It may be relevant that 1.3.7 Release has the same bug. 1.3.7
>> was several months before Phil added RealFFTf, if that is what
>> you are suggesting should be reverted.
> In that case my comment needs to be edited.  I saw these comments
> about a similar sounding bug so I thought this one might also be
> related to the new code.  Still, I'd like to ask if anyone can explain
> the member variables/DSP used here.
>
> I guess part of the confusion is due to me not understand all the DSP
> going on.  I have implemented parametric EQ before, but as peak/shelf
> filters in series.  The difference between the two systems is quite
> amazing, as the shelf/peak method does not worry about windows - which
> makes the overall system less complicated.
>
> The function I've been looking at is the InverseRealFFTf one.  The
> issue I'm trying to understand is how the first 2000 samples (exactly
> (mM - 1)/2, commented as the filter length) are zero values and then
> suddenly the 2001st and beyond seem like normal values.  I don't
> reallly understand what mM is, and how it is connected with the FFT
> code - if anyone could help me out please do.
>
>
>>
>> I was assuming 1.3.8 would be released with this bug, as it is not
>> a P1, and is noted in the README, so will be noted in the Release
>> Notes.
> That seems more probable.  I think I got a little too excited there,
> with the half a bug I helped Dan fix, :)
>
> Michael
>
>
>>
>>
>> Gale
>>
>>
>>
>>
>>>
>>> On Wed, Jul 8, 2009 at 9:19 PM, Philip Van
>>> Baren<[hidden email]> wrote:
>>> > I submitted a change which allows you to enter a dB/decade frequency gain
>>> > setting as a number (between 0 and 60, default to 0) instead of the
>>> > checkbox. �I wanted to put a slider in there, but I don't know enough about
>>> > the GUI stuff to get the done in time for the code freeze. �If anyone wants
>>> > to jump in and make a slider out of it, I won't be offended ;)
>>> >
>>> > As for color palettes, I'm thinking maybe the grayscale checkbox could be
>>> > changed to a drop list of different color palettes. �I've attached a number
>>> > of colormap definitions which are used by Matlab. �You just need to copy the
>>> > desired map into the GetColorGradient() function in AColor.cpp. �My top two
>>> > would be 'jet' and 'hot'. �There isn't time to get this in before the code
>>> > freeze, though.
>>> >
>>> > Phil
>>> >
>>> > --------------------------------------------------
>>> > From: "Martyn Shaw" <[hidden email]>
>>> > Sent: Wednesday, July 08, 2009 8:03 PM
>>> > To: <[hidden email]>
>>> > Subject: Re: [Audacity-devel] New FFT function
>>> >
>>> >> Hi Phil
>>> >>
>>> >> Philip Van Baren wrote:
>>> >>>>
>>> >>>> I tried this with some music from a DAB radio and compared it on and
>>> >>>> off, see here where the left-hand part is the 'new' scheme and the
>>> >>>> right hand one is the 'old' scheme.
>>> >>>>
>>> >>>> http://files.getdropbox.com/u/1327769/spectrograms.png
>>> >>>>
>>> >>>> The old one shows the energy at low frequency, which is audibly
>>> >>>> important but lost on the new one. �A power factor of 1 worked better
>>> >>>> on this particular file.
>>> >>>
>>> >>> I think this is more of an example of the midrange values all blurring
>>> >>> together in that red/magenta range of the color table. �Boosting the gain
>>> >>> a
>>> >>> touch might bring it back up into the white zone, but some more color
>>> >>> table
>>> >>> choices would probably help more.
>>> >>
>>> >> You are probably right, I don't particularly like the current colour
>>> >> scheme for spectrograms in Audacity. �Can you come up with a better one?
>>> >>
>>> >>>> So why not go the whole hog and put in sliders for the 3 new variables
>>> >>>> �in prefs (like the 'Sound Activated Recording' one), plus a button
>>> >>>> to reset to defaults. �If you do, I'd make the 'enhance higher
>>> >>>> frequencies' slider go down to zero and lose the check box (default
>>> >>>> would be zero).
>>> >>>
>>> >>> This is a great idea, and simple to implement. �I'll replace the check
>>> >>> box
>>> >>> with a slider.
>>> >>
>>> >> I think that an all-or-nothing on the 'reset to defaults' button then
>>> >> (and rapidly approaching code freeze).
>>> >>
>>> >>>> Oh yes, and why is maxFreq hardcoded like this? �Surely fs/2 is the max?
>>> >>>> SpectrumPrefs.cpp 213: � if (maxFreq < 100 || maxFreq > 100000) {
>>> >>>
>>> >>> should be an easy fix.
>>> >>>
>>> >>> That isn't my code, but my guess is the prefs need to be global, and not
>>> >>> limited to the sample rate of the current project or audio track.
>>> >>
>>> >> I think writing the 'max' pref as 'max' would be good (rather than a
>>> >> number), so that as the sample rate changed it would still go up to fs/2.
>>> >>
>>> >>> On another note, I would really like a "1-to-1" vertical zoom setting for
>>> >>> the spectrogram display. �The detail in the spectrogram display is much
>>> >>> sharper when you match the pixels 1-to-1 with the spectrum values, but
>>> >>> with
>>> >>> the manual sizing it is hard to find the sweet spot. �Anyone familiar
>>> >>> with
>>> >>> the vertical zoom code willing to take it on? �I can add a function to
>>> >>> map
>>> >>> frequency range to number of pixels, if that helps...
>>> >>
>>> >> I kind of see what you mean, but hadn't thought of it or seen the
>>> >> problem. �Care to post some images of what you mean?
>>> >>
>>> >> TTFN
>>> >> Martyn
>>> >>
>>> >>> Phil
>>> >>>
>>> >>>> Thanks
>>> >>>> Martyn
>>> >>>
>>> >>>
>>> >>>
>>> >>> ------------------------------------------------------------------------------
>>> >>> 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/Challenge
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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/Challenge
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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

[Martyn Shaw-2]

Thanks for that Phil!  I was going to get around to this, but never
did.  I can't confirm the fix as I never looked at the bug, but it
sound right.

TTFN
Martyn

Philip Van Baren wrote:

> I've submitted a fix for this.  The problem was when wcopy < (mM-1) there is a buffer overrun and the final overlap-add doesn't work properly.  This happens whenever the number of samples selected is between 1 and mM greater than any integer multiple of the chosen processing block size.
>
> Phil
>
> -----Original Message-----
> From: Michael Chinen [mailto:[hidden email]]
> Sent: Sunday, July 12, 2009 11:27 PM
> To: [hidden email]
> Subject: Re: [Audacity-devel] New FFT function
>
> On Sun, Jul 12, 2009 at 7:43 PM, Gale Andrews<[hidden email]> wrote:
>> | From Michael Chinen <[hidden email]>
>> | Sun, 12 Jul 2009 18:23:51 -0700
>> | Subject: [Audacity-devel] New FFT function
>>> I've been trying to figure out the P2 EQ Bug - silence at end of EQ
>>> (for around 26000 samples). �It's 100% replicable if you select
>>> 26000+- 1000 samples and do an EQ. �It looks like the Filter routine
>>> generates a window with the beginning 2000 samples truncated to 0 or
>>> very near zero values. �I don't see any part of
>>> Equalization::ProcessOne() or Filter() that seem to affect these 2000
>>> samples, so this looks like a problem in the InverseRealFFT call. �I
>>> don't know the code well enough to fix it immediately. �As we have a
>>> release coming up, Philip, would you be willing to take a look and
>>> revert or fix this, or point me in some direction?
>> Hi Michael
>>
>> It may be relevant that 1.3.7 Release has the same bug. 1.3.7
>> was several months before Phil added RealFFTf, if that is what
>> you are suggesting should be reverted.
> In that case my comment needs to be edited.  I saw these comments
> about a similar sounding bug so I thought this one might also be
> related to the new code.  Still, I'd like to ask if anyone can explain
> the member variables/DSP used here.
>
> I guess part of the confusion is due to me not understand all the DSP
> going on.  I have implemented parametric EQ before, but as peak/shelf
> filters in series.  The difference between the two systems is quite
> amazing, as the shelf/peak method does not worry about windows - which
> makes the overall system less complicated.
>
> The function I've been looking at is the InverseRealFFTf one.  The
> issue I'm trying to understand is how the first 2000 samples (exactly
> (mM - 1)/2, commented as the filter length) are zero values and then
> suddenly the 2001st and beyond seem like normal values.  I don't
> reallly understand what mM is, and how it is connected with the FFT
> code - if anyone could help me out please do.
>
>
>> I was assuming 1.3.8 would be released with this bug, as it is not
>> a P1, and is noted in the README, so will be noted in the Release
>> Notes.
> That seems more probable.  I think I got a little too excited there,
> with the half a bug I helped Dan fix, :)
>
> Michael
>
>
>>
>> Gale
>>
>>
>>
>>
>>> On Wed, Jul 8, 2009 at 9:19 PM, Philip Van
>>> Baren<[hidden email]> wrote:
>>>> I submitted a change which allows you to enter a dB/decade frequency gain
>>>> setting as a number (between 0 and 60, default to 0) instead of the
>>>> checkbox. �I wanted to put a slider in there, but I don't know enough about
>>>> the GUI stuff to get the done in time for the code freeze. �If anyone wants
>>>> to jump in and make a slider out of it, I won't be offended ;)
>>>>
>>>> As for color palettes, I'm thinking maybe the grayscale checkbox could be
>>>> changed to a drop list of different color palettes. �I've attached a number
>>>> of colormap definitions which are used by Matlab. �You just need to copy the
>>>> desired map into the GetColorGradient() function in AColor.cpp. �My top two
>>>> would be 'jet' and 'hot'. �There isn't time to get this in before the code
>>>> freeze, though.
>>>>
>>>> Phil
>>>>
>>>> --------------------------------------------------
>>>> From: "Martyn Shaw" <[hidden email]>
>>>> Sent: Wednesday, July 08, 2009 8:03 PM
>>>> To: <[hidden email]>
>>>> Subject: Re: [Audacity-devel] New FFT function
>>>>
>>>>> Hi Phil
>>>>>
>>>>> Philip Van Baren wrote:
>>>>>>> I tried this with some music from a DAB radio and compared it on and
>>>>>>> off, see here where the left-hand part is the 'new' scheme and the
>>>>>>> right hand one is the 'old' scheme.
>>>>>>>
>>>>>>> http://files.getdropbox.com/u/1327769/spectrograms.png
>>>>>>>
>>>>>>> The old one shows the energy at low frequency, which is audibly
>>>>>>> important but lost on the new one. �A power factor of 1 worked better
>>>>>>> on this particular file.
>>>>>> I think this is more of an example of the midrange values all blurring
>>>>>> together in that red/magenta range of the color table. �Boosting the gain
>>>>>> a
>>>>>> touch might bring it back up into the white zone, but some more color
>>>>>> table
>>>>>> choices would probably help more.
>>>>> You are probably right, I don't particularly like the current colour
>>>>> scheme for spectrograms in Audacity. �Can you come up with a better one?
>>>>>
>>>>>>> So why not go the whole hog and put in sliders for the 3 new variables
>>>>>>> �in prefs (like the 'Sound Activated Recording' one), plus a button
>>>>>>> to reset to defaults. �If you do, I'd make the 'enhance higher
>>>>>>> frequencies' slider go down to zero and lose the check box (default
>>>>>>> would be zero).
>>>>>> This is a great idea, and simple to implement. �I'll replace the check
>>>>>> box
>>>>>> with a slider.
>>>>> I think that an all-or-nothing on the 'reset to defaults' button then
>>>>> (and rapidly approaching code freeze).
>>>>>
>>>>>>> Oh yes, and why is maxFreq hardcoded like this? �Surely fs/2 is the max?
>>>>>>> SpectrumPrefs.cpp 213: � if (maxFreq < 100 || maxFreq > 100000) {
>>>>>> should be an easy fix.
>>>>>>
>>>>>> That isn't my code, but my guess is the prefs need to be global, and not
>>>>>> limited to the sample rate of the current project or audio track.
>>>>> I think writing the 'max' pref as 'max' would be good (rather than a
>>>>> number), so that as the sample rate changed it would still go up to fs/2.
>>>>>
>>>>>> On another note, I would really like a "1-to-1" vertical zoom setting for
>>>>>> the spectrogram display. �The detail in the spectrogram display is much
>>>>>> sharper when you match the pixels 1-to-1 with the spectrum values, but
>>>>>> with
>>>>>> the manual sizing it is hard to find the sweet spot. �Anyone familiar
>>>>>> with
>>>>>> the vertical zoom code willing to take it on? �I can add a function to
>>>>>> map
>>>>>> frequency range to number of pixels, if that helps...
>>>>> I kind of see what you mean, but hadn't thought of it or seen the
>>>>> problem. �Care to post some images of what you mean?
>>>>>
>>>>> TTFN
>>>>> Martyn
>>>>>
>>>>>> Phil
>>>>>>
>>>>>>> Thanks
>>>>>>> Martyn
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> 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/Challenge
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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/Challenge
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

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

[Gale (Audacity Team)]

| From Martyn Shaw <[hidden email]>
| Tue, 14 Jul 2009 00:27:35 +0100
| Subject: [Audacity-devel] New FFT function
> Thanks for that Phil!  I was going to get around to this, but never
> did.  I can't confirm the fix as I never looked at the bug, but it
> sound right.
>
> TTFN
> Martyn

As far as I can see, the bug's gone so I've already removed from
Checklist, and will remove from the README since it had already
been noted there.

Thanks, Phil.


Gale


 

> Philip Van Baren wrote:
>> I've submitted a fix for this.  The problem was when wcopy < (mM-1)
>> there is a buffer overrun and the final overlap-add doesn't work
>> properly.  This happens whenever the number of samples selected is
>> between 1 and mM greater than any integer multiple of the chosen
> > processing block size.
> >
> > Phil
> >
> > -----Original Message-----
> > From: Michael Chinen [mailto:[hidden email]]
> > Sent: Sunday, July 12, 2009 11:27 PM
> > To: [hidden email]
> > Subject: Re: [Audacity-devel] New FFT function
> >
> > On Sun, Jul 12, 2009 at 7:43 PM, Gale Andrews<[hidden email]> wrote:
> >> | From Michael Chinen <[hidden email]>
> >> | Sun, 12 Jul 2009 18:23:51 -0700
> >> | Subject: [Audacity-devel] New FFT function
> >>> I've been trying to figure out the P2 EQ Bug - silence at end of EQ
> >>> (for around 26000 samples). ?It's 100% replicable if you select
> >>> 26000+- 1000 samples and do an EQ. ?It looks like the Filter routine
> >>> generates a window with the beginning 2000 samples truncated to 0 or
> >>> very near zero values. ?I don't see any part of
> >>> Equalization::ProcessOne() or Filter() that seem to affect these 2000
> >>> samples, so this looks like a problem in the InverseRealFFT call. ?I
> >>> don't know the code well enough to fix it immediately. ?As we have a
> >>> release coming up, Philip, would you be willing to take a look and
> >>> revert or fix this, or point me in some direction?
> >> Hi Michael
> >>
> >> It may be relevant that 1.3.7 Release has the same bug. 1.3.7
> >> was several months before Phil added RealFFTf, if that is what
> >> you are suggesting should be reverted.
> > In that case my comment needs to be edited.  I saw these comments
> > about a similar sounding bug so I thought this one might also be
> > related to the new code.  Still, I'd like to ask if anyone can explain
> > the member variables/DSP used here.
> >
> > I guess part of the confusion is due to me not understand all the DSP
> > going on.  I have implemented parametric EQ before, but as peak/shelf
> > filters in series.  The difference between the two systems is quite
> > amazing, as the shelf/peak method does not worry about windows - which
> > makes the overall system less complicated.
> >
> > The function I've been looking at is the InverseRealFFTf one.  The
> > issue I'm trying to understand is how the first 2000 samples (exactly
> > (mM - 1)/2, commented as the filter length) are zero values and then
> > suddenly the 2001st and beyond seem like normal values.  I don't
> > reallly understand what mM is, and how it is connected with the FFT
> > code - if anyone could help me out please do.
> >
> >
> >> I was assuming 1.3.8 would be released with this bug, as it is not
> >> a P1, and is noted in the README, so will be noted in the Release
> >> Notes.
> > That seems more probable.  I think I got a little too excited there,
> > with the half a bug I helped Dan fix, :)
> >
> > Michael
> >
> >
> >>
> >> Gale
> >>
> >>
> >>
> >>
> >>> On Wed, Jul 8, 2009 at 9:19 PM, Philip Van
> >>> Baren<[hidden email]> wrote:
> >>>> I submitted a change which allows you to enter a dB/decade frequency gain
> >>>> setting as a number (between 0 and 60, default to 0) instead of the
> >>>> checkbox. ?I wanted to put a slider in there, but I don't know enough about
> >>>> the GUI stuff to get the done in time for the code freeze. ?If anyone wants
> >>>> to jump in and make a slider out of it, I won't be offended ;)
> >>>>
> >>>> As for color palettes, I'm thinking maybe the grayscale checkbox could be
> >>>> changed to a drop list of different color palettes. ?I've attached a number
> >>>> of colormap definitions which are used by Matlab. ?You just need to copy the
> >>>> desired map into the GetColorGradient() function in AColor.cpp. ?My top two
> >>>> would be 'jet' and 'hot'. ?There isn't time to get this in before the code
> >>>> freeze, though.
> >>>>
> >>>> Phil
> >>>>
> >>>> --------------------------------------------------
> >>>> From: "Martyn Shaw" <[hidden email]>
> >>>> Sent: Wednesday, July 08, 2009 8:03 PM
> >>>> To: <[hidden email]>
> >>>> Subject: Re: [Audacity-devel] New FFT function
> >>>>
> >>>>> Hi Phil
> >>>>>
> >>>>> Philip Van Baren wrote:
> >>>>>>> I tried this with some music from a DAB radio and compared it on and
> >>>>>>> off, see here where the left-hand part is the 'new' scheme and the
> >>>>>>> right hand one is the 'old' scheme.
> >>>>>>>
> >>>>>>> http://files.getdropbox.com/u/1327769/spectrograms.png
> >>>>>>>
> >>>>>>> The old one shows the energy at low frequency, which is audibly
> >>>>>>> important but lost on the new one. ?A power factor of 1 worked better
> >>>>>>> on this particular file.
> >>>>>> I think this is more of an example of the midrange values all blurring
> >>>>>> together in that red/magenta range of the color table. ?Boosting the gain
> >>>>>> a
> >>>>>> touch might bring it back up into the white zone, but some more color
> >>>>>> table
> >>>>>> choices would probably help more.
> >>>>> You are probably right, I don't particularly like the current colour
> >>>>> scheme for spectrograms in Audacity. ?Can you come up with a better one?
> >>>>>
> >>>>>>> So why not go the whole hog and put in sliders for the 3 new variables
> >>>>>>> ?in prefs (like the 'Sound Activated Recording' one), plus a button
> >>>>>>> to reset to defaults. ?If you do, I'd make the 'enhance higher
> >>>>>>> frequencies' slider go down to zero and lose the check box (default
> >>>>>>> would be zero).
> >>>>>> This is a great idea, and simple to implement. ?I'll replace the check
> >>>>>> box
> >>>>>> with a slider.
> >>>>> I think that an all-or-nothing on the 'reset to defaults' button then
> >>>>> (and rapidly approaching code freeze).
> >>>>>
> >>>>>>> Oh yes, and why is maxFreq hardcoded like this? ?Surely fs/2 is the max?
> >>>>>>> SpectrumPrefs.cpp 213: ? if (maxFreq < 100 || maxFreq > 100000) {
> >>>>>> should be an easy fix.
> >>>>>>
> >>>>>> That isn't my code, but my guess is the prefs need to be global, and not
> >>>>>> limited to the sample rate of the current project or audio track.
> >>>>> I think writing the 'max' pref as 'max' would be good (rather than a
> >>>>> number), so that as the sample rate changed it would still go up to fs/2.
> >>>>>
> >>>>>> On another note, I would really like a "1-to-1" vertical zoom setting for
> >>>>>> the spectrogram display. ?The detail in the spectrogram display is much
> >>>>>> sharper when you match the pixels 1-to-1 with the spectrum values, but
> >>>>>> with
> >>>>>> the manual sizing it is hard to find the sweet spot. ?Anyone familiar
> >>>>>> with
> >>>>>> the vertical zoom code willing to take it on? ?I can add a function to
> >>>>>> map
> >>>>>> frequency range to number of pixels, if that helps...
> >>>>> I kind of see what you mean, but hadn't thought of it or seen the
> >>>>> problem. ?Care to post some images of what you mean?
> >>>>>
> >>>>> TTFN
> >>>>> Martyn
> >>>>>
> >>>>>> Phil
> >>>>>>
> >>>>>>> Thanks
> >>>>>>> Martyn

------------------------------------------------------------------------------
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/Challenge
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Michael Chinen]

On Mon, Jul 13, 2009 at 5:18 PM, Gale Andrews<[hidden email]> wrote:

>
> | From Martyn Shaw <[hidden email]>
> | Tue, 14 Jul 2009 00:27:35 +0100
> | Subject: [Audacity-devel] New FFT function
>> Thanks for that Phil!  I was going to get around to this, but never
>> did.  I can't confirm the fix as I never looked at the bug, but it
>> sound right.
>>
>> TTFN
>> Martyn
>
> As far as I can see, the bug's gone so I've already removed from
> Checklist, and will remove from the README since it had already
> been noted there.

Looks good here too.  I tried a bunch of different lengths.  Thanks again Phil!

Michael

>
> Thanks, Phil.
>
>
> Gale
>
>
>
>> Philip Van Baren wrote:
>>> I've submitted a fix for this.  The problem was when wcopy < (mM-1)
>>> there is a buffer overrun and the final overlap-add doesn't work
>>> properly.  This happens whenever the number of samples selected is
>>> between 1 and mM greater than any integer multiple of the chosen
>> > processing block size.
>> >
>> > Phil
>> >
>> > -----Original Message-----
>> > From: Michael Chinen [mailto:[hidden email]]
>> > Sent: Sunday, July 12, 2009 11:27 PM
>> > To: [hidden email]
>> > Subject: Re: [Audacity-devel] New FFT function
>> >
>> > On Sun, Jul 12, 2009 at 7:43 PM, Gale Andrews<[hidden email]> wrote:
>> >> | From Michael Chinen <[hidden email]>
>> >> | Sun, 12 Jul 2009 18:23:51 -0700
>> >> | Subject: [Audacity-devel] New FFT function
>> >>> I've been trying to figure out the P2 EQ Bug - silence at end of EQ
>> >>> (for around 26000 samples). ?It's 100% replicable if you select
>> >>> 26000+- 1000 samples and do an EQ. ?It looks like the Filter routine
>> >>> generates a window with the beginning 2000 samples truncated to 0 or
>> >>> very near zero values. ?I don't see any part of
>> >>> Equalization::ProcessOne() or Filter() that seem to affect these 2000
>> >>> samples, so this looks like a problem in the InverseRealFFT call. ?I
>> >>> don't know the code well enough to fix it immediately. ?As we have a
>> >>> release coming up, Philip, would you be willing to take a look and
>> >>> revert or fix this, or point me in some direction?
>> >> Hi Michael
>> >>
>> >> It may be relevant that 1.3.7 Release has the same bug. 1.3.7
>> >> was several months before Phil added RealFFTf, if that is what
>> >> you are suggesting should be reverted.
>> > In that case my comment needs to be edited.  I saw these comments
>> > about a similar sounding bug so I thought this one might also be
>> > related to the new code.  Still, I'd like to ask if anyone can explain
>> > the member variables/DSP used here.
>> >
>> > I guess part of the confusion is due to me not understand all the DSP
>> > going on.  I have implemented parametric EQ before, but as peak/shelf
>> > filters in series.  The difference between the two systems is quite
>> > amazing, as the shelf/peak method does not worry about windows - which
>> > makes the overall system less complicated.
>> >
>> > The function I've been looking at is the InverseRealFFTf one.  The
>> > issue I'm trying to understand is how the first 2000 samples (exactly
>> > (mM - 1)/2, commented as the filter length) are zero values and then
>> > suddenly the 2001st and beyond seem like normal values.  I don't
>> > reallly understand what mM is, and how it is connected with the FFT
>> > code - if anyone could help me out please do.
>> >
>> >
>> >> I was assuming 1.3.8 would be released with this bug, as it is not
>> >> a P1, and is noted in the README, so will be noted in the Release
>> >> Notes.
>> > That seems more probable.  I think I got a little too excited there,
>> > with the half a bug I helped Dan fix, :)
>> >
>> > Michael
>> >
>> >
>> >>
>> >> Gale
>> >>
>> >>
>> >>
>> >>
>> >>> On Wed, Jul 8, 2009 at 9:19 PM, Philip Van
>> >>> Baren<[hidden email]> wrote:
>> >>>> I submitted a change which allows you to enter a dB/decade frequency gain
>> >>>> setting as a number (between 0 and 60, default to 0) instead of the
>> >>>> checkbox. ?I wanted to put a slider in there, but I don't know enough about
>> >>>> the GUI stuff to get the done in time for the code freeze. ?If anyone wants
>> >>>> to jump in and make a slider out of it, I won't be offended ;)
>> >>>>
>> >>>> As for color palettes, I'm thinking maybe the grayscale checkbox could be
>> >>>> changed to a drop list of different color palettes. ?I've attached a number
>> >>>> of colormap definitions which are used by Matlab. ?You just need to copy the
>> >>>> desired map into the GetColorGradient() function in AColor.cpp. ?My top two
>> >>>> would be 'jet' and 'hot'. ?There isn't time to get this in before the code
>> >>>> freeze, though.
>> >>>>
>> >>>> Phil
>> >>>>
>> >>>> --------------------------------------------------
>> >>>> From: "Martyn Shaw" <[hidden email]>
>> >>>> Sent: Wednesday, July 08, 2009 8:03 PM
>> >>>> To: <[hidden email]>
>> >>>> Subject: Re: [Audacity-devel] New FFT function
>> >>>>
>> >>>>> Hi Phil
>> >>>>>
>> >>>>> Philip Van Baren wrote:
>> >>>>>>> I tried this with some music from a DAB radio and compared it on and
>> >>>>>>> off, see here where the left-hand part is the 'new' scheme and the
>> >>>>>>> right hand one is the 'old' scheme.
>> >>>>>>>
>> >>>>>>> http://files.getdropbox.com/u/1327769/spectrograms.png
>> >>>>>>>
>> >>>>>>> The old one shows the energy at low frequency, which is audibly
>> >>>>>>> important but lost on the new one. ?A power factor of 1 worked better
>> >>>>>>> on this particular file.
>> >>>>>> I think this is more of an example of the midrange values all blurring
>> >>>>>> together in that red/magenta range of the color table. ?Boosting the gain
>> >>>>>> a
>> >>>>>> touch might bring it back up into the white zone, but some more color
>> >>>>>> table
>> >>>>>> choices would probably help more.
>> >>>>> You are probably right, I don't particularly like the current colour
>> >>>>> scheme for spectrograms in Audacity. ?Can you come up with a better one?
>> >>>>>
>> >>>>>>> So why not go the whole hog and put in sliders for the 3 new variables
>> >>>>>>> ?in prefs (like the 'Sound Activated Recording' one), plus a button
>> >>>>>>> to reset to defaults. ?If you do, I'd make the 'enhance higher
>> >>>>>>> frequencies' slider go down to zero and lose the check box (default
>> >>>>>>> would be zero).
>> >>>>>> This is a great idea, and simple to implement. ?I'll replace the check
>> >>>>>> box
>> >>>>>> with a slider.
>> >>>>> I think that an all-or-nothing on the 'reset to defaults' button then
>> >>>>> (and rapidly approaching code freeze).
>> >>>>>
>> >>>>>>> Oh yes, and why is maxFreq hardcoded like this? ?Surely fs/2 is the max?
>> >>>>>>> SpectrumPrefs.cpp 213: ? if (maxFreq < 100 || maxFreq > 100000) {
>> >>>>>> should be an easy fix.
>> >>>>>>
>> >>>>>> That isn't my code, but my guess is the prefs need to be global, and not
>> >>>>>> limited to the sample rate of the current project or audio track.
>> >>>>> I think writing the 'max' pref as 'max' would be good (rather than a
>> >>>>> number), so that as the sample rate changed it would still go up to fs/2.
>> >>>>>
>> >>>>>> On another note, I would really like a "1-to-1" vertical zoom setting for
>> >>>>>> the spectrogram display. ?The detail in the spectrogram display is much
>> >>>>>> sharper when you match the pixels 1-to-1 with the spectrum values, but
>> >>>>>> with
>> >>>>>> the manual sizing it is hard to find the sweet spot. ?Anyone familiar
>> >>>>>> with
>> >>>>>> the vertical zoom code willing to take it on? ?I can add a function to
>> >>>>>> map
>> >>>>>> frequency range to number of pixels, if that helps...
>> >>>>> I kind of see what you mean, but hadn't thought of it or seen the
>> >>>>> problem. ?Care to post some images of what you mean?
>> >>>>>
>> >>>>> TTFN
>> >>>>> Martyn
>> >>>>>
>> >>>>>> Phil
>> >>>>>>
>> >>>>>>> Thanks
>> >>>>>>> Martyn
>
>
>
>
> ------------------------------------------------------------------------------
> 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/Challenge
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

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