>>Does this leave a residual lower priority bug to fix, i.e. the cause of
>>former crash, or is the some reason we can never repair the >whole of
>>a new length of audio?
> I don't know what the former crash was exactly, can it be reproduced now?
No the crash can't be reproduced because we've stopped it, but the symptoms
that caused it are still there. The original report was from someone who
selected 128 samples to repair, then hit CTRL + D (duplicating the
selection) instead of CTRL + R (so as to Repeat "repair"). D + R are close
to each other on the keyboard, so he was doing this many times. So when he
hit CTRL + R after CTRL + D, Audacity crashed. After your fix, he gets your
error message instead, but he does actually want to repair his 128 samples.
> There is a very good reason why we can't repair the whole audio. By
> example, repair the folowing sentances yourself:
> "This is repai***le" (a broken bit within a good bit)
> "**dacity" (a broken bit followed by good data)
> "G*************" (a good bit followed by lots of broken stuff, you'd
> be guessing wildly) "**************" (nothing good, no idea)
> See? You need some data to at least one side of the good bit in order
> to extrapolate new data in the selected region, th more you have the
> better you can do.
Sure, but we don't give them this help if they select some audio within an
>>In your error message:
>>"The Repair effect needs some data to go on. Please select an area to
>>repair with some audio on at least one side (the more the better)"
>>I'm guessing most people will in fact already have the entire length
>>selected, and if what they did wasn't a mistake, may actually want to
>>repair the entire length.
> It was mistake, see above, that's why it's not allowed.
It happened to be a mistake in the intial crash report, but it might not be.
Someone may want to duplicate their 128 samples, and if they repair first,
then duplicate, there is no error. But if they duplicate first and then
repair, there is an error, despite the fact that the original and duplicated
audio are the same, and despite if they repaired the original on its own,
there would be no error.
>>Is "Please select a region to repair inside the track, or repair the
>>original region" clearer (as well as shorter)?
>Not much. Do you see what is possible now?
My two concerns were about "audio on at least one side", and that people
would already have the whole region selected, so your suggestion that the
Repair tool did not have data to go on might seem unintuitive.
Maybe I'm struggling a bit with what Repair does. I can read in the code
that it interpolates, and works best with undamaged audio either side. But I
guess most people use it for click repair, and if they see three samples way
out of line and no others, they will tend to only select those three, and
usually based on my experience that works fine. So that was why I was
struggling a bit to understand your error text, and thought the average user
might too. If I could visualise better what a region of generally messed up
audio looks like (not just a clean click), there may (or may not) be a
better way to phrase it.
Anyway, my main point remains that if Repair tool can legitimately repair a
region of 128 samples selected by the user, why can't it repair that
identical selection when it's duplicated to another track, so should be
identical to the original which it can repair?
View this message in context: http://n2.nabble.com/Another-way-to-crash-with-Repair-tp1094823p1120245.html
Sent from the audacity-devel mailing list archive at Nabble.com.