HQPlayer HQPlayer Convolution Questions

[Miska]

1 hour ago, dm68 said:

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?

 

It doesn't change the result in a way that would matter. For my measurements I just use Toslink cable from the measurement computer to the DAC and use a measurement microphone. The only case where this could matter is if you use rePhase or Acourate or similar that does also phase corrections AND the DAC is using minimum-phase filter.

 

You should always try to make sure you are using linear phase digital filter when doing room correction measurements.

 

[luisma]

2 hours ago, Miska said:

For example direct conversion from DSD64 to DSD256 with volume

In this specific case you are listing, the "volume" implies DSD64 is converted to PCM (volume DSP applied) then that PCM to DSD256 correct? the word "DIRECT" to me means usually "no PCM" but it was my understanding volume and DSP must be done under PCM.

 

EDIT01: And of course this comment you posted

"PCM engine for PCM outputs and SDM engine for SDM outputs. Both have all the same DSP functionality"

kind of tells me the SDM engine has "no PCM" at all so even convolution and DSP are done under SDM "direct"

[Miska]

3 minutes ago, luisma said:

In this specific case you are listing, the "volume" implies DSD64 is converted to PCM (volume DSP applied) then that PCM to DSD256 correct?

 

No, it is 2.8M -> 11.2M with specified gain.

 

[dm68]

53 minutes ago, Miska said:

 

It doesn't change the result in a way that would matter. For my measurements I just use Toslink cable from the measurement computer to the DAC and use a measurement microphone. The only case where this could matter is if you use rePhase or Acourate or similar that does also phase corrections AND the DAC is using minimum-phase filter.

 

You should always try to make sure you are using linear phase digital filter when doing room correction measurements.

 

Hi Miska, Focus Fidelity does do phase corrections. So referrring back to my previous question is it at all possible to carry out measurements with REW via HQPlayer and the NAA and keep the signal path the same as during music playback.

[Miska]

4 minutes ago, dm68 said:

Hi Miska, Focus Fidelity does do phase corrections. So referrring back to my previous question is it at all possible to carry out measurements with REW via HQPlayer and the NAA and keep the signal path the same as during music playback.

 

I think you could export the test signal, play & record it and then import it afterwards. But I don't think it is usually worth the effort if you know/can choose the DAC's digital filters.

 

[dm68]

15 minutes ago, Miska said:

 

I think you could export the test signal, play & record it and then import it afterwards. But I don't think it is usually worth the effort if you know/can choose the DAC's digital filters.

 

OK many thanks.

[Miska]

Note that I've got accidentally "funny" results from phase corrections because the ADC used for microphone was using a minimum phase filter. So also pay attention into what kind of gear is used for the microphone side.

 

[GMG]

On 3/16/2021 at 10:49 AM, Miska said:

 

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.

Hi @Miska

does it matter much if the filter for convolution is based on 44.1kHz or 48kHz rate families?

if my filter is 192kHz would the scaling to 176.4kHz cause any disadvantage  vs using a 44.1 based filter or even a native 176.4 filter? Or are the differences negligible for convolution purposes?

[bibo01]

11 hours ago, GMG said:

Hi @Miska

does it matter much if the filter for convolution is based on 44.1kHz or 48kHz rate families?

if my filter is 192kHz would the scaling to 176.4kHz cause any disadvantage  vs using a 44.1 based filter or even a native 176.4 filter? Or are the differences negligible for convolution purposes?

@MiskaJust to add to questions above...

Probably a measurement is made at 44.1 or 48 hKz, thus what is the best way to upsample it to 352.8 kHz? Can HQP Pro be used?

[Bob Stern]

@bibo01 & @GMG:

I expect Jussi can give you a more focussed answer if you state whether you used a USB mic.  If so, the measurement definitely was made at 48 KHz.

[bibo01]

2 hours ago, Bob Stern said:

I expect Jussi can give you a more focussed answer if you state whether you used a USB mic.

No, not in my case. 

[copy_of_a]

19 hours ago, GMG said:

does it matter much if the filter for convolution is based on 44.1kHz or 48kHz rate families?

if my filter is 192kHz would the scaling to 176.4kHz cause any disadvantage  vs using a 44.1 based filter or even a native 176.4 filter?

 

Filters are scaled (up-/downsampled to match the source rate) in the background before playback. Gerneral advice is to have a filter at the highest (PCM) rate of your source files. So if you have some 192kHz files the IR file should be 192kHz if possible. But if you only have 44.1k or 48k filters these sure will do as well (check „expand HF“ in this case if you apply upsampling).

 

[quote]Or are the differences negligible for convolution purposes?[/quote] This

 

-> 

 

 

[Miska]

19 hours ago, GMG said:

does it matter much if the filter for convolution is based on 44.1kHz or 48kHz rate families?

if my filter is 192kHz would the scaling to 176.4kHz cause any disadvantage  vs using a 44.1 based filter or even a native 176.4 filter? Or are the differences negligible for convolution purposes?

 

No it doesn't matter. If you can create convolution filter for 352.8k then that would be best.

 

[GMG]

Thanks

1 minute ago, Miska said:

 

No it doesn't matter. If you can create convolution filter for 352.8k then that would be best.

 

Thanks!

 

2 more questions if I may:

1. is it possible to provide multiple versions of the filter (like in Roon), and therefore avoid the need for up/down scaling

2. is the convolution performed before or after the up sampling? let's say my track is 44.1 and the convolution filter is 192 and the up sampling is set to 768, when and with which sampling will the convolution be done. In Roon the convolution is down after upsampling to the final sampling rate - claiming it will produce the best convolution results 

[Miska]

8 hours ago, bibo01 said:

Probably a measurement is made at 44.1 or 48 hKz, thus what is the best way to upsample it to 352.8 kHz? Can HQP Pro be used?

 

You shouldn't do that, there's no advantage in doing so and in addition it causes harm, because you lack the "HF Expand" feature. If you cannot create filter natively for 352.8k rate, so that it would have a real frequency response up to 176.4k, you should instead give HQPlayer the one created at measurement rate and let HQPlayer scale it using special algorithms created for the purpose.

 

Measurement rate itself doesn't necessarily matter if it's for example 44.1k, rather it matters how the filter is created from it. IOW, what happens beyond Nyquist of the measurement rate.

 

[Miska]

9 minutes ago, GMG said:

1. is it possible to provide multiple versions of the filter (like in Roon), and therefore avoid the need for up/down scaling

 

No, there's no reason for such. And since HQPlayer doesn't have any limited set of supported source rates, the number of rates could be unbounded.

 

9 minutes ago, GMG said:

2. is the convolution performed before or after the up sampling? let's say my track is 44.1 and the convolution filter is 192 and the up sampling is set to 768, when and with which sampling will the convolution be done.

 

It is documented in the manual... Convolution is performed at the source rate, for PCM and DSD. Except when you are playing through DSD -> PCM conversion, in which case it is performed at 1/16th of the source rate, except if your conversion is set to "none".

 

9 minutes ago, GMG said:

In Roon the convolution is down after upsampling to the final sampling rate - claiming it will produce the best convolution results

 

I disagree.

 

If your source is 44.1k RedBook and thus has content up to 22.05k. Why would you perform convolution at 11.2M rate where there is no content between 22.05k and 5.6M?

 

[GMG]

Thanks Miska

Very clear

[Ozan Bolat]

1 hour ago, Miska said:

 

No, there's no reason for such. And since HQPlayer doesn't have any limited set of supported source rates, the number of rates could be unbounded.

 

 

 

 

To make clear for me when I'll create convolution filters : it is your opinion that there is not benefit in playing 96 file with 192 filter and then switching to 176.4 filter when playing a 88.2 or 44.1 file?

[Miska]

8 hours ago, Ozan Bolat said:

To make clear for me when I'll create convolution filters : it is your opinion that there is not benefit in playing 96 file with 192 filter and then switching to 176.4 filter when playing a 88.2 or 44.1 file?

 

Yeah, especially if the filters are based on single measurement it is no different using different filters than letting HQPlayer scale the filters.

 

Since most tools don't support creating filters for DSD64/DSD128/DSD256 rates anyway, HQPlayer has capability to adapt filters for whatever rate is needed.

 

[Ozan Bolat]

51 minutes ago, Miska said:

 

Yeah, especially if the filters are based on single measurement it is no different using different filters than letting HQPlayer scale the filters.

 

Since most tools don't support creating filters for DSD64/DSD128/DSD256 rates anyway, HQPlayer has capability to adapt filters for whatever rate is needed.

 

I would have thought that scaling down a 192 filter to convolve a 44.1 file would introduce sort of issues decimation and downsampling of a 96K recording into a 44.1 Redbook file do...

 

I intend to use Qobuz with 192 subscription and no intention to own 352.8 or 384 files : is 192 convolution filter enough or do I need to create 384 convolution filters for the Qobuz 192 files ? Does it matter if convolution filters are big (ie 1 Mo if 384 while 512K is enough with 192)?

[Miska]

8 minutes ago, Ozan Bolat said:

I would have thought that scaling down a 192 filter to convolve a 44.1 file would introduce sort of issues decimation and downsampling of a 96K recording into a 44.1 Redbook file do...

 

No it doesn't. And you are anyway dealing with a 44.1k file already.

 

8 minutes ago, Ozan Bolat said:

I intend to use Qobuz with 192 subscription and no intention to own 352.8 or 384 files : is 192 convolution filter enough or do I need to create 384 convolution filters for the Qobuz 192 files ? Does it matter if convolution filters are big (ie 1 Mo if 384 while 512K is enough with 192)?

 

If 192k is highest rate you use, then 192k filter is fine. 352.8k convolution filter is good for DSD sources though.

 

However, if you are using a tool like REW, it is better to use it's parametric EQ text file export instead of convolution filter. Because that way the whole process becomes much simpler and lighter (things like filter rate become totally irrelevant).

 

[Ozan Bolat]

10 minutes ago, Miska said:

 

No it doesn't. And you are anyway dealing with a 44.1k file already.

 

 

If 192k is highest rate you use, then 192k filter is fine. 352.8k convolution filter is good for DSD sources though.

 

However, if you are using a tool like REW, it is better to use it's parametric EQ text file export instead of convolution filter. Because that way the whole process becomes much simpler and lighter (things like filter rate become totally irrelevant).

 

thank you very interesting. From my readings I was under the impression that generating mono wav filters in RePhase was the best free option even if not applying any time domain correction, because of all the parameters (filter length , taps etc). So to make clear : if I don't want to correct time domain, I'm better off not using RePhase at all but only REW as you describe? or if I'm ready to fiddle with RePhase it's still worth it in order to produce better quality filters?

[Miska]

1 minute ago, Ozan Bolat said:

thank you very interesting. From my readings I was under the impression that generating mono wav filters in RePhase was the best free option even if not applying any time domain correction, because of all the parameters (filter length , taps etc). So to make clear : if I don't want to correct time domain, I'm better off not using RePhase at all but only REW as you describe? or if I'm ready to fiddle with RePhase it's still worth it in order to produce better quality filters?

 

I have not used RePhase, so I cannot say how close it is to REW when not using time domain correction. But I can say that when using REW alone, it is best to export it's EQ settings for "generic" EQ as text and then importing that into HQPlayer's matrix instead of convolution filter.

 

[GMG]

Side question. 
I believe Dirac applies both time and frequency corrections.

does that mean that if I loop back a sine impulse through a Dirac filter and capture the impulse response and then use this impulse response in a convolution engine (HQPlayer or Roon or any other) will I be loosing the time domain correction that Dirac applies or is all the information needed to reproduce the Dirac filter exist in the looped back impulse response I captured?

[Miska]

31 minutes ago, GMG said:

Side question. 
I believe Dirac applies both time and frequency corrections.

does that mean that if I loop back a sine impulse through a Dirac filter and capture the impulse response and then use this impulse response in a convolution engine (HQPlayer or Roon or any other) will I be loosing the time domain correction that Dirac applies or is all the information needed to reproduce the Dirac filter exist in the looped back impulse response I captured?

 

Yes, if you capture the impulse response, it will include both time and frequency domain corrections.

 

I think Dirac supports up to 192k these days? At that rate you'd cover most use cases already.