HQPlayer HQPlayer Convolution Questions

[The Computer Audiophile]

Hi Guys, I have questions about how HQP works with convolution filters. @mitchco's Accurate Sound service created my filters and they work perfect in Roon and JRiver. Now when I use them in HQP I don't quite understand what's happening because they don't work the same way. 

 

In Roon and JRiver, I just add the filters, set the volume to max, and call it a day.

 

In HQP there is more going on that I just don't understand and it has an impact on the sound. I believe it's related to limiting and gain, but I'm at a loss. I'll explain it as best I can below.

 

I added the filters via HQP (see below). I don't understand what IR gain means and why it says -8.64216 dB.

 

 

 

When playing music and the volume is set to 0 dBFS, I see the volume "knob" turns red and the Limited counter is incremented each time. I don't know what's really going on here and if this happens with and without convolution filters. 

 

 

 

 

 

When listening with the convolution filters, there can be a serious high frequency cut off. @Miska said this is related to the limiting listed in the HQP interface. I guess I don't understand why this only happens in HQP. 

 

I'm very confused and would love to understand it more so I can write an accurate article on what I'm doing and write a how-to article for others. 

 

Thanks to anyone who can help.

[The Computer Audiophile]

I also need to understand the relationship between the IR Gain that is sensed after loading the filters and the Gain Comp.

 

[The Computer Audiophile]

I'm looking through notes from @Miska and think I may understand the IR Gain and Gain Comp a bit better. 

 

The IR Gain is just an estimator of the boosting done by filters. If I have this correct, then there is a negative gain / boost by my filters that decreases the volume by -8.64216 dB. Is this correct?

 

But, I also have an email from Jussi that says the IR Gain shown is an increase / boost (even though there is a negative in front of the number).

 

I guess I'm lost. 

[Miska]

2 hours ago, The Computer Audiophile said:

I'm looking through notes from @Miska and think I may understand the IR Gain and Gain Comp a bit better. 

 

The IR Gain is just an estimator of the boosting done by filters. If I have this correct, then there is a negative gain / boost by my filters that decreases the volume by -8.64216 dB. Is this correct?

 

But, I also have an email from Jussi that says the IR Gain shown is an increase / boost (even though there is a negative in front of the number).

 

I guess I'm lost. 

 

If the value is negative, then the estimated gain of the filter is negative (attenuation). In this case you can apply positive gain compensation.

 

If the value is positive, filter has some boost above 0 dBFS, in which case you should apply equivalent amount of negative gain compensation.

 

These are estimates and not always correct for all filters. So knowing the filter design parameters upfront helps. For example on REW it is easy to see what is maximum boost of the eq filters so one can bring the value over to HQPlayer compensation.

 

There are two gain estimators, result of the other one is only written to the log file, but not shown on the GUI. So for some more guidance, one can take a look at the log.

 

[Miska]

3 hours ago, The Computer Audiophile said:

When playing music and the volume is set to 0 dBFS, I see the volume "knob" turns red and the Limited counter is incremented each time. I don't know what's really going on here and if this happens with and without convolution filters. 

 

 

 

This is not related to convolution as such, but it is generic. Most DACs and players just don't tell you about this.

 

If you set volume 0 dBFS and your RedBook content for example is either normalized to 0 dBFS or contains clipping (very typical), you will have inter-sample overs. With just normalized but not clipped you may have +3 dBFS of intersample overs. This is because at for example RedBook sampling rate, the actual sample values don't always happen to be placed at the actual waveform peak, but somewhere else. When simple DAW software normalizes such to 0 dBFS it will cause inter-sample overs in oversampling digital filters that go over 0 dBFS level. Clipped content may make this worse, because then you have essentially square waves in the music where the flat top is at 0 dBFS. When filter (partially) recovers the cut peak, it will again go over 0 dBFS.

 

For this reason you need to leave headroom for such overs, so at least don't exceed the recommended volume setting of -3 dBFS.

 

Many DAC chips and software upsamplers just clip the output at 0 dBFS, while HQPlayer instead applies soft knee limiter to avoid clipping and indicates such event by incrementing the "Limited" counter.

 

Some DACs deal with this the same way, like for example Benchmark DAC3:

