It’s underneath the divider in the Effect menu along with High Pass, Low Pass etc. If there is nothing under the divider than you have moved or renamed the Audacity Plug-Ins folder. Or are you on Linux and obtained Audacity via your distribution?
Gale
I didn’t see it underneath the divider. I installed v 1.3.5 over the previous beta (in the same Audacity 1.3 directory). When I checked the Plugins folder, I didn’t see the clipfx.ny file, so I downloaded it separately and put it in my Plugins folder. When I re-opened Audacity, it was there in the Effects menu.
Thanks.
MattG
In my recent post where I said Clipfix was now in 1.3.5, I meant to say that it was now in source code (it was actually added two weeks after 1.3.5 release). I think I got that right where I mentioned it elsewhere in this long topic. So sorry for the confusion, but it is not in the 1.3.5 release, but can be obtained either from my site:
http://www.gaclrecords.org.uk/clipfix.zip
or from source code:
http://audacity.cvs.sourceforge.net/audacity/audacity-src/plug-ins/clipfix.ny?revision=1.3&view=markup
and it will be included in the next Beta (1.3.6).
I’ll edit the post where I got it wrong.
Thanks
Gale
Hello Benjamin and other Audacity great developpers.
I have been using clipfix.ny on mac both PPC and Intel in the last two days to rescue important recordings which were badly damaged by clipping (without negative clipping areas)
It did work fine, even for very noisy sounds (percussions) and the audio rendering was perfectly preserved.
This is great great great!
The bad point is the duration of the computing.
On a dual processor G4 it took a hole day to declip 8 tracks of 8 minutes each. During that time, the application was paralyzed and the little colored weel was turning. But at the end everything finished well. Except twice when I tried to work on other sound editors while the calculation was going, I had the grey curtain big macintosh crash.
On a Dual core Intel Macbook, the same treatment takes about one hour. The interface of Audacity is also paralized. Only one processor works.
Good luck and thank you.
Roland Cahen
Electroacoustic music composer and sound designer
//perso.orange.fr/roland.cahen
That seems odd.
On my Pentium III 500MHz 512MB RAM running Xubuntu 8.04 (linux) and Audacity 1.3.5
A single mono 5 minute 38 seconds track 44.1 kHz 16 bit with lots of clipping took only 20 minutes to complete Clip Fix processing.
when i run the plug-in, it is not doing anything except deleting the selection.
i am using audacity-1.3.5-beta (unicode) on ubuntu-8.10.
i have an 80 minute track with quite a bit of clipping throughout. i have amplified by -10 dB and then ran clipfix set at 95%. it will begin and appears to be working, the progress bar moves steadily until about 50% completion. then, the progress stops and audacity goes black & white for about 1 minute. after that, the entire track is gone!
i have tried selecting smaller selections and the same thing is happening (but a little quicker)
if i select a very small portion (tenths of seconds or less), then the plug-in appears to work. however this is way too much work and would take days. plus, after amplifying by -10 dB, i’m not sure where the clipping occurred, as the red indicators have disappeared, so i don’t know what to select for clipfix.
The SBBOD (Spinning Beach Ball Of Death) happens when OS-X thinks it’s taking too long to access the hard drive–or other storage medium. That and Sudden Computer Insanity happen when you run out of hard drive. No production machine should be over 90% full, and that’s the worst case condition. Many people start to worry when their machine approaches 80%. People who start productions with hours of material need to know that Effects generate many gigs of storage requirements, and then there’s the UNDO functions and the capture buffers…
Do you run Mac Janitor or run sudo periodic? OS-X housekeeping and logging functions can clog a machine to the point that it can’t do production any more. If you do not leave your machine awake at 4 am, then you must run the commands manually–or get Mac Janitor to do it.
Koz
here is a picture of the audio i am working with,
http://img89.imageshack.us/img89/1102/clippingrd8.png
any constructive suggestions?
You mean apart from recording it again I presume.
I seem to remember reading that Clipfix can be rather memory hungry - how much available RAM do you have on your computer?
yes 
I seem to remember reading that Clipfix can be rather memory hungry - how much available RAM do you have on your computer?
enough? but, i have tried running clipfix on smaller samples, like 3 minutes, 1 minute, 30 seconds… that should use less RAM, right? still same problem though.
$ free
total used free shared buffers cached
Mem: 4055648 3896472 159176 0 180432 2902380
-/+ buffers/cache: 813660 3241988
Swap: 4194296 297664 3896632
I am also using audacity-1.3.5-beta (unicode) on ubuntu-8.10.
Apart from the addition of a few Nyquist and LADSPA plug-ins, I have a standard installation of Audacity 1.3.5 installed with Synaptic.
My computer is a 500MHz Pentium III with 512 MB of RAM.
I have just tested the ClipFix plug-in (the ZIP file downloaded from Gale’s link) on 130 second recording at 44100Hz 16 bit mono. Processing was rather slow (took about 10 minutes) but it completed successfully and repaired the clipped audio.
So what have I done different to you?
i have found some sort of solution which satisfies me, but it took me about 1 hour to complete on that 80 minute track. also, audacity crashed several times during this process. i would of course like clipfix to work with one pass, which would only take me a few seconds to run, and the computer a few minutes. so here’s what i did, would be nice to have this automated perhaps…
1.) ran “find clipping”
now i have a separate track that shows where the clipping is and do not need to rely on the red lines.
2.) amplified by -10 dB
3.) zoomed into each area marked by the clipping track
4.) selected a few tenths or hundredths of seconds around where the clipping occurred
5.) ran clipfix at 95% on the selection
6.) zoomed out and moved on to next clipped area, repeated until all clipped areas had been fixed
maybe because it’s mono, and mine is 32-bit float stereo?
i have amd64 so maybe that is different?
also, i am using the plugin from,
OK, I’ve tried it on a short 32 bit (float) stereo file and it still works.
Perhaps you should try replacing your version of ClipFix with the one in Gale’s link.
[Edit] I’ve had a quick look and I’ve not spotted the differences yet, but the two versions are not identical.
can you provide the link again, just to be clear? thx
My copy of ClipFix has now been updated to be the same as in source code, but the only difference between that and what was there before is the ;categories line which means that 1.3.6 sorts it under Effect > Utility > Noise Removal.
One of our contributors who works on Nyquist plug-ins has come back “on stream” again recently, I’ll ask him if there is some way to improve performance. Reducing “largenumber” (the maximum number of samples it works with) would be, but it doesn’t then carry on after it’s dealt with that number, but stops and truncates the audio to that length.
Gale
thanks. so am i correct in understanding that the truncation of the whole selection is normal, for now? but then i do not understand how stevethefiddle is able to successfully execute the plugin on a long sample of 130 seconds, when i have tried using it on as little as 1 second and experience deletion or truncation.
is it possible to modify/update this plugin so it can be successfully executed in one pass on a huge selection, like 80 minutes, like the audio screenshot i posted earlier? or is that just a pipe dream?
I have attached the version of ClipFix that I am using. Remove or rename your existing clipfix.ny file, then unzip this file into your Audacity Plugins folder then restart Audacity.
There is no guarantee that this is the problem - in fact I suspect that it isn’t the problem, but it’s worth trying as it will at least rule out one possibility.
The way that clipfix.ny is written, it reads the audio into memory in order to be able to do certain operations on it, such as finding peak levels. When it does this, it requires about 4 bytes per sample. The program uses several functions which require that the sample is loaded into RAM, so removing the limitation is more than a small change in the code.
The version that I am using limits the number of samples that can be processed to “largenumber” - I don’t remember off the top of my head how many samples that is - perhaps a million. I think that there may have been an earlier version that limited the number of samples to “NY:ALL”, which is a billion samples and would require about 4GB of available RAM.
Reading an 80 minute file into RAM would require getting on for a Gig of RAM, so it would be possible, but would crash on computers that had insufficient RAM.
clipfix.ny.zip (2.06 KB)
This is the same as the one on my site and in source code. The “largenumber” here is 100 million samples, so at 44100 Hz sample rate it will truncate audio longer than (100000000/44100) / 60 =37.792895 minutes.
Gale
Gale was kind enough to notify the mailing list that this thread has been revived. I’m sorry for not getting back at you earlier, my studies have been quite demanding. (It’s my excuse for the next 5 years.) But I’m glad that you guys are working on it, your work is really appreciated.
I see that the topic has shifted over to the performance of the clipfix plugin. Is there any chance you will look into the inverse polarity clipping (see OP) as well? I actually gave up fixing my messed up recording and I took down the sample Wave (page 2) in a cleanup of my webspace, but if there’s any interest I’d be glad to put it back. The last post on page 1 by stevethefiddle outlines (in pseudocode) how the polarity fixer could be implemented in clipfix.ny.
As for the perfomance: it doesn’t really bother me because personally I just run Clipfix on small selections in a recording instead of the entire wavefile. Am I doing it wrong? My thought is that if a recording is clipping all over it’s usually so messed up there’s no need trying to salvage it anyway.
Wishing you a merry Christmas,
Arnoud
