Re: [Audacity-devel] Plot Spectrum normalises multiple-track input inappropriately

[Martyn S. <mar...@gm...>]

Hey

Thanks for your intelligent input Mike!

Martyn

On 28/07/2011 14:46, Mike Walmsley wrote:
> Hi Martyn,
>
> Many thanks for that - I'll pick it up and check it out.
>
> I agree that understanding the spectral impact of the clipping is of negligible benefit to anyone - I implemented the clipping largely because I was too scared of unintended consequences downstream on the FFT and the GUI if levels greater than 0dB were present.  I'll not put it in as a feature request/proposal, therefore.
>
> Cheers,
>
> Mike W.
>
>
>
> -----Original Message-----
> From: Martyn Shaw [mailto:mar...@gm...]
> Sent: 23 July 2011 01:31
> To: aud...@li...
> Subject: Re: [Audacity-devel] Plot Spectrum normalises multiple-track input inappropriately
>
> Hi Mike
>
> That dBm0 was a new one for me, I must say.  Thanks for that.
>
> I've removed the normalisation on the number of tracks, since it seems
> wrong to me as well, and won't have any impact on most people.
>
> The change to render the spectrum as if it were exported (clipped)
> would have to be an option (defaulted off), if it were to be
> implemented.  I suggest that you add that to
> http://wiki.audacityteam.org/wiki/Feature_Requests or possibly add a
> Proposal page, like
> http://wiki.audacityteam.org/wiki/Proposal_DC_Management and so on.
> Certainly it could be optionally done, but would it be a popular
> option?  Maybe not.  We have so many 'options' already that I am
> hesitant to put it in.  And if it's just for you ,clearly you can
> compile your own version!
>
> A new version of Audacity should pop up on
> http://wiki.audacityteam.org/index.php?title=Nightly_Builds or
> http://www.gaclrecords.org.uk/audacity.html at some point, depending
> on your OS.
>
> It's good to see somebody who cares about the details, and I hope that
> you will continue to contribute here.  I care about the details too
> and like to see me 'scientific' and accurate measurement stuff built in.
>
> TTFN
> Martyn
>
> On 22/07/2011 10:18, Mike Walmsley wrote:
>> Hi Martyn,
>>
>> Thanks for your response. Detailed comments in line below, but in summary:
>>
>> Sorry I wasn't clear about the signal level. I don't have a problem with where the 0dB point is set for single track inputs - you're right that it's at a sinusoid of 1.0 peak-peak amplitude. In telecoms we typically use a different reference level, but that's fine since it's a fixed offset.  I have tendency to add in the offset in the wrong direction, but that's my problem not Audacity's! My issue was that the reported level for the same track goes down as soon as I select more tracks.
>>
>> I'd like to see the impact of clipping on the spectrum, reflecting what would happen if I rendered the tracks in their current state. I can see that there's a case for keeping the spectrum "clean" as Audacity hasn't clipped the track until it has been rendered, but perhaps I'm just a pessimist...
>>
>> Detail below.
>>
>> Cheers,
>>
>> Mike W.
>>
>>> -----Original Message-----
>>> From: Martyn Shaw [mailto:mar...@gm...]
>>> Sent: 22 July 2011 01:07
>>> To: aud...@li...
>>> Subject: Re: [Audacity-devel] Plot Spectrum normalises multiple-track
>>> input inappropriately
>>>
>>> Hi Mike
>>>
>>> On 20/07/2011 13:52, Mike Walmsley wrote:
>>>> Hi,
>>>>
>>>> Great fan of Audacity and I use it for both work and leisure.
>>>
>>> That's great!  Thanks for your interest!
>>>
>>>> Using "Analyse>    Plot Spectrum" to analyse signals in a telecoms
>>> environment, I became
>>>> perplexed by some of the signal levels which seemed (a) wrong and (b)
>>> variable
>>>> depending how I invoked the feature.
>>>
>>> (a) I think depends on your point of view, (b) is true, and probably a
>>> mistake, thanks for spotting that!  See below.
>>>
>>>> I investigated and discovered that behaviour depends on how many
>>> tracks are selected
>>>> when invoking the Frequency Analysis window. FreqWindow::GetAudio()
>>> realises when
>>>> handling multiple tracks that the resulting mixed signal may exceed
>>> the +-1.0 dynamic
>>>> range, so it normalises an n-track input by 1/n.
>>>
>>> Hmm.  I have my name against some of that code, as does llucius
>>> (Leland) (who always claims he's an audiot).  I think we scaled it
>>> down since we did not have auto-scaling in at that point, but I may be
>>> wrong.  It does look odd now.
>>>
>>>      This seems flawed on several
>>>> counts:
>>>>
>>>>       1)  Signal levels in the spectrum are reported at incorrectly low
>>> levels.
>>>
>>> We have had many discussions about that, but I'm afraid I'm no good at
>>> Nabble references to them.  From what I recall we were only talking
>>> about one track.  I believe that a full-amplitude sinusoid is reported
>>> @ about 0dB?
>>
>> 1.0 pk-pk sine is reported as 0dB in Audacity. In telecoms we use a
>> different reference point - see http://en.wikipedia.org/wiki/Dbm0 for a
>> discussion of dBm0. However, this just results in Audacity's 0 dB being
>> +3 dBm0 (approx), so no big deal. I'm not arguing for a change in the
>> behaviour for the single track case.
>>
>>>
>>>>       2)  If mixing the tracks will result in clipping, the resulting
>>> spectral
>>>>           mess is hidden from the user.
>>>
>>> Now, what to do about that?  Is it a mess?  Internally we do not clip
>>> waveforms until they are rendered by some sort of export, be it by
>>> file or listening.  So it isn't a mess internally and so isn't
>>> reported so by Plot Spectrum.  If you mix stuff via Tracks ->   Mix and
>>> Render you can always do Effect ->   Amplify and get back to a
>>> non-clipped track for export, which is quite kind.  Feel free to argue
>>> back!
>>
>> I'd argue you'd either want to see the accurate-levels-without-clipping,
>> giving the "cleanest" view of the tracks, or accurate-levels-with-clipping,
>> giving the "most realistic" view of the tracks once they're rendered.
>> Inaccurate-levels-without-clipping just seems confusing. My personal
>> preference was for a view of the spectrum if I chose to render the tracks
>> in their current state, hence the clipping. This also had the benefit that
>> I didn't need to worry about whether the FFT code would accept signals
>> outside +/- 1.0 amplitude, which the accurate-levels-without-clipping
>> would imply.
>>
>>>
>>>>       3)  Both the above mean that what the ear will perceive when
>>> Exporting or
>>>>           Mix&    Rendering the tracks is not what the spectral analysis
>>> suggested.
>>>
>>> See above.
>>>
>>>> The attached patch changes the behaviour to clip the mixed signal
>>> used as input to
>>>> the FFT at +-1.0. I've tested the patch and it behaves as I expect:
>>> signals within
>>>> the dynamic range give consistent spectral results irrespective of
>>> the number of
>>>> tracks selected;
>>>
>>> I believe that this is important and we should probably lose that
>>> normalisation.  Currently if we analyse a track, and then analyses it
>>> along with a silent track we get a different result, which does not
>>> seem right.  Please respond here + or - or I will forget to change it.
>>>
>>> TTFN
>>> Martyn
>>>
>>>     signals which exceed the dynamic range show the expected mess in
>>>> the frequency domain arising from the clipping.
>>>>
>>>> Before accepting this patch, there are some considerations needed by
>>> those more
>>>> knowledgeable of Audacity's internals than me:
>>>>
>>>>       1)  I believe that this strategy of clipping is equally
>>> applicable to the
>>>>           Cepstrum and Autocorrelation functions of the Frequency
>>> Analysis window.
>>>>           However, I'm less familiar with these other techniques, so it
>>> would be good
>>>>           if someone could confirm my view.
>>>>
>>>>       2)  My implementation of the clipping is very straightforward,
>>> but I don't know
>>>>           if there are any utility functions or better methods
>>> available within
>>>>           Audacity to clip a signal efficiently.
>>>>
>>>>       3)  I suppose a case could be made that keeping the signal
>>> normalised rather
>>>>           than clipped is appropriate in some contexts. I struggle to
>>> see when, so
>>>>           I didn't see a need to make this behaviour a selectable
>>> option in the
>>>>           Frequency Analysis window. Others may disagree.
>>>>
>>>> Shout if there's anything I need to fix or clarify...
>>>>
>>>> Hope that helps!
>>>>
>>>> Mike Walmsley
>>>>
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>> ---------
>>>> 10 Tips for Better Web Security
>>>> Learn 10 ways to better secure your business today. Topics covered
>>> include:
>>>> Web security, SSL, hacker attacks&    Denial of Service (DoS), private
>>> keys,
>>>> security Microsoft Exchange, secure Instant Messaging, and much more.
>>>> http://www.accelacomm.com/jaw/sfnl/114/51426210/
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> audacity-devel mailing list
>>>> aud...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>>
>>> -----------------------------------------------------------------------
>>> -------
>>> 10 Tips for Better Web Security
>>> Learn 10 ways to better secure your business today. Topics covered
>>> include:
>>> Web security, SSL, hacker attacks&   Denial of Service (DoS), private
>>> keys,
>>> security Microsoft Exchange, secure Instant Messaging, and much more.
>>> http://www.accelacomm.com/jaw/sfnl/114/51426210/
>>> _______________________________________________
>>> audacity-devel mailing list
>>> aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>> ------------------------------------------------------------------------------
>> 10 Tips for Better Web Security
>> Learn 10 ways to better secure your business today. Topics covered include:
>> Web security, SSL, hacker attacks&   Denial of Service (DoS), private keys,
>> security Microsoft Exchange, secure Instant Messaging, and much more.
>> http://www.accelacomm.com/jaw/sfnl/114/51426210/
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Storage Efficiency Calculator
> This modeling tool is based on patent-pending intellectual property that
> has been used successfully in hundreds of IBM storage optimization engage-
> ments, worldwide.  Store less, Store more with what you own, Move data to
> the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Got Input?   Slashdot Needs You.
> Take our quick survey online.  Come on, we don't ask for help often.
> Plus, you'll get a chance to win $100 to spend on ThinkGeek.
> http://p.sf.net/sfu/slashdot-survey
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel