Re: [Audacity-devel] Potential P2 in Audacity 2.0.0 alpha

[Steve t. F. <ste...@gm...>]

On 13 February 2012 00:33, Martyn Shaw <mar...@gm...> wrote:
>
>
> On 10/02/2012 02:09, Steve the Fiddle wrote:
>> On 10 February 2012 00:58, Martyn Shaw<mar...@gm...>  wrote:
>>>
>>>
>>> On 09/02/2012 01:26, Steve the Fiddle wrote:
>>> <snip>
>>>>
>>>> 192 dB is of course "a lot", and sound cards should not produce values
>>>> anywhere near that level. However, the "real world" example recording
>>>> that brought this issue to our attention had sample values in excess
>>>> of 700 dB - obviously corrupt data and clearly not very common, but if
>>>> one single bad sample value from a USB sound card can trash hours of
>>>> work by causing the exported audio to flat-line half way through, then
>>>> it is more than a minor issue for the user (especially if they have
>>>> just closed the project without saving, in the belief that they had
>>>> safely exported a WAV file).
>>>
>>> I believe that is now fixed, but I have a question.  Has a NaN ever
>>> been seen in the "real world" of capturing audio or are they only
>>> created by Nyquist? (Or another answer.)  If they are created in
>>> hardware then we should do one thing to trap them, if they only come
>>> out of Nyquist then the solution should be different.
>>
>> I've seen *one* example of a "real world" NaN.
>> I don't know how it occurred, whether it was from direct capture or
>> something else, but the user was not messing around with Nyquist.
>
> Ouch!  But it is only one in the 'real world', out of very very many.

It's not possible to say how rare this is. The *one* example that I've
seen was in a project where I specifically tested for illegal sample
values due to the user reporting the "flat-line -1 samaples" issue.
There could well be more cases that have not been identified as such,
but I think that it is safe to say the the occurrence is very rare.


>
> Testing for Infs and NaNs as data comes into Audacity (from Nyquist,
> capture or maybe files (?)) could take up a lot of cycles.  But they
> could cause Audacity to crash on their very rare (or deliberate, by
> your method) occurrence.

I don't really see how NaNs are possible directly from capture, as the
capture data should always be integer.


>
> I'm not sure what to do here, from a 'user experience' perspective, as
> NaNs in data can cause crashes or other undesirables.  'Spectrogram'
> view (for example) currently crashes with a Nan in the data (easily
> fixed, but it would slow it down), I don't know what else crashes with
> a NaN.

There's probably not much that can be done without more information
about where NaNs come from.
We don't really want to slow down the Spectrogram view as it is fairly
slow already.

I suppose the good thing about Spectrogram view crashing, is that from
a diagnostic point of view it provides a quick and easy test for the
presence of a NaN.


>
> I don't think that Nyquist should hand back NaNs to Audacity, but
> maybe Audacity should trap them if it does, and if given any by other
> sources?

The only way that I've found so far to produce NaNs with Nyquist is
with the biquad filter (and any higher level function that uses the
biquad filter, such as "highpass2").

I proposed a patch for dspprims.lsp that prevents NaNs from being
created by the biquad filter (see bug 152).
Roger Dannenberg's comment was:

"It looks to me like the problem is deeper, and we're just masking it with the
check. It's on my list to look at, but meanwhile I think the suggested patch is
a good idea. Thanks!"

Now that we are more aware of the issue, I would suggest that
dspprims.lsp should be patched to prevent Nyquist from returning NaNs
(I'll keep an eye out for any other Nyquist function producing NaNs,
but so far this is the only one). Bug 152 can then be closed and a new
bug about the deeper problem (handling of NaNs and infinites) can be
raised.

>
> I don't think that this should hold up 2.0 though, as it's so obscure.

I agree, though the effects can be severe so I think that it should
still have quite a high P rating.

Do we know for certain that NaNs are not responsible for some of the
MoonPhase bugs (for example bug 341)?
(a quick test with Audacity 2.0.0 on Linux; the presence of a single
NaN value in an audio track causes some corruption to the audio after
the NaN when exporting as AAC with FFmpeg).

Steve

>
> TTFN
> Martyn
>
>> Steve
>>
>>
>>>
>>> Thanks
>>> Martyn
>>>
>>>> If Michael's fix prevents flat-line exports, even with infinite and
>>>> NaN sample values present, then I think we should go with that one for
>>>> now, though the bug should remain open, pending a fix of the cause.
>>>> (just my 2p)
>>>>
>>>> Steve
>>>>
>>>>
>>> <snip>
>>>
>>> ------------------------------------------------------------------------------
>>> Virtualization&  Cloud Management Using Capacity Planning
>>> Cloud computing makes use of virtualization - but cloud computing
>>> also focuses on allowing computing to be delivered as a service.
>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>>> _______________________________________________
>>> audacity-devel mailing list
>>> aud...@li...
>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>>
>> ------------------------------------------------------------------------------
>> Virtualization&  Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> audacity-devel mailing list
>> aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel