[BUG] Oversampling causes artifacts with GuitarML module #250
Comments
|
Hi there, thanks for the bug report! I've been trying to re-create the issue locally, but I'm having a bit of trouble. For example, here's the GuitarML module running a model with 2x oversampling. The input sound is a 2 kHz sine wave, and as you can see from the spectrum analysis, it doesn't seem like there's any aliasing happening: If I bump the oversampling up to 16x, the spectrum still looks about the same (and sounds the same too, but I guess you'll just have to take my word for it for now): Additionally, it seems odd that using more oversampling would lead to aliasing... typically for nonlinear processes, including the neural networks that the GuitarML module is using, using more oversampling would attenuate potential aliasing artifacts. I wonder if the actual issue is that some buffer under-runs occur when using the GuitarML models with oversampling? That's always a danger when using CPU-heavy processing with lots of oversampling. The CPU meter in the lower right corner of the plugin should show the current CPU usage. As you can see in the screenshot above, running the GuitarML module at 16x oversampling puts the CPU meter at 56%, so if I'm running other BYOD modules, or other plugins in my session, that could definitely lead to buffer under-runs, and the associated audible artifacts. If that's the case, I'd suggest not using oversampling with the GuitarML module, since it doesn't make as much of a difference in the resulting sound as it would with some of the other BYOD modules. |
|
Thank you for the detailed reply. Under-runs maybe is the issue. I will try it out on a more powerful computer and see/hear the results and get back to you |
|
I tested it now and there is added high frequencies when I play very high frequencies through a model. Easiest to notice it is to feed white noise through a model. |
|
Ah okay, I was able to measure the same thing using a white noise as input. I believe the issue is happening because the GuitarML networks are trained for a 44.1 kHz input, so when the network is run at a higher sample rate, it ends up having to deal with signal outside of what it was trained on. I'll do a bit more investigation on this soon. |
|
Is it possible to put a "constant resampler" at 44100 Hz in the beginning of the GuitarML module and then after resample it back to whatever sample rate the project is using? |
|
Yeah, I've tried that approach with neural network-based effects before, and I'd really prefer to avoid going that route in this situation. The primary issue is that there's an inherent tradeoff between the resampler quality and latency. I've been trying to make sure that BYOD modules are as close as possible to zero-latency. After analyzing the frequency response change a bit further, I'm fairly confident that the apparent change is due to a comb-filtering effect, rather than some sort of aliasing artifacts. With that in mind, I think the best solution might be to have some kind of "compensation filter" to compensate for the change in frequency response. I'm doing a bit more analysis to try to figure out the best way to design the compensation filter, but I'll try to have something ready for testing soon. |
|
I look forward to what you will come up with! Regards. |
|
Okay cool, I've got a branch working with a correction filter (https://github.com/Chowdhury-DSP/BYOD/compare/guitarml-sample-rate-corr). The filter can be enabled/disabled with a parameter, and old patches will open with the parameter turned off so that the sound is not affected. Anyway, definitely let me know if you're able to give this branch a try! |
|
How do I git pull this branch and not recieve the master? |
So if you're inside the repository, you should be able to do: $ git add remote chowdsp https://github.com/Chowdhury-DSP/BYOD
$ git fetch chowdsp
$ git checkout guitarml-sample-rate-corrAnd that should put you on the new branch. After that, you might need to do a submodule update before building. |
|
When Sample Rate Correction FIlter option is blue the oversampling creates what sounds like low-pass filters but with the option not showing in blue it sounds the same no matter what oversampling is used. I haven't tested loading projects with different sample rate yet though. It is a thrill to post about things here and see what solutions/features you come up with! |
|
Should I close this issue or do you want to do some more testing? |
|
I'm actually going to leave this open for a bit... i had another idea that I wanted to try out, but haven't had the time yet, so this issue would be a good reminder. |
|
By the way, I don't know if you know but in this build the GuitarML open file window opens up in the GuitarML module frame. To be able to view anything I have to zoom in a lot. Unfortunately I have no screenshot at the moment. |
Oh interesting... I haven't noticed this in my own testing, plus I can't think of what I would have changed that would have made this difference... A screenshot would definitely be helpful, plus I would be curious to know if the same thing happens with the Amp IRs module? |
|
Void Linux (Glibc, x86_64, X11)
The Amp IR module does not have this issue. |
|
Ah okay, probably something specific to JUCE's LInux file chooser... I have an idea what it could be. Have you noticed the same thing with the file chooser in Amp IRs? Edit: I just pushed a fix to the same test branch, which should affect both modules. |
|
I didn't have issues with the file chooser in Amp IR. I will compile the branch asap and report back to you. Regards. |
|
It works correctly now! Thank you! |
|
Should we close this? I would just like to ask for this option to be enabled by default before we close it, please. |
Describe the bug
Load the module, load a Proteus json and choose any oversampling. The higher the oversampling the more artifacts there are. Sounds like aliasing.
Expected behavior
No artifacts
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: