obsproject
obs-filters: add denoiser strengh parameter to RNNoise
obs-filters: add denoiser strength parameter to RNNoise
In the noise reduction filter, show a denoising strength slider when using the RNNoise algorithm. It is implemented as a drymix slider as RNNoise itself dosen't provide a parameter for its denoising strength.
Description
This patch adds code to show a noise reduction strength slider when RNNoise is selected and uses its value in mixing the original and denoised signals to produce an output that integrates the desired level of background noise.
Motivation and Context
When the RNNoise algorithm is selected, the slider for the noise reduction strength is hidden because the RNNoise library has no such parameter. But it seems there are situations where RNNoise makes too good a job and needs to be moderated.
How Has This Been Tested?
This is a simple modification that I tested locally on my computer, running Debian Unstable, here is a demo: https://streamable.com/4696fq
Types of changes
- New feature (non-breaking change which adds functionality) -->
Checklist:
- [x] My code has been run through clang-format.
- [x] I have read the contributing document.
- [x] My code is not on the master branch.
- [x] The code has been tested.
- [x] All commit messages are properly formatted and commits squashed where appropriate.
- [x] I have included updates to all appropriate documentation.
Small nitpick: mixing the fully denoised (wet) audio with the unprocessed (dry) audio shouldn't be called "denoising strength" (as that is a misleading name), but "dry mix" instead, which is what it does. Like you said, the RNNoise library has no option to control the denoising strength.
This also means the slider needs to work backwards; 0dB meaning fully dry.
@mufunyo In english the option in the interface is called “Suppression Level”, I guess it’s vague enough and not a technical term enough to not cover both the “denoising strength” of the Speex denoiser and the dry mix system used for RNNoise.
As for the slider and the unit used (dB), in the case of RNNoise, a selection of 0dB effectively yields a fully dry signal, whereas -60dB yields a virtually fully wet signal. I guess -60dB is to be interpreted as the amount of gain applied to the noise in the signal, as the “Suppress Level” label would hint.
If I understand correctly, the mixing is done such that "full denoising" still mixes in an infinitesimal amount of dry audio whereas "no denoising" doesn't mix in any denoising? That makes no sense. Can't you reverse that?
The code does include dry signal with a gain of -60dB applied in the mix yes. It does what the setting says. There is no “full denoising” option, only a “Suppression level” of -60dB.
If you think it’s best I could add code to test the suppression level and if it is at -60dB the effect would only output the wet (denoised) signal.
(Just to be sure, I’m only talking about the RNNoise algorithm, the Speex algorithm related code has not been changed).
I don't know how I feel about this option. It's not an option that actually affects the library, it's just a dry/wet mix. It's not actually as effective because if it's not 100% wet, it basically will always allow some of the audio, so it feels like a less effective method of solving the actual problem.
The option name should reflect that fact, and the value should be in percentage, with the default value at 100% (wet). Additionally, at 100% wet, it should not be doing any processing what-so-ever. I'm probably not going to merge this for the current patch. We're going to see how it goes with how it currently is (100% wet).
To me it's very simple: you're trying to combine two features that are unrelated to each other in their implementation and running into differences, trying to patch those differences away with a solution that nobody is happy with. Don't be afraid to add a new string, Crowdin will translate it.
Speex denoiser should retain its current setting: suppression level. RNNoise should have its own separate setting called dry mix, which you can either implement as a dB scale, with 0 dB being fully dry, and -∞ dB being fully wet (no mixing performed), or as a 0% to 100% percentage scale.
It would be unusual to me to have dB-based dry/wet mix. I'd say percentage-based for sure, feels more in line with how DAWs would normally handle it and makes immediate sense to pretty much every single user (dry/wet terms aside).
Id just like to mention how utterly useless audio engineering terms are to the average user. https://i.imgur.com/PLxjSES.jpg
And even within this PR, there is a claim we should have the default "100% wet". The default demoed is "dry mix: 0%". And even within this PR we are clarifying what we mean by wet/dry because they are so utterly arbitrary. Maybe this is what Jim meant by "100% wet" but to me the slider should be at 100% to represent that it is on and suppressing noise. Having the slider at 100% representing noise suppression being off seems counter intuitive.
Is there really an issue with leaving the value's name "Noise suppression" but changing its value to a percentage defaulting to 100% when using rnnoise and leaving its value dB in speex?
I think all the options have their merits and that’s why it’s hard to decide.
Keeping the same slider with a dB “Suppression Level” allows the users to have the same slider to which they are already accustomed for both algorithms. Having a “Dry Mix” (or “Wet Mix”) percentage slider for RNNoise is technically accurate. Having a “Noise Suppression” percentage slider is user friendly and hides unnecessary complexity.
It would seem strange though to have a more user-friendly configuration for one algorithm (RNNoise) and not the other (Speex). The sliders would work in opposite directions too. I wrote the code for @kkartaltepe’s suggestion and made a quick demo. If we’re doing this, maybe it would be best to also hide the complexity of Speex and use the “Noise Reduction” percentage-based slider for both algorithms.
In general though, it must be noted that OBS audio effects are not very user-friendly so we’d be breaking some coherency. Which is not a problem IMO but asks whether all effects should be made more user-friendly and if yes how, which is such a broad subject to debate here in this PR about adding one slider.
Id just like to mention how utterly useless audio engineering terms are to the average user.
This subject always comes up and catering to the "average user" is never the solution, imho. I'd just like to remind everyone that the "Studio mode" button was never meant to only enable the preview/program busses, but was originally intended to switch between a "basic" UI that looked a lot like OBS Classic, and a "studio" UI that catered to the type of user that can Google for "dry mix audio" and has enough reading comprehension to understand the first result listed. I'm getting a bit tired of these incessant discussions about the "average user" that end up almost always to the detriment of the usability of OBS, because of some kind of fear that if OBS isn't a Teletubbie Play-mobil interface the support Discord will get clogged with ignoramuses that don't know what a decibel is. /rant
The sliders would work in opposite directions too.
Hmm I see you are right, thats incredibly annoying. As long as they are consistent I guess thats more important.
a "studio" UI that catered to the type of user that can Google for "dry mix audio"
This is a filter that everyone uses, its not part of the studio ui. Also knowing the magic terms to add to figure out what this means is impossible. Maybe at best a user could guess "Dry mix noise suppression" and that's still incredibly unfriendly. Perhaps more importantly is that there is no intrinsic benefit in the terms being suggested. For a compressor which is hard to conceptualize yea you can google "attack compressor" and get a nice graphic describing these parameters. That isnt the case for "Dry mix noise suppression"
I'm getting a bit tired of these incessant discussions about the "average user" that end up almost always to the detriment of the usability of OBS, because of some kind of fear that if OBS isn't a Teletubbie Play-mobil interface the support Discord will get clogged with ignoramuses that don't know what a decibel is. /rant
Yes if it were actually to a detriment of OBS. I agree with you that having a wet dry mix is the better implementation for the Suppression level in this filter, I just dont see value in changing the name just because we changed the implementation a little. As pointed out for compressors there can be standard parameters for a filter which have value due to their nature, but this isnt a parameter that everyone on the internet has described its renaming to follow some implementation detail when users are already familiar with (hopefully) our existing terminology. Where is the value to anyone in changing the name of this parameter?
I strongly suggest a basic wet/dry mix control to be implemented for every audio filter.
In audio engineering land mixing processed and dry sound is a basic workflow. While in some cases it can produce seemingly surprising results (mainly when processing affects the phase), it's still very desirable.
For noise suppressors it's often necessary to not completely eliminate the noise, but to make it quieter, so the feeling of natural ambiance retains.
Hi there, we're looking to properly review this soon. Please resolve the merge conflicts, squash your commits, and fix the typo in the commit title ("strengh"). Thank you and apologies for the delay!
Hello @WizardCM, thank you. I did as you said then compiled and tested my branch and it worked as expected.
I'm surprised this is still open. Last time I checked it looked like this PR is ok and it's going to be merged. Any reasons for it being stalled?
The commit title after the prefix should be capitalized "obs-filters: Add ...", I brought this up again to see if anyone had any remaining comments on the code. At least to me the code seems good, but im not to familiar with audio filters so hopefully someone else can take a look.
@jp9000 sorry for the ping. Could you please review or instruct what's left to be done to get this merged?
@RytoEX I hesitant to merge this PR for the following reasons:
- rnnoise does not expose its own "strength" parameter (in contrast to SpeexDSP), so there is no actual "denoiser strength" for the user to configure
- Instead the PR adds a dry/wet mix control just for rnnoise, which is not the same
- A dry/wet mix control would be beneficial for all filters, not just this specific one
I don't think we should pretend as if rnnoise's strength can be adjusted (because it cannot). But dry/wet might be beneficial for all filters, though it's not avoidable that users will need to familiarise themselves with its underlying concept. Then again that's something users have to do for all aspects of media creation anyway.
(It should also be noted that most noise suppression that users encounter in the wild is a simple check box with no further parameters, so I don't see this as a much sought-after feature to begin with).
(It should also be noted that most noise suppression that users encounter in the wild is a simple check box with no further parameters, so I don't see this as a much sought-after feature to begin with).
Talking in broad terms, if producers don't do some thing doesn't mean the consumers don't want it. It might mean the former are just uninformed or avoid the thing because of complexity/economical reasons.
Also, you might need to back this statement with some data: all noise reduction processing I encounter has some kind of reduction db slider.
A dry/wet mix control would be beneficial for all filters, not just this specific one.
Even though I initially expressed the same wish, judging from the speed of development in this area of the project, I think it wold be beneficial to move forward with this one. Besides the fact that someone has to actually do it for all the filters (or add the setting for some wrapping code), there's an additional complexity of dealing with possible audio delays (which, I suppose, is not tracked/restricted by OBS atm) or phase changes introduced by individual filters. Both of these factors can drastically change the resulting sound when the processed sound is mixed with the original in some proportion.