Repair/Auto Heal

[audacity-voice-guy]

I would really like to see a much better/longer "Repair" function, similar to 'Auto Heal' in other software such as Audition, Amadeus Pro, etc., or at least allowing the sample size to be adjusted to a greater length.

The current size of 128 samples is too ridiculously short to be of any use in most cases for speech, including relatively short noises, such as mouth clicks.

The repair/autoheal I am speaking of also seems similar- analyzing audio before and after the selected sample to adjust what seems too anomalous.

I was reading somewhere that this would take processing time, but this feature has been available in other software for many years, and takes very little time at all, even on older computers, so that would not seem to be the problem.

[steve]

The repair algorithm that Audacity uses in the Repair effect is "Least Squares AutoRegression". This algorithm produces extremely good results provided that the damaged audio is surrounded by lots of good audio, but the processing time rises rapidly as the number of samples increases. On a 2 GHz dual core Intel processor, a repair length of 500 samples takes about 50 seconds. Perhaps you can suggest a faster algorithm that produces equally good results?

In the meantime, I have added your vote for increased repair length.

[NTL2009]

Please add my vote to an increase in sample length for the 'Repair' effect.

I understand now that the time increases by huge amounts as sample size increases, but sometimes that's fine - I can just take a break or read email or something.

It could be nice to have feedback on the estimated time required. I know it can be complicated to try to predict times on different hardware, but maybe just something relative to the 128 sample execution time? IOW, display 128 samples as "1X" and 500 sample size as "50X" (assuming here that 500 samples takes 50x longer than 128 samples). I'm assuming the relative times would be similar across different machines? A rough guide would be helpful, to avoid 'surprises'.

BTW, I've been using this effect a lot lately (digitizing LPs), and have come up with a workflow that I'm tweaking that seems to be working well for me. I think it may offer some advantages over what is in the current wiki, or is at least a viable option - personal preferences vary. Once I have tweaked it a bit, I'll post it in the forum for feedback. Quick overview: create two duplicate tracks for visual cues only; apply extreme compression to one to eliminate the need to change display amplitude to see the 'click'; apply a 4000HZ brickwall HP filter to the other duplicate, maybe with compression - (I'm working out the details here) - to make the high frequency clicks stand out. Turn volume of the duplicates to zero. Listen for clicks in the original, and I've always got a clear visual cue as to where the click from the two 'visual' tracks. Drag across all three tracks, and use 'Repair'. This has been very fast and effective for me - I'll work out some details on compression and equalizer settings, and then publish the workflow.

-NTL2009

[steve]

Please add my vote

I've added your vote and noted your suggestion.

[Gale Andrews]

It could be nice to have feedback on the estimated time required. I know it can be complicated to try to predict times on different hardware, but maybe just something relative to the 128 sample execution time? IOW, display 128 samples as "1X" and 500 sample size as "50X" (assuming here that 500 samples takes 50x longer than 128 samples). I'm assuming the relative times would be similar across different machines? A rough guide would be helpful, to avoid 'surprises'.

512 samples is unusable on my modest Windows machine (2.4 GHz 6 GB RAM). Needs to be force quit even after half an hour, the last time I tried it.


Gale

[Paul L]

I am following this conversation.

Is this effect suitable for the problems you try to fix with Repair?

http://forum.audacityteam.org/viewtopic ... 42&t=79278

[NTL2009]

...
512 samples is unusable on my modest Windows machine (2.4 GHz 6 GB RAM). Needs to be force quit even after half an hour, the last time I tried it.
Gale

OK, without being able to try it, I can't offer any feedback on times. So if 512 is too extreme, it would still be useful to offer a higher count if the increase isn't unrealistic. So I don't know, would 192, or 256 be crazy long on high end hardware? A setting to allow the user to set the max would be flexible and future-proof (as hardware improves).