https://benchmarkmedia.com/collections/digital-to-analog-audio-converter/products/benchmark-dac3-hgc-digital-to-analog-audio-converter

Quote

Internal digital processing and conversion is 32-bits, and this processing includes 3.5 dB of headroom above 0 dBFS. This headroom prevents the DSP overloads that commonly occur in other D/A converters.

 

This essentially means that it has internal maximum volume setting of -3.5 dBFS that you can't override. HQPlayer doesn't enforce such on you, but indicates that it is recommended. And HQPlayer's DSP pipeline is 64/80-bit floating point instead of 32-bit integer.

 

I have some material where -3 dBFS setting is not enough, but it is not very frequent.

 

[The Computer Audiophile]

15 minutes ago, Miska said:

 

This is not related to convolution as such, but it is generic. Most DACs and players just don't tell you about this.

 

If you set volume 0 dBFS and your RedBook content for example is either normalized to 0 dBFS or contains clipping (very typical), you will have inter-sample overs. With just normalized but not clipped you may have +3 dBFS of intersample overs. This is because at for example RedBook sampling rate, the actual sample values don't always happen to be placed at the actual waveform peak, but somewhere else. When simple DAW software normalizes such to 0 dBFS it will cause inter-sample overs in oversampling digital filters that go over 0 dBFS level. Clipped content may make this worse, because then you have essentially square waves in the music where the flat top is at 0 dBFS. When filter (partially) recovers the cut peak, it will again go over 0 dBFS.

 

For this reason you need to leave headroom for such overs, so at least don't exceed the recommended volume setting of -3 dBFS.

 

Many DAC chips and software upsamplers just clip the output at 0 dBFS, while HQPlayer instead applies soft knee limiter to avoid clipping and indicates such event by incrementing the "Limited" counter.

 

Some DACs deal with this the same way, like for example Benchmark DAC3:

https://benchmarkmedia.com/collections/digital-to-analog-audio-converter/products/benchmark-dac3-hgc-digital-to-analog-audio-converter

 

This essentially means that it has internal maximum volume setting of -3.5 dBFS that you can't override. HQPlayer doesn't enforce such on you, but indicates that it is recommended. And HQPlayer's DSP pipeline is 64/80-bit floating point instead of 32-bit integer.

 

I have some material where -3 dBFS setting is not enough, but it is not very frequent.

 

You’re a star Jussi. You’re way ahead of anything I’m thinking in terms of why it works like it does. This is really helpful. 

[AudioDoctor]

55 minutes ago, Miska said:

 

This is not related to convolution as such, but it is generic. Most DACs and players just don't tell you about this.

 

If you set volume 0 dBFS and your RedBook content for example is either normalized to 0 dBFS or contains clipping (very typical), you will have inter-sample overs. With just normalized but not clipped you may have +3 dBFS of intersample overs. This is because at for example RedBook sampling rate, the actual sample values don't always happen to be placed at the actual waveform peak, but somewhere else. When simple DAW software normalizes such to 0 dBFS it will cause inter-sample overs in oversampling digital filters that go over 0 dBFS level. Clipped content may make this worse, because then you have essentially square waves in the music where the flat top is at 0 dBFS. When filter (partially) recovers the cut peak, it will again go over 0 dBFS.

 

For this reason you need to leave headroom for such overs, so at least don't exceed the recommended volume setting of -3 dBFS.

 

Many DAC chips and software upsamplers just clip the output at 0 dBFS, while HQPlayer instead applies soft knee limiter to avoid clipping and indicates such event by incrementing the "Limited" counter.

 

Some DACs deal with this the same way, like for example Benchmark DAC3:

https://benchmarkmedia.com/collections/digital-to-analog-audio-converter/products/benchmark-dac3-hgc-digital-to-analog-audio-converter

 

This essentially means that it has internal maximum volume setting of -3.5 dBFS that you can't override. HQPlayer doesn't enforce such on you, but indicates that it is recommended. And HQPlayer's DSP pipeline is 64/80-bit floating point instead of 32-bit integer.

 

I have some material where -3 dBFS setting is not enough, but it is not very frequent.

 

 

 

Thanks for writing this out, I was also wondering about the "limited" counter in HQPlayer.

[lpost]

