Re: [Audacity-devel] New error reporting feature for recordings
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
Menu
▾
▴
Re: [Audacity-devel] New error reporting feature for recordings
|
From: Peter S. <pet...@gm...> - 2018-01-16 14:05:44
|
On Tue, Jan 16, 2018 at 2:01 PM, Cliff Scott <fly...@gm...> wrote: > > > On Jan 16, 2018, at 7:02 AM, Peter Sampson <pet...@gm...> > wrote: > > Hi Paul, > > I've just been testing and documenting this today: > https://alphamanual.audacityteam.org/man/New_features_in_this_release# > dropouts > https://alphamanual.audacityteam.org/man/Recording_Preferences#Options > > I tested on the latest Mac nightly using the temporary Tools menu item to > simulate > recording errors. > > I note, gratefully, that the "error label track" was a newly created label > track and did not > corrupt my existing label track. > > > My initial comment is made in the light of your comment in this thread and > in one of your commits > >Allow reporting of drop-outs to be turned off by Recording prefs... > > > >Just in case it turns out to make some false positives. > > If there is any chance whatsoever of false positives them I'm thinking > that the default for this new > option should be "off" rather than "on". > > I would not want my perfectly good recorded audio corrupted by any such > false positive. > > > Why would it be corrupted? If all the error reporting does is generate a > label track to indicate the location of the errors, which is my > understanding of what is proposed, how would that corrupt your data? Am I > missing something here? > Dropout detection We have added dropout detection for this release. This is controlled from a setting in Recording Preferences <https://alphamanual.audacityteam.org/man/Recording_Preferences> "*Detect dropouts*". - When this setting is "*on*" *(default setting)* Audacity will detect dropouts (brief gaps in the recording) and will insert zeroes into the recording to keep the other good parts synchronized. - When recording stops, a message box alerts the user and a label track is added showing the lost parts, labelled with consecutive numbers. Note the bit about "will insert zeroes into the recording to keep the other good parts synchronized" so if this is in response to a "false positive" then good data would/could be corrupted by such a change. Peter > > Cliff > > > Additionally I note that the error message is rather long (TL;DR possibly) > - in general shorter messages > are to be preferred to longer ones as users are more likely to read them > properly. > > Peter. > > On Mon, Jan 15, 2018 at 11:50 PM, Paul Licameli <pau...@gm...> > wrote: > >> >> >> On Mon, Jan 15, 2018 at 6:23 PM, Peter Sampson < >> pet...@gm...> wrote: >> >>> >>> >>> On Mon, Jan 15, 2018 at 11:19 PM, Paul Licameli <pau...@gm... >>> > wrote: >>> >>>> >>>> >>>> On Mon, Jan 15, 2018 at 5: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. >>>>> >>>>> 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. >>>>> >>>>> For example, it is possible that creating labels will slow the >>>>> recording down further, and lead to many more drop outs, on slow machines. >>>>> >>>> >>>> If you mean the labels created by this project, no, it doesn't happen >>>> until recording is finished. >>>> >>>> >>>>> >>>>> 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). >>>>> >>>> >>>> My only concern is that it might make false-positive reports, which I >>>> have not seen yet. You are right that making a preference to disable the >>>> warning could save us if that ever happens. >>>> >>> >>> >>>> But by default, I would want the reporting turned on. >>>> >>> >>> >>> +1 I agree >>> >>> Peter >>> >> >> Quite easily done. >> >> I have added a checkbox to Recording preferences. Its label is a third >> user-visible string for this project: >> >> "Detect dropouts" >> >> This is at commit d2749068f145519a6b71dd91ca72961da8f7b52d. >> >> PRL >> >> >>> >>> >>> >>>> But if ever it makes real reports, it will have done a very useful >>>> thing for the users. >>>> >>>> PRL >>>> >>>> >>>> >>>>> >>>>> --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 >>>>> >>>> >>>> >>>> ------------------------------------------------------------ >>>> ------------------ >>>> 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 >>>> >>>> >>> >>> ------------------------------------------------------------ >>> ------------------ >>> 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 >>> >>> >> >> ------------------------------------------------------------ >> ------------------ >> 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 >> >> > ------------------------------------------------------------ > ------------------ > 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 > > > > ------------------------------------------------------------ > ------------------ > 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 > > |
