Suggestion: Repair Limits

[waxcylinder]

... 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

[Edgar]

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.

[Gale Andrews]

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

[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.

[Gale Andrews]

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

[steve]

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?

[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.

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.

[waxcylinder]

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

[Robert J. H.]

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.

[waxcylinder]

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.