I've been using convolution in HQPe via 'matrix'...I believe I was instructed to use it and not the 'convolution' selection some time ago but it's been a couple years...and my memory fades. 

 

What are the reasons for using one or the other? Is it a difference in the type of files used?

[ericuco]

@MiskaI am currently with @mitchco on DSP filters that are input to HQP and have two questions on convolution settings, one of which was addressed above but still not clear to me.

 

On page 25 of the HQP manual (Version 3.14.0) which discusses the Convolution panel settings, it states:

 

"When positive gain compensation is chosen, it is applied as negative gain when convolution is disabled from the main screen. This makes it easier to compare impact of the particular convolution setup."

 

Does that imply that the "Gain comp" does not do anything when convolution is enabled? In other words, the "gain" is not impacted from the "Gain comp" setting while convolution is enabled?

 

Sidenote: convolution can be enabled/disabled from either the "main screen" and the "convolution screen". Correct?

 

Secondly, the manual states:

 

"When provided impulse response is lower sampling rate than source material, it's high frequency response can be expanded to cover the new bandwidth by selecting “Expand HF” setting."

 

The impulse responses that I have received are 48kHz. As such, I should check the "Expand HF" box given that a lot of my source material is at 96k, 192k, etc. even though a lot is still 44.1k (CD quality).

 

Lastly, for people considering DSP but need some assistance (i.e. don't want to climb the steep learning curve), hire @mitchco today!!! It has been a great experience so far and well worth the expense which is not peanuts but less than what some people spend on cables, DACs, etc. And, it will most likely have a positive impact on your system much more than cables, DACs, etc. ever will.

[bogi]

On 6/30/2020 at 2:41 AM, lpost said:

I've been using convolution in HQPe via 'matrix'...I believe I was instructed to use it and not the 'convolution' selection some time ago but it's been a couple years...and my memory fades. 

 

What are the reasons for using one or the other? Is it a difference in the type of files used?

If you don't need channel mixing (that's the typical case) then IMO you can use any of the two possibilities.

 

Matrix processing gives you more possibilities which you don't need for room corrections - channel mixing, stacking more convolutions, creating presets and easy switching between presets. For example with channel mixing and no convolution IRs you can do multichannel to stereo processing (see picture in HQPlayer manual).

More advanced example is stereo to binaural or multichannel to binaural processing for headphones. That requires both channel mixing and convolution. See an example here:
https://audiophilestyle.com/forums/topic/19715-hq-player/?do=findComment&comment=602225

 

[Miska]

18 hours ago, ericuco said:

@MiskaI am currently with @mitchco on DSP filters that are input to HQP and have two questions on convolution settings, one of which was addressed above but still not clear to me.

 

On page 25 of the HQP manual (Version 3.14.0) which discusses the Convolution panel settings, it states:

 

"When positive gain compensation is chosen, it is applied as negative gain when convolution is disabled from the main screen. This makes it easier to compare impact of the particular convolution setup."

 

Does that imply that the "Gain comp" does not do anything when convolution is enabled? In other words, the "gain" is not impacted from the "Gain comp" setting while convolution is enabled?

 

No, that applies only when gain compensation is positive value (gain). To avoid clipping/limiting, while having similar volume levels with convolution enabled/disabled, the positive compensation is performed as negative compensation (attenuation) for the convolution disabled case.

 

Negative values are processed as usual as attenuation on the convolution enabled case.

 

Idea is that for example if you have +5 dB boost at some frequency, the overall gain of the filter needs to be -5 dB to avoid clipping when full level signal hits that boost frequency. This means the perceived volume of the correction is 5 dB lower. If you compare the two cases without compensation by switching convolution on/off, the perceived volume of the convolution case is 5 dB lower. However, if you apply +5 dB compensation, it drops the non-convolution case volume by 5 dB, meaning you get same perceived level while not having danger of clipping...

 

18 hours ago, ericuco said:

Sidenote: convolution can be enabled/disabled from either the "main screen" and the "convolution screen". Correct?

 

Yes, the convolution dialog enable/disable switch is the main switch. If it is disabled there, you cannot enable it from main window. The switch in main window is on the fly toggle to quickly engage/disengage the convolution during listening.

 

