Re: [Audacity-devel] New error reporting feature for recordings

[Peter S. <pet...@gm...>]

On Mon, Jan 15, 2018 at 10:57 PM, James Crook <cr...@in...> wrote:

> +1 to doing something about drop outs. Bravo.  I have found drop outs very
> annoying in the past.  Much better to know about them at the time of
> recording.
>


+1

I cannot but agree with this  :-)



> I think though that this is a risky change to make late in 2.2.2.
> There is not going to be a lot of time to thoroughly test it out on a
> range of different machines before 2.2.2 is released.
>


+1   I agree - but I'd love to see this for the release after 2.2.2

Peter.


> For example, it is possible that creating labels will slow the recording
> down further, and lead to many more drop outs, on slow machines.
>
> I think if you are serious about this for 2.2.2, as a minimum it needs a
> preference that can be used to disable it.
> recording-preferences -> Report recording errors  .  The preference can be
> normally on by default.  If we do find it is causing problems, we can tell
> affected users to disable it, rather than have to issue an emergency fix
> release (or tell them to go back to 2.2.1).
>
> --James.
>
>
> On 1/15/2018 8:29 PM, Paul Licameli wrote:
>
>> I pushed it at 9777d3e88009e593035c77be2a5835ce76ce0765
>>
>> Up first: what matters before string freeze:  There are two new
>> user-visible strings.  Suggest detailed wording changes soon, please!
>>
>>
>>     - "Errors" is a name given to a new label track.  (I decided
>> "Recording
>>     errors" was too long to appear properly in the TCP menu button.)
>>     - A long message box text:
>>
>>
>> "Recorded audio was lost at the labelled locations.\n\
>> This may have happened because you are saving directly to a \
>> slow external storage device, or because other applications are \
>> competing with Audacity for processor time."
>>
>> Secondly: the rationale.
>>
>> In my usage of Audacity, before I get a faster computer, I did notice,
>> rarely, on a Windows laptop that occasional syllables of my recorded voice
>> were dropped out, as if a few milliseconds had been deleted.  I noticed
>> this only becauase I proofed my work carefully.
>>
>> I have heard a few complaints of similar things too from users, in a
>> discussion group I manage for narrators.  I think that in one case,
>> someone
>> was trying to record directly onto a slow external device, like a thumb
>> drive.
>>
>> In a few other cases, the recording glitches were very dense in a short
>> space, making the recordings unsalvageable.  The users ultimately decided
>> that it was a symptom of the computer's internal storage devices going
>> bad,
>> because bad effects were seen with other programs.
>>
>> In most cases, the default suspicion is that Audacity is competing for CPU
>> with other applications or background virus checkers, which should be
>> closed and disabled before you try again.  Audacity fails to keep up in
>> real-time with the stream of input samples because of this.
>>
>> In all these cases, the user only knows there is a problem when listening
>> to the recording again.  But if Audacity has the means to detect the
>> error,
>> it should give the user some alert, sooner, so the problem might be
>> corrected before recording again.
>>
>> And Audacity was detecting the errors, but only writing debug messages to
>> standard output that only programmers were likely to notice:
>> wxPrintf(wxT("lost %d samples\n"), (int)(framesPerBuffer - len));
>>
>> This new feature gives the user an alert.  I am not wholly satisfied,
>> because the alert is a modal dialog that happens only after the recording
>> is complete.  I think a better solution might pop up a modeless dialog
>> during recording, as soon as the problem is detected, giving the user the
>> option to stop the recording, but otherwise continuing it.  This would let
>> a user stop a bad recording very early instead of going on ten or twenty
>> minutes only to discover then that it was bad.  But this requires some
>> more
>> programming effort.  Perhaps for a later release.
>>
>> On the other hand, if the errors are very few and far between, and easily
>> repaired with a few pickups, then this feature should be very convenient
>> to
>> pinpoint them.
>>
>> Thirdly: the details of this project.  Quoting my commit comment:
>>
>>
>>      Alert user to drop-outs during recording...
>>
>>      1) When the program detects this, insert zeroes into the recording to
>> keep the
>>      other good parts synchronized.
>>
>>      2) When recording stops, a message box alerts the user, and a label
>> track is
>>      added showing the lost parts, labelled with consecutive numbers.
>>
>>      3) A menu item visible in alpha builds only is added to Tools, to
>> simulate
>>      recording errors at random times and test the reporting feature.
>>
>> Lastly:  I would like others to try this out and comment.  Try it with the
>> simulated errors to see if you like the details of the reporting
>> mechanism.  Try recordings without this, to be sure we don't get frequent
>> false positives on any operating system.
>>
>> PRL
>>
>>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> audacity-devel mailing list
> aud...@li...
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>