Meier Crossfeed plugin - Has an unexpected behaviour - it acts like a brickwall limiter !

[OK1]

I've been using the version of this open source crossfeed tool, provided by Liqube here

BS2BR VST Plugin » Resonic

Bauer Stereophonic-to-Binaural VST plugin (Resonic Mod)

resonic.at

I discovered, purely by accident, when observing some other plugin behaviour which I won't go into here, that if I have any EQ processing before sending audio to this crossfeed, which causes audio levels to exceed 0dB, in my DAW (Reaper) on Windows 10, the crossfeed plugin then acts like a brickwall limiter, obviously creating some distortion, however imperceptible or not, in the audio.

I have sent an email to the developer about this, but I thought it good to also share with others here.

Workaround - trim before the crossfeed plugin, e.g by 20 dB, before the crossfeed plugin, and boost by 20 dB afterwards.

Or avoid placing any plugin which could cause audio to reach 0dB or more.

Not sure if this limiting occurs on the input to the plugin, or on the output, or both..

I put this to the test using PluginDoctor by ddmf (demo version). and the graph of the dynamics behavior confirms the aforementioned assertion.

 

[kemmler3D]

Good to know. In general it's best practice to not have more than unity gain on an EQ setting anyway, so in terms of best practice this won't affect anything. But, it's another reason to be careful with gain.

I use the same plugin and I really like it. Plain stereo through headphones sounds a bit lifeless to me now.

 

[OK1]

Good to know. In general it's best practice to not have more than unity gain on an EQ setting anyway, so in terms of best practice this won't affect anything. But, it's another reason to be careful with gain.

I use the same plugin and I really like it. Plain stereo through headphones sounds a bit lifeless to me now.

Same here - I have found it quite an improvement to my headphone listening. The limiting behaviour was somewhat unusual because in modern plugins that have either 32 float processing, or more recently 64 bit float audio processing in both plugins as well as the DAW audio path, there should be no need to place limits in the processing, cos there is just so much headroom.

I must say, its the 1st time I have observed this unintended behavior in any plugin.

My thoughts are, the root cause is from the core library cos from what I can deduce the core library supports various implementations - WinAmp, Foobar, etc, so maybe that's what's causing it.

My current workaround, to avoid any issues, is to setup the plugins in the following order, when playing back audio from mastered sources, which typically will have peaks as high as -0.1dBFS.

1. Gain - reduce by 20dB
2. BS2R plugin
3. Gain - make up by 20dB
4. Any other processing such as EQ.
5. Gain adjustment for monitoring

I must add though, in my environment, all volume management of the output to the headphones is done via the DAW, so in step 5, I have a gain reduction that is typically at least -30dB, so there is no way the final audio from the converters will clip.

I will check the number of bits which BS2R outputs, and I may refine the gain reduction and gain make up values in steps 1 and 3, based on this. If BS2R is for example truncating to 16 bits, I'll reduce the values to -3dB and 3dB, to minimise any loss of accuracy in the processing.

 

[kemmler3D]

Same here - I have found it quite an improvement to my headphone listening. The limiting behaviour was somewhat unusual because in modern plugins that have either 32 float processing, or more recently 64 bit float audio processing in both plugins as well as the DAW audio path, there should be no need to place limits in the processing, cos there is just so much headroom.

I must say, its the 1st time I have observed this unintended behavior in any plugin.

My thoughts are, the root cause is from the core library cos from what I can deduce the core library supports various implementations - WinAmp, Foobar, etc, so maybe that's what's causing it.

My current workaround, to avoid any issues, is to setup the plugins in the following order, when playing back audio from mastered sources, which typically will have peaks as high as -0.1dBFS.

1. Gain - reduce by 20dB
2. BS2R plugin
3. Gain - make up by 20dB
4. Any other processing such as EQ.
5. Gain adjustment for monitoring

I must add though, in my environment, all volume management of the output to the headphones is done via the DAW, so in step 5, I have a gain reduction that is typically at least -30dB, so there is no way the final audio from the converters will clip.

I will check the number of bits which BS2R outputs, and I may refine the gain reduction and gain make up values in steps 1 and 3, based on this. If BS2R is for example truncating to 16 bits, I'll reduce the values to -3dB and 3dB, to minimise any loss of accuracy in the processing.

I would be surprised if it was doing 16 bit internal processing, or even 24, but it's an old and free plugin, so I wouldn't rule it out.

 

[OK1]

I would be surprised if it was doing 16 bit internal processing, or even 24, but it's an old and free plugin, so I wouldn't rule it out.

I'm using two different plugins to check the bit depth of the output.

1. This is the result of the version 1.1 of the original BS2B 32 bit version, which is from the tools I have used to check, outputting 64 bits.

2. This is from the BS2R - or BS2BR (depending on what you prefer to call the latest version) by Liqube. - this is a 64 bit plugin, which also processes the audio with 64 bits.

So clearly the unintended brickwall compression is unrelated to the bit depth, and appears to be an artefact from the original code.

The workaround I've implemented is to trim by -5db before the plugin, and make up gain by 5dB, after the plugin, when listening to commercially produced music, and place all customisation such as eq for my personal taste on headphones - after the plugin.

 

[kemmler3D]

Thanks for checking. It's weird that there's a limiter in there, but good to know!