Note that the main window switch doesn't control convolution configured through pipeline matrix. This is safety reasons because pipeline matrix is commonly used for dealing with active speaker cross-overs. Which is something you don't want to switch during listening.

 

Note! At the moment I'm doing big overhaul on how pipeline matrix plugins are handled, which will split this functionality further, then you can have completely independent convolution engine and pipeline matrix convolution plugin.

 

18 hours ago, ericuco said:

The impulse responses that I have received are 48kHz. As such, I should check the "Expand HF" box given that a lot of my source material is at 96k, 192k, etc. even though a lot is still 44.1k (CD quality).

 

Yes, that's the purpose of the function. Some tools like Acourate have equivalent function (Acourate calls it Brickwall extension) that allow creating filters for higher sampling rates than the measurement itself is. For such cases Expand HF is not needed.

 

[lpost]

On 11/19/2020 at 4:33 PM, bogi said:

If you don't need channel mixing (that's the typical case) then IMO you can use any of the two possibilities.

 

Matrix processing gives you more possibilities which you don't need for room corrections - channel mixing, stacking more convolutions, creating presets and easy switching between presets. For example with channel mixing and no convolution IRs you can do multichannel to stereo processing (see picture in HQPlayer manual).

More advanced example is stereo to binaural or multichannel to binaural processing for headphones. That requires both channel mixing and convolution. See an example here:
https://audiophilestyle.com/forums/topic/19715-hq-player/?do=findComment&comment=602225

 

It was Jussi who said to use matrix and not convolution so I didn’t question it.

[paulmckwan]

I have been HQP user for years, and just start using convolution yesterday.

I generate filter by REW and try it in Roon, but it can't handle DSD playback with convolution. But HQP can do it with so small CPU loading, how can this be possible?

I once wonder if it is really enabled that i trigger the convolution button on main screen repeatedly to hear the difference.

[firedog]

11 hours ago, paulmckwan said:

I have been HQP user for years, and just start using convolution yesterday.

I generate filter by REW and try it in Roon, but it can't handle DSD playback with convolution. But HQP can do it with so small CPU loading, how can this be possible?

I once wonder if it is really enabled that i trigger the convolution button on main screen repeatedly to hear the difference.

What are your Sample Rate Conversion-DSD settings in Roon? Turn off "native" DSD processing and turn on parallel processing.

[paulmckwan]

Great thanks, it works like charm !  There is no more drop.

 

When i play DSD, it is convert to 352.8k PCM first before convolution, at ~3x speed even using my NAS Roon core, and my DAC shows 24/352.8 as input signal.

 

Btw, for the "Sample Rate Conversion" section, i leave it as "Disabled" and config as "For Compatibility Only", is this ok ?

i guess since it is disabled, the config of "For Compatibility Only" or others does not matters.

 

[firedog]

Roon is converting DSD to 352 for you b/c you disabled native DSD processing. That tells Roon to convert to PCM before other DSP processing. Since your Bartok is Roon Ready, Roon knows to use 352 - see your device settings in Roon. 

[ecwl]

13 hours ago, paulmckwan said:

I have been HQP user for years, and just start using convolution yesterday.

I generate filter by REW and try it in Roon, but it can't handle DSD playback with convolution. But HQP can do it with so small CPU loading, how can this be possible?

I once wonder if it is really enabled that i trigger the convolution button on main screen repeatedly to hear the difference.

I don’t know what your HQP settings are.

But for Roon, what is happening is that your 352kHz convolution filter is 880k taps which is insanely high.

I think my convolution filter at 44.1kHz is only 66k taps. I suspect yours was 110k taps to begin with for 44.1kHz. But when I generated the convolution filters for higher sample rates in Acourate, they are still 66k taps. So my 352kHz convolution filter is still 66k taps which is why it won’t overwhelm my desktop to apply the convolution filter.

 

I’m actually surprised if you’re to play 192kHz music, your system doesn’t grind to a halt running a 440k taps filter. Or maybe you haven’t tried it yet.

 

You really have two options:

1) Convert your DSD to 88.2kHz in Roon and then apply the convolution filter (which would be at 220k taps) and see if it works. (In theory you can also try 176kHz at 440k taps)

2) Create new 88.2kHz/96kHz/176kHz/192kHz/352kHz/384kHz convolution filters that are only 110k taps and use those for your high-res playback.

 

