Improving "Clip Fix"

[Gale Andrews]

OK, I'm with you now Provided that your method is followed rigorously it works pretty well and certainly better than ClipFix.

That depends what you are looking for - a simple-minded repair (smoothing) of the current waveform with a given that only damage is selected; or something that is more forgiving in its detection requirements and which can preserve previous dynamics as well as tolerably remove clipping. I still think improving Clip Fix should be on the agenda.

Unless my audio is not clipped enough in the first place or my musical tastes too subtle, I've been disappointed with the audible result of Repair compared to Clip Fix, especially given the much larger effort needed to use Repair.

So I would still like to hear a section of music where Repair beats Clip Fix, while being very interested in an automated Repair Effect

Have you tested "Repair" for the effect of changing the maximum order of the least squares regression (currently hard coded at 50)? I would expect a significant increase in speed if that number is reduced and a slight improvement in quality when increased.

Can you point to what exactly to change?

I just really wish there were an easier way to automate Repair on multiple sections. [...]What clip fix uses for detection is good enough.

OK so is the feature request as you see it to add detection back to Repair (if necessary using the Clip Fix detection) and then Repair uses its current algorithm (or Clip Fix's if that is detected as better in a given case) to work through the detected sections?

And the samples limit then applies to the number of samples in the detected clipped sections and not to the number of samples in the selection made by the user?

I also think before reinventing wheels you should try the two pre-existing efforts by Leland and Danni Coy that used Find Clipping to do the detection then Repair to fix the detected selections.

Danni Coy's effort seemed very promising because unlike Leland's, his had a configurable number of samples and detected clipped samples that had been negatively amplified (see Martyn Shaw's comments about this here ).

I've attached the two zip files (Danni's is not a patch so needs integrating into Audacity).

Also I had some correspondence with someone who had devised what sounds like very high quality click and soft dust tick detection for vinyl records in labVIEW. The detection seems to be based on statistical analysis of what a click "signature" is like.

He knows no C++ but wanted to integrate his detection with an automated version of Audacity's Repair effect. So he offered us his detection method if we could make it work in C++. He says his method is not proprietary so I have attached a summary of what he wrote to me including images.

Perhaps this detection is of more relevance to Audacity's Click Removal than Repair, but is Click Removal's deficiency wholly in detection or also in removal?

I have not stated his name yet but I have told him I have posted here.


Gale

[steve]

I still think improving Clip Fix should be on the agenda.

I agree.

Nyquist, because of its rapid development capacity, will be useful for prototyping algorithms. It is likely to be impractically slow for recursive processing of samples, but I think that the specific limitation highlighted by Quant's example can be significantly improved with little additional processing time.

Unless my audio is not clipped enough in the first place

That is possible.
If only single peaks are clipped (and it is "digital" clipping) then ClipFix works pretty well. It is also a much faster algorithm than "Repair" uses.

I would still like to hear a section of music where Repair beats Clip Fix, while being very interested in an automated Repair Effect

Going through a long enough section to be clearly audible would take a considerable amount of time. I've manually done a long enough section to analyze the difference (about 0.1 seconds) but it's not really enough to clearly hear the difference. Perhaps Quant has a "real life" example that he could post?

2) Have you tested "Repair" for the effect of changing the maximum order of the least squares regression (currently hard coded at 50)? I would expect a significant increase in speed if that number is reduced and a slight improvement in quality when increased. If that is correct then it could be a very useful parameter for what is being proposed.

I was just wondering if anyone had already tried this. If not I'll try it myself and report back.

and then Repair uses its current algorithm (or Clip Fix's if that is detected as better in a given case)

I think that we can improve on ClipFix's repair algorithm. If we are going to this much trouble then we should do so.

And the samples limit then applies to the number of samples in the detected clipped sections and not to the number of samples in the selection made by the user?

Yes, but there must also be enough "good" samples before (or after) the first "bad" samples, otherwise the result will be garbage. The effect should be clever enough to tell the user if the audio is unrepairable after the analysis pass.

(see Martyn Shaw's comments about this here ).

Interesting that Leland wrote it as a dynamically loadable effect. That would ease some of the design constraints (allow it to be a more specialised tool).


(Aside from http://audacity.238276.n2.nabble.com/Ju ... 52451.html...)

Some effects, such as bassboost, also introduce this clipping in their processsimplemono(). These will need to be handled case by case, since the code is case by case.

This issue in "BassBoost" was fixed with the upgrade to "Bass and Treble". There are still a few other effects with this issue so we should probably fix those - it's an easy fix. "Phaser" and "Wahwah" are two examples that come to mind.

Danni Coy's effort seemed very promising because unlike Leland's, his had a configurable number of samples and detected clipped samples that had been negatively amplified (see Martyn Shaw's comments about this here ).

I presume that you mean here? http://audacity.238276.n2.nabble.com/Pa ... 23796.html

Unlike ClipFix, "Repair" can handle "inverted clipping". Special treatment is required for ClipFix's repair to work with inverted samples (this is an enhancement that we can add to ClipFix).

Also I had some correspondence with someone who had devised what sounds like very high quality click and soft dust tick detection for vinyl records in labVIEW

An interesting and promising algorithm. I tried something quite similar to this a long time ago in a Nyquist plug-in, but gave up on it as it was impractically slow (in Nyquist). I would expect this to still be pretty slow in C++, but perhaps not fatally so. However, click detection is a different fish to clipping detection and this algorithm is addressing click detection.

Perhaps the Repair tool, if it is to support automatic detection, should have user options for whether it is repairing clipped audio or clicks, but that raises a question of whether or not typical users know the difference (we often see posts that say "my recording sounds fuzzy").

Incidentally, I think that I can see an improvement to "Analyze > Find Clipping". Currently it looks for samples > 1.0, but clipping can occur < 1.0.

[steve]

Danni Coy's effort seemed very promising

I've only had a brief look and I've not tried it, but this looks like it is exactly what Quant is asking for.

[steve]

This is the kind of audio that people generally want to repair: http://forum.audacityteam.org/viewtopic ... 20#p214720

[Gale Andrews]

I too find Repair produces more pleasing sounding results and have already made some modifications to the source code (for my personal use) that might have some bearing on this topic. I thought I had posted the code here but I can't find it; it does a couple of things: 1) adds a new preference item giving the user control over the maximum number of samples Repair will accept, 2) if the user selects committee samples a dialog opens specifying the maximum, the number selected & the difference (selected minus maximum).

A recent [email protected] correspondent who uses Repair heavily has suggested that it might "lock" the selection when it reaches 128 samples (or whatever the maximum is) rather than keep nagging with a warning each time you select too many samples.

I'm not sure about that. The option to do that would need to be presented somewhere, and I would think there may be temptation to accept the selection when it reaches 128 samples, whether the selection contains only damaged audio or not.

However taking that idea further (and if Repair still leaves detection up to the user, one selection at a time) then I could envisage something more useful, such as a modeless repair tool dialogue, enabled by a Tools Toolbar button (in the same way that you enable Draw Tool).

When the repair tool is enabled and you drag a selection, the dialogue displays the samples in the selection. The OK button carries out the repair and the maximum samples could be set in this dialog too.

When the number of samples in the selection is exceeded, Repair alerts you in some way, stops the drag, and greys the OK button.


Gale

[Gale Andrews]

Danni Coy's effort seemed very promising

I've only had a brief look and I've not tried it, but this looks like it is exactly what Quant is asking for.

I tried building it on Windows, adding to LoadEffects.cpp:

+ #include "RepairClipping.h"
+ em.RegisterEffect(new EffectRepairClipping());

but come up with a linking error after compilation that I have not managed to get around:

4>......srceffectsRepairClipping.cpp(77) : error C2039: 'CopyInputWaveTracks' : is not a member of 'EffectRepairClipping'
4> c:audacity svnsrceffectsRepairClipping.h(27) : see declaration of 'EffectRepairClipping'
4>......srceffectsRepairClipping.cpp(84) : error C2065: 'mOutputWaveTracks' : undeclared identifier
4>......srceffectsRepairClipping.cpp(105) : error C2039: 'ReplaceProcessedWaveTracks' : is not a member of 'EffectRepairClipping'
4> c:audacity svnsrceffectsRepairClipping.h(27) : see declaration of 'EffectRepairClipping'


Gale

[waxcylinder]

A recent [email protected] correspondent who uses Repair heavily has suggested that it might "lock" the selection when it reaches 128 samples (or whatever the maximum is) rather than keep nagging with a warning each time you select too many samples.

I'm not sure about that ...

I'm not sure that's a good idea either.

I have my Selection Format (in the Selection Toolbar) set to: hh:mm:ss + samples and (Selection) End/Length set to "Length" precisely so that I can see when I have 128 or less to operate on with the repair command.

Aside: setting it that means also that it doesn't matter if you accidentally set Snap To on

WC