A historical note:
The original Repair effect included click detection. I assume that the detection was problematic in some way, so it was later removed. Perhaps it wasn’t as good as your detection algorithm. What I’m thinking is that if the user options can be made simple enough, then your detector could perhaps be implemented in C++ as an enhancement to the Repair effect (as well as a Nyquist implementation that specialises in repairing mouth smacks). What do you think?
I can test on Linux for you.
In most cases, if the code works on Windows and Linux then it is likely to work on Mac OS X (the exception being GUI elements which are quite often different on Mac), but once it has been submitted as an enhancement it will be tested on all platforms before being marked “patch_ready”.
Just so that you are forewarned, the journey from a working patch to the patch being committed into the main source code can be frustratingly slow.
All patches should be made against svn head, so if you’ve not done so yet the first thing to do is to build Audacity from the source code.
There are instructions for building on Windows here: http://wiki.audacityteam.org/wiki/Developing_On_Windows
and a brief “developers guide” here: http://wiki.audacityteam.org/wiki/Developer_Guide
(The one rule of coding standards that everyone is required to follow is “don’t use tabs at all, and always use three spaces for indentation”)
If you run into problems building (the instructions are not great), then post on the “Compiling” forum board and I expect that Edgar will offer assistance.
For published Nyquist plug-ins (on the wiki or shipped with Audacity) we prefer standard indentation to be 2 spaces. The problem with tabs is that they display differently according to the editor that the file is opened on and we like to make it easy for anyone to open and read the code. Some of the old plug-ins on the wiki have horrible formatting, but we’re trying to improve and become more consistent with that.
BTW - I just found this thread a few minutes ago, after posting a new thread on this subject (which I believe was your original…)
While I’d love the code to be hyper-efficient, I’ll trade many cups of coffee/tea/other (time off) if it works well. Slower and accurate is huge if this is right. Doing this manually is hours of work, so if a 30 minute voice file can be processed in 5 minutes that would be amazing! I’ll report back with progress. IF you ever need testing or test materials, please send me a PM (or post here, your choice) and I’ll either test for you, or send you anything that is helpful.
I have hours of test material, I’ll report back how it goes.
At the defaults it doesn’t remove some of the subtle clicks that I need cleaned, but now I’m going to tweak.
Note that it does reduce some of the clicks circled in the screenshot below, but we need those clicks to be even further reduced because during the “silence” they are still noticeable if you are listening at moderate to loud volumes. I’m hoping with different settings they can be reduced to below the noise floor and for practical purposes be silent. In the case where they are “surrounded” by the noise floor (silence), they could be cut out and nobody would care. We delete them manually at this time, rather than replace with room tone (aka “silence”).
I made a sample file (under 5 seconds) that shows the exact issue I’m trying to eliminate.
I uploaded it in another thread, but since this is the thread dedicated to your tool, I’m uploading again. (Mods: If this is inappropriate, please let me know and I’ll delete in one of the two places! I’m new to the board and don’t mean to violate any specific policies!)
Now I’m back to testing, looking for what I need to change from the defaults.
Hats off to you! This tool will be loved by all the audiobook processors out there (growing by the day.)
I can’t claim yet to have used this for production. Frankly it’s such a diverting programming challenge of itself, it has stalled my production! (Luckily neither activity is my livelihood.) But I think it has great promise as a labor saver.
Yet the question is how to tweak the settings and understand the tradeoffs. For instance I thought that more (and narrower) frequency “bands” might make for superior fixes at the cost of more compute time. But perhaps that isn’t quite so.
There are other tradeoffs to discuss too. But I hope to find good enough default settings that more casual users don’t need to think too much about them.
Mostly the defaults. I have tried setting the first parameter (peak to background) at 3 rather than 2 with good results.
I have experimented with the others but not enough to really understand all the interactions among them.
That said, I’m impressed what what it’s doing, and it does improve the quality of the sound. (I’m a former musician, with really great monitors, so I tend to hear more details than many.)
It is important of course not to overcorrect dsirable sounds and make mud. Earlier efforts dulled stop consonants too much but I found a simple fix for that.
since I was pointed to this thread by a forum moderator (who then ducked behind a couch) I hope it isn’t considering necroing because I’m wondering if this project stalled, was finished or abandoned?
I have been making improvements and I was contemplating posting a new improved version. And as a bonus, a de-esser that was a by-product of this development. Your expression of interest may spur me to present what I have in a day or two.
Have you tried the version above with any success?
I just tried it for the first time and it did nothing which is why I came back here to see what settings I ought to be using.
Once I’ve figured that out I shall try again and let you know.
On a side note, I didn’t find that my humidifier did anything to resolve the issue (though whoever suggested it on a search I did swore it eliminated them for him) so I’m back on the breathing, green apples and warm water.
so far I’ve not been able to work out the settings and the order in which I’m to use the tool’s options (I’m very new to the business of audio).
I’ve added a “Click test” to the OneDrive folder I have in that other thread in case you’re interested. They mainly seem to be in the gaps so, of course, I can manually remove them.
The first control is a drop down. Choose Apply to really fix it. Choose Isolate to hear only what gets subtracted. The other settings only make labels where fixes will be with debug information.
One way to experiment with settings is duplicate the track and use isolate in one. If you play both, you will hear the fix because of destructive interference. Or you can play just the isolated fixes solo to be sure not too much is changed. Or you can play the original solo to compare.