Skip to content
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

[BUG] Oversampling causes artifacts with GuitarML module #250

Open
38github opened this issue Dec 18, 2022 · 20 comments
Open

[BUG] Oversampling causes artifacts with GuitarML module #250

38github opened this issue Dec 18, 2022 · 20 comments
Assignees
Labels
bug Something isn't working

Comments

@38github
Copy link

38github commented Dec 18, 2022

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):

  • OS: Windows 10, Linux
  • Reaper
  • Latest stable
  • 64 bit
@38github 38github added the bug Something isn't working label Dec 18, 2022
@jatinchowdhury18
Copy link
Contributor

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:
Screen Shot 2022-12-18 at 9 23 56 AM

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):
Screen Shot 2022-12-18 at 9 25 02 AM

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.

@38github
Copy link
Author

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

@38github
Copy link
Author

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.

@jatinchowdhury18
Copy link
Contributor

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.

@38github
Copy link
Author

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?

@jatinchowdhury18
Copy link
Contributor

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.

@38github
Copy link
Author

I look forward to what you will come up with! Regards.

@jatinchowdhury18
Copy link
Contributor

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!

@38github
Copy link
Author

How do I git pull this branch and not recieve the master?

@jatinchowdhury18
Copy link
Contributor

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-corr

And that should put you on the new branch. After that, you might need to do a submodule update before building.

@38github
Copy link
Author

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!

@38github
Copy link
Author

Should I close this issue or do you want to do some more testing?

@jatinchowdhury18
Copy link
Contributor

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.

@38github
Copy link
Author

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.

@jatinchowdhury18
Copy link
Contributor

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?

@38github
Copy link
Author

38github commented Feb 20, 2023

Void Linux (Glibc, x86_64, X11)
The same issue with VST3, CLAP and LV2 under both Reaper and Qtractor. The same thing happens under Wayland and Sway (window manager).

vst3

The Amp IR module does not have this issue.

@jatinchowdhury18
Copy link
Contributor

jatinchowdhury18 commented Feb 21, 2023

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.

@38github
Copy link
Author

I didn't have issues with the file chooser in Amp IR. I will compile the branch asap and report back to you. Regards.

@38github
Copy link
Author

It works correctly now! Thank you!

@38github
Copy link
Author

Should we close this? I would just like to ask for this option to be enabled by default before we close it, please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants