Not at all, that’s exactly how I use it, and it is how the ClipFix effect recommends that you should use it.
The only proviso is that ClipFix requires that there is sufficient headroom for the clipped audio to be restored, so the entire track will usually require amplifying by a negative amount to allow headroom for the clipped sections.
Not always, but nearly always true.
No, it’s always true. By the time people realize they need help, it’s too late.
I know exactly one producer that used noise reduction to gently get rid of a faint air conditioner whine in his interview. It turned an already good show into an excellent show. That’s it. One. Everybody else wants software that can turn complete acoustical garbage into a show. Hasn’t happened yet.
The video people have two jokes. One is the Professional Audio filter where you put in whatever you have and it creates a Hollywood Soundstage track for you and the other is the “Reshoot Filter.”
Koz
Hi again Arnie,
The polarity inversion that is shown in your example are pretty extreme and can not be fixed with ClipFix … or at least they couldn’t be corrected until now 
I’ve made a modification to the ClipFix plug-in that may be able to solve the problem.
Basically the modification uses the algorithm that I suggested way back at the beginning of this topic that will correct inverted samples before the usual ClipFix algorithm is applied.
I have called the modified plug-in “ESP-ClipFix” so as to distinguish it from the original (you can have both my modified code, and the original version installed at the same time - My modified version will be listed as “ESP Clip Fix”.
Here is a sine test sample before running ESP Clip Fix:
And here is the sample after running ESP-ClipFix:
Here is a more realistic sample recording:
Also, it comes with no guarantee whatsoever. If people find it useful then I may add stereo support when I have time.
ESP-Clip-Fix is available here: http://forum.audacityteam.org/download/file.php?id=5438
Figuring out where the distortion is is critical. I wonder what that tool would do to a good fuzz guitar track.
Cello and timpani? Wouldn’t it be funny if it took the cannons out of the 1812?
Reading through all that is making my head bleed, but what provision is there for the all too common problem of clipping a microphone amplifier way before the output signal clips. “My track never gets any bigger than 0.5 on the blue waves…”
Koz
Thanks, Steve. Do you think you might write this for stereo anyway? Rather than call this ESP Clip Fix and have it as a “competing” version to Clip Fix, I’d like to simply upgrade the present Clip Fix with this modification and add it to source code. That’s if you agree of course.
Gale
There is an apocryphal story about a BBC recording engineer who made a field recording in Africa of a language where the clicking noises made by the speaker were a fundamental part of the language and conveyed the meaning. In the editing process some smart editor then went and cleverly removed all the clicks -effectively destroying the content and value of the recording …
WC
The standard Clip Fix uses a relatively simple algorithm to determine clipped audio. It looks for flat peaks and the necessary “flatness” of the peak for correction to be applied is determined by the slider control (“Threshold of Clipping %”).
Because it is working from the maximum sample present value rather than an absolute amplitude, audio that has the peaks clipped flat at say -18dB will still be de-clipped correctly. In fact, when using the effect, you will generally need to reduce the overall amplitude to allow space for the peaks to be reconstructed, so the audio that is being corrected should always be substantially lower than 0dB. The information on the plug-in window recommends allowing 10dB of headroom.
The way that “flatness of the peaks” is determined (as far as I can tell) is by the plug-in looking for the maximum sample value, then comparing individual samples with that maximum value. If they lie within the range that has been set (the default is 95% of the maximum value) then the sample is included in the area for reconstruction.
Obviously this does allow some samples to be incorrectly selected for correction as all samples that are above 95% of the maximum are assumed to be clipped. In practice this is not a problem because of the simple but clever way that Clip Fix corrects clipped audio. Clip Fix will “mark” the region that has “clipped samples” on a wave peak, and will then look at the slope on either side of that region. The slope will then be extrapolated (using cubic spline interpolation) across the marked region. In the case of a few samples that have NOT been clipped having values over 95% of the maximum, they will in all probability already lie extremely close to the “correct” waveform as determined by Clip Fix, so the amount of correction that is applied is insignificant.
Using cubic spline interpolation is also nice in that the reconstructed audio is unobtrusive. It does not carry the “tonal character” of the surrounding audio, but will generally have the effect of restoring greatly clipped peaks more than slightly clipped peaks (which is what is required). Any samples below the (95%) threshold are unchanged by the plug-in, so unnecessary distortion is kept to a minimum and the effect produces subjectively pleasant results.
In such cases as “Fuzz Guitar”, then although the audio may sound similar to clipped audio, it will often look very different to Clip Fix. Harmonics and phase shifts present will often present a spiky waveform rather than a flat topped waveform, and in this case the audio will not be considered “clipped”. However in the case of a simple “diode clipping” fuzz that has been DI’d (plugged directly into the recorder), then waveform may match the “flat topped” characteristics that Clip Fix is looking for, and the audio would be “corrected”, making the sound “cleaner”.
The main limitations of Clip Fix are that it only works on audio that has peaks that have been clipped (probably why it is called “Clip Fix”). 
Other forms of distortion can not be repaired by this effect.
In the case of a live recording of a band, you may have a perfect example of clipping on the lead vocal microphone, but by the time the sound has travelled across the room to your recording microphone and been mixed with the sound of the other instruments and the audience, the waveform that you have recorded will look nothing like the flat topped clipping that Clip Fix can work on and the audio would be hardly affected at all by Clip Fix. The only way that Clip Fix could work in this scenario is if you had a direct “off the desk” separate track with the lead vocal microphone.
Another example of when Clip Fix will not work is when there is “polarity inversion” of the clipped audio - (the issue that started this thread). As I said way back then, audio equipment should be better behaved and polarity inversion should not happen… but sometimes it does. This is the issue that my modification addresses.
For anyone interested, the algorithm that I have used is describe near the begining of this thread.
As the audio is being processed, ESP-Clip-Fix will look for inverted clips and if found will convert them to flat clipping. The audio is then processed by Clip-Fix in the normal way.
How could I refuse
I have used the name “ESP Clip Fix” simply to distinguish my modified version from the original so that I can have both versions installed simultaneously. (I use the “ESP” prefix for all of my plug-ins). If it was included in the “official release” then there would be no need for the distinction, so calling it “Clip Fix” would be fine.
I doubt that I will have time before the new year, but it should not take long to do.
My code may not be the optimum due to my lack of knowledge in using Nyquist, but I’m sure that there are some developers that could cast an eye over it and tidy it up if necessary. Also, I am unable to test the modification on long sections of audio as my computer is too low specification, so it would require testing by others.
As the issue of inverted polarity is not very common, I was thinking of adding a check box for enabling (polarity correction) such that my code was normally bypassed. What do you think?
There is one problem I’ve noticed that glances off the ideas advanced. In almost all of the cases of obvious clipping, when the waveforms are posted, they look nothing like classic waveform flat-topping (and bottoming). We know that if you put sharp waveforms through a restricted bandwidth environment, all sorts of nasty things happen as the upper frequencies are suppressed. Audio waveforms always get taller and square waves turn into trash heaps. I submit that clipping at 48000 would be easier to fix than the same show at 44100.
<<<If it was included in the “official release” then there would be no need for the distinction, so calling it “Clip Fix” would be fine.>>>
Quite a number of “normal” programmers have version numbers and nobody ever uses the whole name. I’d be applying CF2.2.
Koz
Oh, one more. The odd numbers are experimental. CF2.3 has the test code for polarity inversion. It’s beta.
Koz
That’s true, and in most cases the distortion is so bad that the only solution is to delete it and start again. The exception to this is where the recording level has been set just a little too high and a few peaks have suffered digital clipping. This is the kind of distortion that Clip Fix is designed for, and in these cases it works very well.
In the case of polarity inversion, this is a particularly nasty sounding distortion and is very obvious and intrusive. In this case the original Clip Fix fails completely, but the modification turns the inverted audio into “ideal” flat topped clipping and allows Clip Fix to work and the improvement is considerable.
The current version does not carry a version number, so what number would the next version be?
Well at the moment the polarity reversal code is alpha or even pre-alpha 
CVS (that is “our” CVS) just starts from 1.1 and carries on with 1.2, 1.3 etc.
Steve, does this checking for/correction of inverted polarity double the processing time or is it less intensive than the normal fixing that goes on afterwards? I’m not keen on having a checkbox to turn inverted polarity processing off, because of the user difficulties comprehending it/ trying to figure from the waveform if they have inverted clipping. So, IMO it’s better under the hood unless expensive to run.
Thanks
Gale
It is pretty slow at the moment as it simply processes the entire selection, sample by sample, before the Clip Fix code runs. I wrote the modification and then just dropped it into the Clip Fix code so that it would pre-process the data, which is a pretty inefficient way to do it.
There are a couple of methods that I’ve thought of for making it considerably more efficient;
One is to (quickly) test the audio to see if polarity reversal is needed and to only run that part of the code if required (the program decides if the “check box” should be ticked). This bit could run very fast.
The other possibility would be to integrate the polarity reversal more closely into the existing code so that it ran within the same “Do” loops that Clip Fix uses. This should reduce the overhead considerably, but I will need to study the existing code a bit more work out how to do that.
Both of these methods could be used together so that if polarity reversal is not present there would be virtually no increase in processing time, and if present there would just be a small increase in processing time.
The other issues that I have are:
Occasionally it locks up (processing takes forever). I’m not sure at the moment if this is because of a bug in my code or a bug in the existing code. I don’t think that it is caused by the new code, but the bug needs fixing anyway.
The new code is only written for mono - that’s easy to fix.
If applied to sudden sounds such as drum hit, the first few samples can be falsely detected and changed. This is due to my sloppy coding and is another easy fix.
Once I’ve fixed the last two issues, the new code will be working correctly. Would you be able to put me in touch with the person that you are referring to? Improving the performance of the effect as a whole and finding the “lock up bug” will require unravelling the existing code and improving it, and I’m having some trouble with that.
Steve
You could test for spectrum density.
As you point out, clipping inversion sounds really terrible–and should result in a very dense spectrum as all those intense, harsh overtones are created. If you apply the inversion flipper and the spectrum quiets down, then you done good. I can’t imagine a condition where you would create damage and have a quieter spectrum (although I’m sure there are some). You could use that as a Quality Control. Keep correcting until the spectrum density is minimised. Once you have a feedback like that, you can eliminate a lot of incomprehensible controls and sliders–or post the sliders anyway plus [x] Auto.
You personally wouldn’t have to do a lot of work, either. Analyze > Spectrum and The Area Under The Curve thing applied once and not even that accurately, should do it.
Given most people’s shows are unrecoverable anyway, I suspect you could get away with “wasting” time and resources if you produced a pleasant product.
Is this the longest thread?
Koz
Steve, once you’ve got the new code working in stereo and correctly detecting the first few samples, I’ll be happy to add the new version to source code. Audacity 1.3.7 will be out very soon, so you might even get the new code into that and get some feedback about it.
The processing improvement for the new code you suggest, so that there will be relatively little extra processing time even if there is inverted polarity clipping, would be great, and would definitely avoid the need to have an on/off switch for polarity checking in the interface.
The Nyquist person I mentioned doesn’t in fact find it easy to understand the Clipfix code. However there is some interest in this topic now in the corresponding thread in the Nyquist Forum:
http://n2.nabble.com/Clipping-with-inversed-polarity---idea-for-a-fix-td238860.html
Gary Nelson suggested there an alternative binary number correction for inverted polarity, but the major issue is memory use in Clipfix. Roger Dannenberg commented in the thread:
Since the clipfix code begins by making copy of the input sound, I can understand why the code uses a lot of memory. The algorithm used by the code is undocumented and the indentation does not match the program structure, so I didn’t get very far trying to quickly grasp what’s really going on there. I’d be happy to comment on approaches if anyone plans to do some rewriting.
Note there is a general problem that Nyquist running in Audacity uses far more memory than it does running as a JavaIDE, because in Audacity it cannot work directly on the source files. So running any Nyquist plug-in on a CD-length file in Audacity is going to put a strain on RAM, and even the best code design will only minimise this basic problem.
Unfortunately I have not been able to contact the original author of Clipfix (Benjamin Schwartz) with the address I have for him, but I’d suggest if you subscribe to the Audacity Nyquist Forum:
http://lists.sourceforge.net/lists/listinfo/audacity-nyquist
and post your code suggestions for integrating negative polarity fixing into the main code, you may (at least) get some feedback if you are doing it the best way.
Thanks
Gale
I’ve got it working fine as a stand-alone effect (on relatively short audio clips), and have been looking at integrating it better with Clip Fix.
I’ve spent a fair bit of time unravelling the original code and commenting it more fully. There’s some pretty weird code in there, but I’ve just about got it sussed now. I think I’ve also found a pretty big memory hog within the code that can be eliminated.
There’s a few bits that I’d like to change, such as using “max” as a variable (confusing since “max” is also a nyquist function).
Yes, I’ve just run into this one.
edgar commented on this back in January http://n2.nabble.com/Memory-bug-with-Nyquist-in-Audacity-td257313.html
If in Audacity I write the same thing as:
(let ((peak-value (peak s ny:all)))
(mult (/ 1.0 peak-value) s))Audacity again starts to allocate more and more memory until it finally
crashes.I’m sorry but I have no idea what this could be called other than a
severe bug with Nyquist in Audacity.
- edgar
So it seems there is no way round this issue at the moment - there’s just no wayto recover that memory.
I’m already subscribed to the Audacity Nyquist list, so I’ll post something there when I get home (beginning of January).
it still deletes the audio, or rather, it clears it away, because the track is still the same length, just all the audio data is gone. i have tried using a sample much smaller than 37 minutes, but larger than a few hundredths of seconds, and it still clears whatever has been selected.
i tried changing largenumber to 10 billion and, instead of the progress bar stopping about half way, the progress bar completed to 100%. however, after that, audacity turned gray as if it was not responding, and the mouse cursor turned into the busy signal, similar to what i have been experiencing. after waiting a couple of minutes, all 80 minutes except for the first ~2.3 seconds had been cleared away.
i tried your version of clipfix.ny and experienced the same thing i have been experiencing from the start. namely, the progress stops at about 50%, screen turns gray for a couple minutes, then all the audio is cleared away (except for the first ~2.3 seconds).
scar, I’ve kind of lost track with this thread, so can we recap?
You are wanting to run ClipFix over large files, using a high spec computer?
Having now spent some time going through the code, I don’t think that it is going to happen. “Bit-wise” processing in Nyquist will always be slow and memory hungry. In addition there are certain technical issues that result from the implementation of Nyquist in Audacity that prevent memory being freed from certain processes. This is one of the root problems with ClipFix. Each time it runs, it not only utilises large amounts of RAM, but that memory utilisation persists for as long as Audacity is open, so if you run ClipFix more than once, large amounts of memory are used each time, and memory usage accumulates until you finally run out of memory and Audacity crashes.
Even so, you should be able to process more than a few seconds of audio. On my Pentium 500 with 512 MB Ram, I can easily process a million samples (a bit over 22 seconds at 44.1) though it is quite slow.
Note that the “process bar” in the effect is hopelessly inaccurate. On my machine, processing a million samples indicates a processing time of around 35 seconds, but after the “countdown”, it actually takes almost another 5 minutes. I tried once running ClipFix over a 20 minute track - the countdown showed something like 20 minutes for processing. Some hours later, after I had cooked and eaten my evening meal and washed the pots, and listened to the radio for a while, it had completed successfully. During that period, Audacity was completely unresponsive - moving another window over the Audacity window would cause a blanking out of that window. Audacity appeared to be quite dead, until it eventually completed processing. CPU usage had been at a fairly constant 48%, but memory usage had gone up alarmingly, and remained high until I closed Audacity.
This plug-in eats memory - you may need to check how much real memory (not swap memory, it needs to be genuine RAM) you have available.
I am currently working on a rewrite of ClipFix and looking at ways of reducing memory usage, but even with the most optimised code, memory usage will still be pretty high.
Steve,
Would it be possible for me to get copy of your working code…whether it’s complete or not? I’m in the process of upgrading to the latest version of Nyquist and have have tremendous memory and cpu savings. The original clip fix doesn’t benefit though.
Leland
I’m not contributing anything. I just want to see if I can get the post to go to seven chapters.
Koz
Up to my eyes at work at the moment - will provide a copy asap.
Probably do more than that
