I just wanted to clean up some old audio tapes I have digitized and thought that I might try noise-repellent for this task. Adaptive mode was working quite well. But I after tweaking a bit more, and wanting to do some A/B checks I noticed that the bypass button doesn’t work. Sure enough I wasn’t the first to notice this, as I found Bypass button not working in Ardour · Issue #113 · lucianodato/noise-repellent · GitHub. Yet, the issue is labeled “Work in Progress” since more than 2 years without any further reply from @lucianodato . Since Luciano was also posting in this forum a few times I wanted to check if he (or someone else from the community knows if he) is still maintaining noise-repellent?
Just a quick note for anyone else noticing this: After a few more tests and a note from @DHealey on the Github issue it turns out that v0.1.5 of the plugin does not have this issue. So I am sticking with it for now.
1 Like
As a FLOSS developer with way too many responsibilities accumulated over my career, I can sympathize with any developer who gets overwhelmed or burnt out with supporting any give project:
- At first, I’ve put off reviewing PRs or tackling even what seemed easy issues because I had too much on my plate;
- Later, feeling guilty about my tardiness further damaged my enthusiasm for (or even willingness to engage with) the project;
- Over a longer period, I’ve managed to numb myself to the sense of responsibility, and corresponding guilt, to the point that I no longer check on the state of the project regularly.
Things that have helped break me out of the vicious cycle:
-
A new, tightly-focused PR which fixes a known issue in an easy-to-read way; for such a PR to successfully break through, it needs to have zero extraneous changes: no whitespace cleanups, no “style-only” tweaks, nothing: only the fix, and if possible, a new testcase which reproduces the bug being fixed (without the main patch), but passes with the patch applied. Note that the proposed fix doesn’t have to be the accepted / “right” change, but it needs to be plausible, minimal, and comprehensible.
-
A new volunteer offereing the time to help prioritize open issues, review PRs, etc. N.b. that this kind of help can also be an attack vector against the project: see the
opensshmess earlier this spring.
3 Likes
Don’t feel guilty. Unless you’re being paid by someone you don’t owe them anything. Your life is yours to do with what you like.
I have a project that gets a lot of feature requests, I tag them appropriately and comment on them with my thoughts but it is unlikely that I’ll work on them as they have no interest to me personally - in fact as far as I’m concerned the project is feature complete. I review and merge PRs from others and put out new binaries occasionally but it’s absolutely on my schedule and I feel no guilt about letting it take a little while.
1 Like
FYI, Luciano has updated noise-repellent’s README to state that it’s not actively maintained right now.
2 Likes
Oh, I get that for sure, at the “top” of my mind. But the guilt-induced aversion to do anything at all about those projects (or even think about them) still lurks down in the shadows.
I dug a little bit deeper today into the noise-repellent source code and the LV2 spec and I think I found the issue why bypass isn’t working.
Noise-repellent 0.2.x applies a short cross-fade to full-dry (or full-wet, depending on the enabled state) signal: noise-repellent/src/signal_crossfade.c at 5468d9f95ee5745171dec2892404c045b05095bd · lucianodato/noise-repellent · GitHub
But this happens after the spectral processing has already been applied to the output buffer: noise-repellent/plugins/nrepellent.c at 5468d9f95ee5745171dec2892404c045b05095bd · lucianodato/noise-repellent · GitHub
GitHub user Efenstor mentioned that input buffer and output buffer were the same during their tests for their PR which obviously makes the crossfade code a no-op. I have verified this myself today, both input and output pointers are always pointing to the same memory address, and according to the LV2 spec the host is free to do so:
Plugin writers should be aware that the host may elect to use the same buffer for more than one port and even use the same buffer for both input and output (see lv2:inPlaceBroken in lv2.ttl).
The note at the end of the quote already hints at a spec-compliant solution for noise-repellent. It could declare lv2:inPlaceBroken to indicate that it needs different buffers for input and output data. IIUC this would be a fairly easy change to noise-repellent, requiring no further code changes. I wanted to try this tomorrow, but I have just found this LV2 host compatibility chart which indicates that Ardour does not support inPlaceBroken.
That chart was last updated last year though, so maybe lv2:inPlaceBroken is supported in Ardour now? Maybe one of the devs can comment on this: @x42 @paul ?
If it’s indeed unsupported I might look into restructuring noise-repellent’s soft-bypass logic instead.
Ardour continues to require in-place processing (as have other plugin APIs in the past and present).
Fair enough, thanks for the quick info, Paul!
I find that the 0.2.x version of noise repellent produces worse results than 0.1.5 - which is why I didn’t bother trying to fix the bypass issue myself - are you finding otherwise?
I simply haven’t enough experience with 0.2.x yet, because the bypass issue was making it completely unusable for me. I am in the process of pushing my fix for that issue, then I might be able to do further testing/comparing 0.1.5 and 0.2.x.
Out of curiousity, what else do you find inferior noise-reduction-wise comparing 0.2.x to 0.1.5? I saw your other issue regarding latency on Github, but this is more an (annoying, true) alignment issue, not necessarily an issue regarding sound quality?
A fix for the bypass issue is available here: Fix bypass for hosts providing in-place buffers by jmaibaum · Pull Request #122 · lucianodato/noise-repellent · GitHub
I can’t remember exactly now since I haven’t used it for ages. The latency problem is massive for me though because I’m working with multi-channel audio and applying noise removal to individual channels moves them all out of alignment.
Oh, well yeah, that’s a nasty issue then. I read the issue report as if it was only affecting exported audio, which doesn’t bother me that much. Since I used noise repellent only to clean up single track stereo recordings I did not notice this.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.