Page 2 of 3
Re: Suggestion: Repair Limits
Posted: Mon Oct 07, 2013 2:04 pm
by waxcylinder
steve wrote:waxcylinder wrote: ... there was a suggestion that larger sections could be repaired as a sequence of 128 sample length blocks. Initial tests indicated that this might work, but as yet it has not progressed much more than that.
The question then is just where do you start the processing and what order do you continue in.
I do this manually sometimes but it requires a fair bit of judgment where and when to do the various repairs - and can require recursive or overlapping repairs - I'm doubting that it will be possible to automate this through an algorithm - but I'd be happy to be proved wrong
Peter
Re: Suggestion: Repair Limits
Posted: Mon Oct 07, 2013 2:41 pm
by Edgar
steve wrote:waxcylinder wrote:I seem to recall that lengthening the repair selection exponentially increases the processing time
Yes - for selections greater than 128 samples the repair time rises very rapidly. However, there was a suggestion that larger sections could be repaired as a sequence of 128 sample length blocks. Initial tests indicated that this might work, but as yet it has not progressed much more than that.
srceffectsRepair.cpp, at or near line 34, add these two lines:
Code: Select all
#define MAXIMUMSAMPLECOUNT 256
#define MAXIMUMSAMPLECOUNTFLOAT 256.
both of these must have the same value (this just makes it easy to play around with various values).
At or near line 81, make this change:
Code: Select all
//if (spacing < 128. / rate)
// spacing = 128. / rate;
if (spacing < MAXIMUMSAMPLECOUNTFLOAT / rate)
spacing = MAXIMUMSAMPLECOUNTFLOAT / rate;
At or near line 105, change this code:
Code: Select all
if (repairLen > 128) {
::wxMessageBox(_("The Repair effect is intended to be used on very short sections of damaged audio (up to 128 samples).nnZoom in and select a tiny fraction of a second to repair."));
bGoodResult = false;
break;
}
so that it looks something more like this:
Code: Select all
if (repairLen > MAXIMUMSAMPLECOUNT) {
wxString message;
wxString math;
math.Printf(_("The Repair effect is intended to be used on very short sections of damaged audio (up to %d samples).nn"), MAXIMUMSAMPLECOUNT);
message.append(math);
message.append(_("You have chosen "));
wxString repairLength;
repairLength.Printf(wxT("%d"), repairLen);
message.append(repairLength.c_str());
message.append(_(" samples.nn"));
message.append(_("Zoom in and select a tiny fraction of a second to repair."));
::wxMessageBox(message);
bGoodResult = false;
break;
}
all this does is pick up our modified maximum sample count and makes the error message a little bit more informative by telling the user how many samples are currently chosen.
I find that invariably I need someplace between 150 and 200 samples when I go to repair. I know my hardware is probably faster than average (Intel Core 2 Duo E6850 3.0 GHz FSB1333 LGA775, 2X OCZ DDR3 PC3-12800 4GB Kit = 8GB ram) but I find that with a maximum set out either 128 or 256 Repair runs virtually instantaneously. I've never bothered to check any longer maximums because I'm concerned that the smoothing code would be confused. However, using 256 is a maximum works just fine.
Re: Suggestion: Repair Limits
Posted: Wed Oct 09, 2013 3:41 am
by Gale Andrews
steve wrote:there was a suggestion that larger sections could be repaired as a sequence of 128 sample length blocks. Initial tests indicated that this might work, but as yet it has not progressed much more than that.
My money is that is where the effort needs to be directed. I suspect an algorithm could be smarter about "where to repair" than just scanning blocks of 128 samples.
I agree there is no reason to withdraw the ability to manually repair selections of a few hundred samples or less, since that would give optimal results given a skilled user.
Gale
Re: Suggestion: Repair Limits
Posted: Wed Oct 09, 2013 7:50 am
by Robert J. H.
The most intuitive way would probably be to have a "Repair Tool", i.e. a brush with the 128 sample-width. You simply click where the audio should be repaired.
Re: Suggestion: Repair Limits
Posted: Thu Oct 10, 2013 12:36 am
by Gale Andrews
Robert J. H. wrote:The most intuitive way would probably be to have a "Repair Tool", i.e. a brush with the 128 sample-width. You simply click where the audio should be repaired.
Then that goes back to doing a repair centred on the click point which seems sub-optimal compared to choosing the selection.
It might also be too similar to Draw Tool's smoothing brush (or spray can on Linux).
Gale
Re: Suggestion: Repair Limits
Posted: Thu Oct 10, 2013 1:26 am
by steve
Gale Andrews wrote:It might also be too similar to Draw Tool's smoothing brush (or spray can on Linux).
Perhaps it could be an alternative behaviour for the brush/spray can?
"Alt" for one, "Shift+Alt" for the other?
Re: Suggestion: Repair Limits
Posted: Thu Oct 10, 2013 8:03 am
by Robert J. H.
Gale Andrews wrote:Robert J. H. wrote:The most intuitive way would probably be to have a "Repair Tool", i.e. a brush with the 128 sample-width. You simply click where the audio should be repaired.
Then that goes back to doing a repair centred on the click point which seems sub-optimal compared to choosing the selection.
It might also be too similar to Draw Tool's smoothing brush (or spray can on Linux).
Gale
Why sub-optimal? The movement of the mouse would drag the 128 bit frame around, so you would exactly know what region the repair is applied to.
This makes of course only sense with a proper zoom factor.
However, it is very weird if I propose a feature that isn't accessible...
So, with the current play preview, only a solution with a selected portion will be feasible for me. And most naturally, the 128 bits should be taken from the beginning of the selection. To be honest, I've never ever used the effect because it is so cumbersome.
That's where a scrubbing feature might come in handy.
Re: Suggestion: Repair Limits
Posted: Thu Oct 10, 2013 9:37 am
by waxcylinder
Robert J. H. wrote:Why sub-optimal? The movement of the mouse would drag the 128 bit frame around, so you would exactly know what region the repair is applied to.
Because as discussed earlier in this thread, a skilled user will often carefully choose a smaller number of samples (sometimes much smaller than 128) to effect the repair without affecting audio which does not need to be altered.
Peter
Re: Suggestion: Repair Limits
Posted: Thu Oct 10, 2013 10:04 am
by Robert J. H.
waxcylinder wrote:Robert J. H. wrote:Why sub-optimal? The movement of the mouse would drag the 128 bit frame around, so you would exactly know what region the repair is applied to.
Because as discussed earlier in this thread, a skilled user will often carefully choose a smaller number of samples (sometimes much smaller than 128) to effect the repair without affecting audio which does not need to be altered.
Peter
Sorry, I missed that one.
I rather seldom edit 1 ms samples (instead of 2-3 ms for 128 samples). The tool could be so flexible to adjust the repair selection to the nearest zero crossings before the repair.
Re: Suggestion: Repair Limits
Posted: Thu Oct 10, 2013 10:18 am
by waxcylinder
Robert J. H. wrote:waxcylinder wrote: The tool could be so flexible to adjust the repair selection to the nearest zero crossings before the repair.
That would be a cute bit of finessing.
Peter.