My guess is that HQPlayer was doing one of the two options above automatically which is why you have no problems playing DSD on HQPlayer

[Miska]

2 hours ago, ecwl said:

But for Roon, what is happening is that your 352kHz convolution filter is 880k taps which is insanely high.

I think my convolution filter at 44.1kHz is only 66k taps. I suspect yours was 110k taps to begin with for 44.1kHz. But when I generated the convolution filters for higher sample rates in Acourate, they are still 66k taps. So my 352kHz convolution filter is still 66k taps which is why it won’t overwhelm my desktop to apply the convolution filter.

 

880k taps is pretty short. Given that with GPU you can process 16M taps at 12 MHz sampling rate without issue... :D

 

880k taps at 352k rate is just about two seconds long filter and shouldn't be much of an issue for a normal CPU either. (for comparison, you can try running HQPlayer's sinc-M filter at 352k rate, which is 1M taps)

 

[ecwl]

13 minutes ago, Miska said:

 

880k taps is pretty short. Given that with GPU you can process 16M taps at 12 MHz sampling rate without issue... :D

 

880k taps at 352k rate is just about two seconds long filter and shouldn't be much of an issue for a normal CPU either. (for comparison, you can try running HQPlayer's sinc-M filter at 352k rate, which is 1M taps)

 

Ah... haha... Right. It’s high for Roon and not for HQPlayer...

 

Definitely. HQPlayer best software for this kind of DSP.

[ecwl]

4 hours ago, paulmckwan said:

Great thanks, it works like charm !  There is no more drop.

 

When i play DSD, it is convert to 352.8k PCM first before convolution, at ~3x speed even using my NAS Roon core, and my DAC shows 24/352.8 as input signal.

 

Btw, for the "Sample Rate Conversion" section, i leave it as "Disabled" and config as "For Compatibility Only", is this ok ?

i guess since it is disabled, the config of "For Compatibility Only" or others does not matters.

 

Oh. I finally understood what happened. It’s working already.

 

Right, so @firedog is right. You probably had Roon do all the processing in DSD, so it was either applying the convolution filter in DSD? Or it was doing DSD to PCM then convolution then PCM back to DSD? Not sure. But bottom line, that was too much for Roon which you’ve now disabled.

 

But as @Miska said, you can probably do that without any problems with HQPlayer because it’s software written directly to use all your CPUs & GPUs to compute.

[dm68]

I've recently started looking into convolution and generating filters using Focus Fidelity. This is probably a stupid question but I just wanted to check, does HQPlayer do the convolution before upsampling and therefore do I match the sample rate of the filter to the source material or HQPlayers upsampled output?

[Miska]

35 minutes ago, dm68 said:

I've recently started looking into convolution and generating filters using Focus Fidelity. This is probably a stupid question but I just wanted to check, does HQPlayer do the convolution before upsampling and therefore do I match the sample rate of the filter to the source material or HQPlayers upsampled output?

 

Convolution is performed at the source rate. (except DSD-to-PCM conversion case, where it is performed after conversion to PCM at 1/16th of the original rate)

 

You don't need to match the sample rate, but instead provide filter at highest rate of your content if possible. Preferably at 352.8 kHz rate (DXD material). HQPlayer then scales the filter to match the source rate, what ever that will be.

 

[Zauurx]

Yes, but in the case of volume management by HQP (e.g. RME volume bypassing), DSDs are transformed into PCM and then DSD?
In this case the cpu load is important.

[Miska]

2 hours ago, Zauurx said:

Yes, but in the case of volume management by HQP (e.g. RME volume bypassing), DSDs are transformed into PCM and then DSD?

 

No, HQPlayer has two separate DSP engines. PCM engine for PCM outputs and SDM engine for SDM outputs. Both have all the same DSP functionality.

 

If you do volume management or any other DSP processing, you should always also do upsampling to increase headroom.

 

For example direct conversion from DSD64 to DSD256 with volume.

 

[dm68]

Thanks @Miska. One other question, I am using an NAA but could not work out how to include it while taking the measurments with REW so ended up plugging my DAC into the control PC. Does this change in signal path make much difference to the measurements and if so is there a way to route REW test signals through HQPlayer in order to keep the NAA in the signal path?