Another thing that would be super useful (but maybe very difficult to code, I don't know), would be some feedback or limits on the sample selection while in REPAIR, rather than just the current "I'm sorry, Dave. I'm afraid I can't do that". Like if you got the warning dialog, it could auto-truncate the selection length, but still allow you to drag it left/right, and hit ENTER (or CANCEL if it doesn't make sense on the smaller selection), w/o needing to get in/out of REPAIR mode. Seems minor, but de-clicking is tedious, and any work-flow improvements have big returns in time saved (and sanity!).

I am following this conversation.

Is this effect suitable for the problems you try to fix with Repair?

http://forum.audacityteam.org/viewtopic ... 42&t=79278

Thanks, I'll re-visit that in detail a little later - I thought I was 'subscribed' to this topic, but I wasn't so I lost track - I will be back!

-NTL2009
See new topic at http://forum.audacityteam.org/viewtopic ... 20&t=84751

[Gale Andrews]

Another thing that would be super useful (but maybe very difficult to code, I don't know), would be some feedback or limits on the sample selection while in REPAIR, rather than just the current "I'm sorry, Dave. I'm afraid I can't do that". Like if you got the warning dialog, it could auto-truncate the selection length, but still allow you to drag it left/right, and hit ENTER (or CANCEL if it doesn't make sense on the smaller selection), w/o needing to get in/out of REPAIR mode. Seems minor, but de-clicking is tedious, and any work-flow improvements have big returns in time saved (and sanity!).

OK, a few others have made that suggestion, so I added the votes now.


Gale

[steve]

The time taken to process is not the only consideration to setting the maximum length for the Repair tool. A slow computer should be able to process over 500 samples "eventually" (though it may take a very long time). The algorithm used by the Repair tool works very well with short clicks provided that there is an adequate amount of "good" audio surrounding the selection, but with long selections the results can be quite peculiar and not at all useful. Depending on the type of damage, alternative approaches to repair may well yield better results.

[NTL2009]

The time taken to process is not the only consideration to setting the maximum length for the Repair tool. A slow computer should be able to process over 500 samples "eventually" (though it may take a very long time). The algorithm used by the Repair tool works very well with short clicks provided that there is an adequate amount of "good" audio surrounding the selection, but with long selections the results can be quite peculiar and not at all useful. Depending on the type of damage, alternative approaches to repair may well yield better results.

True, and I'd guess that 80% of my repairs are probably in the 40 sample range. But occasionally, I see a case where encompassing just a little more than 128, maybe 140-150 samples, would help to select some of the weird squiggles and then the surrounding shape looks good. I can do it in sections, but then the 'weird' part gets considered in the correction. I don't doubt that 500 samples could end up with peculiar results sometimes. It is getting to ~ 11 msec (at CD rates), down to around 88 Hz range, so yes, could be a problem and create thumps/bumps. But why not let the user decide?

Of course, I have no knowledge of the code, but if this is simply(?) changing a variable from 128 to (something larger*) and letting the existing code just crank more w/o any other re-write of that code, the downside seems minimal.

* maybe this should be an entry in preferences, with the current 128 as default? The prefs dialog could include the warnings, so should be no surprise the user. The current warning dialog for 'Repair' could reference the ability to change the max samples in preferences.

I tried testing on my current, modest i3 laptop, and a 128 sample repair is too quick to really measure, way less than one second. On my old (2009), cheap ASUS EEE-PC901 with a very low power ATOM processor, I got ~ 5~6 seconds for a 128 sample repair, and I think less than 1 second for a 64 sample repair. So I'm guessing a doubling of 128 to 256 on modern middle-road hardware might still only be ~ 5~6 seconds? Sure, 500 samples might get crazy long (minutes), but the user could set their preferences according to their hardware and needs. I think 128 is still a good default to keep the idea that it is geared towards small repairs.

I hope I'm not being too much of a PITA with this, or making a mountain out of a molehill - I guess for the coding that I did do (many years ago), I just learned to have an aversion for hard-coded limits!

Thanks for all the feedback - very interesting! - NTL2009