-
Notifications
You must be signed in to change notification settings - Fork 39
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Loading noise profile from Carla carxp file does not work #114
Comments
Thanks for reporting! Will look into it soon! |
Thank you for the quick reply. I just want to point out issue lucianodato/libspecbleach#52 to you in case you come to the conclusion that fixing the bug here involves changes that are closely related to said other issue. (Of course, if it turns out that they are unrelated and can be fixed independently, please keep them separate.) |
Is there any progress regarding this issue? I consider it quite important because being able to always use the same noise profile is the main reason as to why someone would use this plugin in the first place (as opposed to, let's say, the adaptive variant). Also, I just found out that Carla produces log lines whenever I open a carxp file with it. Here are the relevant lines:
I hope this helps. |
I have (or had) the same issue. I actually didn't even know this plugin saves the learned noise profile before I saw this post. I found the cause for it. I didn't find a clear explanation why it happens, but from what I gathered, calling "retrieve" again changes the previous retrieved value to something high (maybe pointers to pointers? or just trash data?). I didn't try dereferencing them twice tho, because I just now thought of that. Some links I researched: Anyways, I jerry rigged it with two extra constants and it works (nrepellent.c from line 402):
I didn't wanna create a pull request cause I don't know if this is proper way to deal with it. If you want to know more about the values, on one test run "fftsize" printed out as 1105 when first retrived and 128445920 after the "averagedblocks" retrieve. And "averagedblocks" printed out at first retrieve as 2354 and after the "saved_noise_profile_1" retrieve it printed out as 128444992. |
Thank you so much for fixing this issue, @TekMiikka. I simply replaced the entire Let us hope that the issue will be fixed upstream so other users can enjoy it as well. |
I tried your solution @TekMiikka and it seems like it almost worked. It definitely loaded something, but it only seemed to be doing something with one side of the audio. At least it's progress |
Here's @TekMiikka patch with my horrible hackiness applied... I just made it to load the
|
Based on the fix by @SnipeXandrej lucianodato#114 (comment)
First of all, thanks for the great work!
I am using Carla on JACK 2 with Noise Repellent on Arch.
Noise Repellent works fine if Carla learned the noise profile during the very same session. That is, "Residual listen" clearly demonstrates the difference between noise and signal. However, now that it works, try saving the current Carla session in a carxp file and close Carla. The carxp file is an XML file and seems to store the noise profile as well.
Now, open Carla again and load the carxp file. "Residual listen" indicates that the noise profile stored in the carxp file is not respected. Note, however, that other parameters like "Reduction amount" ARE respected. Now, without changing anything, save the very same (seemingly broken) session under a different name using "File" -> "Save as". Both the old and the new carxp file are completely identical, indicating that the noise profile has not been discarded and/or not been overwritten during loading the carxp file.
Since Noise Repellent 0.1.5 is not affected, even when using the same Carla version, Carla is probably handling all the values as expected, indicating that Noise Repellent, for some reason, does not care about the noise profile presented by Carla.
Speculation: Maybe not all identifiers have been properly renamed while progressing from 0.1.5 to 0.2.0 or later.
Please keep up the good work.
The text was updated successfully, but these errors were encountered: