Is the convolution in EQ APO unstable?
A system-wide equalizer for Windows 7 / 8 / 8.1 / 10 / 11
Brought to you by:
jthedering
Menu
▾
▴
#292 Is the convolution in EQ APO unstable?
I discovered some rather strange things while testing a few VSTs, and I'd like to share a few of them.
The comparison is between APO and Foobar.
For a stable comparison, I used pink noise for more than 15 seconds and applied a 65536 rectangular windowing to observe the spectrum.
Please refer to the attached links for the images.
In the attached image 001, the top shows the Foobar loopback, and the bottom shows the APO loopback. I used the same VST with identical settings and performed a loopback test.
In the attached image 002, the dark blue graph represents the loopback of the convolution VST in APO, while the purple graph shows the same in Foobar. There is a significant difference between them.
And in image 003, I applied psychoacoustic smoothing to make it easier to observe the results.
The differences are just too extreme, and I can't understand why. I clearly noticed a difference when using the VST in APO compared to Foobar, and it’s now reflected in the results. The correct response, where the convolution is properly applied, is on the Foobar side.
Image 004 shows the results with an algorithmic reverb (not convolution). Aside from minor deviations between the loopback and the algorithm, they appear almost identical. This made me wonder if there’s an issue with the convolution process itself, so I decided to try something else.
In image 005, it's a comparison of TrueStereo convolution. The orange line represents Hesuvi + APO, and the green line is Foobar's TrueStereo convolution (both using the same response). There’s quite a strange difference between them.
Could it be due to the sample rate? However, my sample rate is consistent at 48kHz, and both APO and Foobar follow the Windows sample rate settings, don't they?
This seems like a rather strange result.
And it might just be a measurement error. However, even before performing the loopback, I noticed a significant difference when listening directly. I would like to know why the developer thinks these results differ and if there is a way to fix it.
https://github.com/chebum/equalizer-apo-64
https://github.com/TheFireKahuna/equalizerAPO64/releases/
And while searching, I found some links where people seem to be using a more customized version of an older release. Particularly on GitHub, it mentions that it performs complex elements (like Hesuvi) more accurately.
So, does this imply that the official release of EQ APO isn’t handling complex elements—such as stereo or TrueStereo convolution—properly at the moment? Even if it is functioning correctly now, I’m still puzzled as to why the results between EQ APO and Foobar are different.
Intriguing results. Would be interesting to know where this difference comes from. I'm guessing it's not the sample rate. If I'm not mistaken sample rate issues will become larger when approaching the sample rate frequency. In this case the problem is present over the whole frequency spectrum. Also, if the current Equalizer APO is using 32 bit numbers this resolution is still very high (4,294,967,296 steps). For normal purposes calculating (mixing) with the resolution shouldn't give such huge changes IMO.
Perhaps it's about 2 different ways of doing convolution? Then again, it's the same VST. Of course the Foobar TrueStereo and Equalizer APO convolution (HeSuVi) can differ.
Equalizer APO does follow the set Windows sample rate. It must as it's an Audio Processing Object (an "object" placed in the audio stream).
That's exactly what I'm trying to say. Precisely!
There might be differences in how TrueStereo is processed. However, when applying it in other DAWs like Foobar or Reaper, the results were similar to Foobar’s. Even putting that aside, images 002 and 003 show a very simple stereo convolution.
What’s more, these results came from using the same VST, so I expect them to be the same. While I don't expect perfect consistency from a program's stability or real-time convolution, the loopback results I got were so different that it left me a bit confused. (In fact, at this point, they don’t even seem like the same response. It’s more like comparing two entirely different responses.)
Therefore, basic PEQ or mono convolution seems fine. However, it looks like at least stereo and TrueStereo are not being applied correctly. I hope the developer pays attention to this issue.
After discovering this problem, I considered switching to another program, spending the day testing JRiver, Foobar, and Reaper as potential alternatives. However, I found them too heavy and inconvenient for my needs.
And the issue with the sample rate is just a small hypothesis of mine. I don’t actually believe it’s the cause. The fact that only EQ APO shows these results suggests there’s something wrong in the way it handles convolution (or perhaps the channel mixing?). VSTs do involve some form of channel mixing depending on the mix level, but for this test, I set the mix to 100% to ensure a fair comparison. It seems like the problem lies in how EQ APO processes convolution. Yes, channel mixing is handled within the VST itself, not inside EQ APO. However, the issue could still lie in how EQ APO interacts with the VST during processing.
Honestly, I have no clue what the cause could be. LOL.
But now I understand why so many people have complained about using convolution VSTs in APO.
Last edit: dingdong3 2024-09-10
In principle it's about "giving" the samples per channel to the VST and then receiving them after processing. Probably it's more complicated then this. But this should be the same as in DAWs. Perhaps a stupid question but are you sure no other Equalizer APO commands are present creating the difference?
I'm only aware of a convolution issue of Equalizer APO, not of the VST's. But they are people having difficulties with VST's so perhaps with convolution ones too.
I've read up on the TrueStereo. I'm wondering how the impulse response file is built up. 4 channels in 1 file or 4 files for each channel. Anyway, as you I think the channel mixing is (and should be) done in the convolution VST or any VST for that matter. Equalizer APO can't handled or expects the receiving of 4 TrueStereo channels.
iI didn't have anything turned on except VST when I experimented with those loopbacks. (Nothing EQ or any channel mixing)
So the only other thing is the program. Is it EQAPO or Foobar or Reaper?
Same VST, same value, nothing else. No variables.
Yes. It's actually what Hesuvi's text filter does, but when wav files with multiple tracks are convolved, they read them in order and distribute them to virtual channels. And mix them up. And I think the huge difference that happens when you use "simple normal stereo" to convolve "simple regular stereo" is actually more important, except for the difference that comes from True Stereo as mentioned earlier.
Last edit: dingdong3 2024-09-10
I also don't get it that mono convolution isn't a problem. It does suggest a channel or channel mixing issue as you mentioned.
Looking at the code (see attached cpp file) it suggests that things aren't straightforward (see Initialize and Proces functions).
Last edit: Peter Verbeek 2024-09-10
I must say I don't understand what's going on in the code.
Just like we talked about in the "peace" thread, I'm also into acoustics, but I don’t know anything about programming. I have no idea what that code means either. =(
When I asked GPT to summarize and explain the code you provided, it gave me the following information.
Constructor: The constructor initializes the VST plugin filter by accepting a plugin library, configuration data (chunkData), and a parameter map. It also stores the library path (libPath) for future use.
Destructor: The destructor ensures that resources are freed by calling the cleanup() method when the object is destroyed.
Memory Cleanup: It clears any previous state by calling cleanup() and then checks the number of channels to process. If there are no channels, it returns early.
VST Plugin Instance Creation: It creates the first instance of the VST plugin and attempts to initialize it. If initialization fails, it logs the error and sets the skipProcessing flag to skip further processing.
Creating Additional Instances: Depending on the number of input and output channels, the code calculates how many additional VST instances are needed and initializes them accordingly.
Setting Input/Output Arrays: The input and output arrays are configured to handle the correct number of channels, and any unused channels are filled with zeroes.
Input/Output Mapping: During audio processing, the input and output data are mapped to the correct plugin instance. The method processReplacing is used to process the audio frame by frame. In case of crashes during processing, it copies the input directly to the output as a fallback.
It releases memory and stops the processing of each VST plugin instance. It also deallocates the input and output arrays, ensuring that all resources are properly cleaned up.
This code is designed to handle multi-channel audio processing with VST plugins, ensuring stability with robust memory management and crash handling through exception handling mechanisms.
I don’t really know either. I can’t be certain about mono convolution since I rarely use it. The only time I used mono convolution was when I created and applied FIR filters for speakers a while back. However, that filter didn’t require complex calculations like impulse responses with room reflections do, so maybe that’s why there were no issues. Honestly, I’m not sure.
But one thing is certain:
There’s definitely an issue, whether it’s with the convolution, the channels, or the channel mixing. If there were no issues, the loopback results would have been the same regardless of which DAW I used.
I think you’d agree with me on this point too.
Yes, unless we overlook something obvious 😃 But there seems to be an issue here.
It's been a chaotic day =).
I hope the developer sees this and cares about it.
Yes, there won't be any noticeable issues in a typical VST (errors that seem to cause a huge clipping I've written before? Because this is trivial).
But the reason why I said this is because it might not fit the topic of this thread, but I'll write it down briefly.
With convolutional reverb and algorithmic reverb, we can sort it out.
Algorithms are artificial, convolution is literally loading impulses.
It depends on the purpose, but usually the more realistic feeling is excellent for that purpose because the convolution side contains real space.
But if you had this problem with VST using convolution (or convolution + direct channel mixing of IR above stereo by yourself), it would be that it didn't work properly, so I think you experienced dissatisfaction.
Because I usually remember the reviews of using convolutional reverb VST in APO were not good, and they said it was good when using it in Foobar or Driver. So when I saw it before, I just thought that those VSTs were not compatible.
But today, I looped back and checked it myself, and it's not a matter of VST, but APO's convolution, channel mixing, or computational processing? Or just mystery?
I don't think anyone could have had the right experience because there was something unknown
Yes, no one did what you did, a proper investigation and comparison of the frequency spectrum and gains.
Indeed, convolution isn't an algorithm we can easily check the calculation ourselves. For all we know Equalizer APO could be doing it alright and the other apps doing it wrong! Highly unlikely of course. Another way of saying we can't check what's going on.
I've tried reverb convolution with Equalizer APO's own convolution feature. It seems to go alright. Perhaps it's about the way convolution has to be done when using a convolution VST. It could just be incompatible with Equalizer APO or any Audio Processing Object for that matter. Or it has some limits that we don't know about. One way to rule out the lack of resolution is to try the 64 bit resolution Equalizer APO, well, if it has VST capabilities. But I strongly suspect one of the other issues you summed up (convolution, channel mixing, or computational processing).
You should, though. Convolution is a mathematically exact process that is not subject to interpretation. When done correctly it will always give the exact same results all the way down to the numerical precision of the convolution method used (which, in 32-bit float as is the case here, is virtually perfect for all intents and purposes). I don't know why you are getting these results, but there is definitely something wrong somewhere, either in one of the chains or in the way you are making the measurements.
Here are a few things I can think of:
Equalizer APO\config\config.txtfile for us to double check?First of all, I'd like to say I'm sorry. Except for 005 in the image link I've previously posted, the rest is somewhat wrong. (But it's not saying it's the same. What looked completely different was that the apply button was not pressed inside the VST, but it's still different like image 005. Of course, it's Foobar that's right when you hear it.)
And I don't have time for more measurements because I have to sleep now. So I just leave a few briefly.
https://imgur.com/a/LiTVCNS
As expected, please refer to the link.
Also, in order to share the meassurement more accurately, I recorded it several times with sign sweep, not pink noise, and I can check the impulse.
Variations in the impulse are also clearly identified.
001 : Foobar2000 same vst loopback (bottom is -20db, 4times meassurement. same result)
002 : EQAPO same vst loopback (bottom is -20db, 4times meassurement. same result)
003: Compare FR
004: Compare Impulse
006: Reference Dirac Pulse
007: Eq APO dirac pulse loopback
008: Foobar2000 dirac pulse loopback
009: Compare
The result of this body link will be reproduced as it is now, even if the vst settings are done correctly. I don't have any specific settings in the config. Except for turning on VST
I previously acknowledge and apologize for the wrong setup in example images 001~004. Sorry for the confusion.
But the problem still remains. As expected, it's different.
And I forgot the comparison of the wider time band and didn't put it in the link. So I'm adding the attachment.
It's completely different when you look at the overall impulses, not the very early impulses.
Obviously that is the same channel and should be the same impulse.
Last edit: dingdong3 2024-09-10
The graphs look almost the same but somehow shifted in frequency.
One of the impulse responses is stretched in time, with an increasing shift as time passes. The time shift at about 50 ms is about 5 ms. That suggests a 10% speed difference. Guess what: 10% is also the difference between 44100 Hz and 48000 Hz. So I would really look into the possibility that the convolution is being done at the wrong sample rate.
Last edit: Etienne Dechamps 2024-09-10
More specifically, I am willing to bet that in foobar you are playing a 44.1 kHz file (which requires a 44.1 kHz IR if you want to convolve in foobar), but your Windows shared audio pipeline is operating at 48 kHz (i.e. it's resampling foobar's output). You can't use the same IR for both - it's either a 44.1 kHz IR or a 48 kHz IR, it can't be both at the same time. Now, ideally I would expect the convolver to reject an IR whose sample rate does not match the convolver's input, but maybe one (or both) convolvers lack that check and will happily accept the wrong sample rate.
This would completely explain the differences in the impulse responses you posted.
That must be it, a straightforward explanation of the issue. The VST within Equalizer APO processes a 48 kHz sample rate audio stream. I'm guessing the VST resamples the impulse response file to 48 kHz.
If the VST resampled the IR to match the input, that would actually produce the correct result. The hypothetical problem that I'm describing is the exact opposite - the VST is not resampling the IR, and yet accepts it anyway (it shouldn't, ideally), and for that reason ends up processing a 48 kHz stream with a 44.1 kHz IR (or vice-versa).
You were right. Brilliant insight! As you mentioned, I checked in Foobar and saw that it was set to 44k. When I tested it using a Dirac pulse for 44k, the results were the same. So, the previous differences in FR and impulse responses were due to the sample rate issue. This is great information!
And while this resolves my initial concern, it also raises a new one. If the issue was the sample rate, it suggests there might be a problem with how the mix is handled when multiple convolutions are running simultaneously. With a single convolution, APO performs accurately without any issues, but in other conditions, it behaves differently compared to Foobar, JRiver, and Reaper. I’ll need to investigate further.
I’ll probably test this again over the weekend. Instead of a simple L or R channel loopback, I’ll need to use a TrueStereo loopback to see if the channel relationships are being maintained correctly.
Thank you so much for your advice and ideas!
You're right of course. So this specific VST is accepting a file which it shouldn't. But as this file selection is done in the Configuration Editor perhaps the sample rate check fails?
I don't know...In fact, the sample rate, when you and Etienne told me that the response was the same when I prepared the file for each sample rate myself, I could see that there was no problem with it anymore.
The other one, then, is the story of complex components (e.g., hesuvi + other convolutions or convolutions or VST)
Then, we should go back to the part related to channel mixing, maybe right?
This is what I recorded.
Same setting, but different with convolution working. Listen with IEM or headphones. Am I sensitive? I thought it was just a placebo, but when I recorded it like this and played it to other users, I was told that the depth of the convolution was distorted almost to the difference between mono and stereo and was omitted.
And I think that's the channel mixing that I previously suspected (there's something wrong with the correlation between each channel).
Or I can't help it. Then I don't know any more... Of course, I finished setting up Reaper today, so I can use it no longer without any problems.
https://youtu.be/cZ3uDf-nDSE
Listening to the convolution versions it does sound "narrower", more mono. But that can be caused by the reverb impulse response file although it should sound the same in Equalizer APO as in Foobar/Reaper. Also, the wave forms of the left and right channel do seem different so it isn't mono. It's hard to say if there's a problem or what the problem is if any. Btw. To me it sounds like a good sounding reverb. I can't hear any distortion. A bit metalic but the original does sound a bit metalic to me too.
The mystery is that they're both convolutions (as you can see me cutting the track). Originally, they both had to be the same. That's the puzzle I'm looking for right now..
The left-right channel looks different because it is in the true stereo state, not mono.