Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[joergstumpp]

When I use JRiver Convolution with a simple Stereo 96K Filter as wave file,
it seem that the filter sampler rate is not recognized correctly.
The wav filter file seems to be  handled as a 44K1 filter being resampled to 96K when playing 96K files.
Opening the wav file in JRiver, JRiver shows the correct sample rate of 96000,64Bit.

The filter works correctly in ConvolverVST and in Foobar.

Using cfg files doesn not help.
I am using latest build of JRIver 20.
JRiver Convolution is configuered not to seach for filters based on the sample rate played.

Any Ideas or is this an error ?

Best regards Joerg

[mattkhan]

The wav filter file seems to be  handled as a 44K1 filter being resampled to 96K when playing 96K files.

how do you tell this is happening?

Using cfg files doesn not help.

what config file are you using (that does not work)? As far as I can tell, it works normally in my use using a cfg file.

[joergstumpp]

The wave filter file seems to be  handled as a 44K1 filter being re-sampled to 96K when playing 96K files.
how do you tell this is happening?

The audible result clearly shows  that the filter is not handled correctly. So I did some checks:

I played a 96K wave file containing a dirac-imp, did the convolution , recorded the result. The result should be the filter file itself.
When I do a FFT of the recorded result all freq are shifted. So what should be at 1KHz was at 0,46 KHz.

I used accourate to  calculate the 64Bit Wave Filter files for the different sample rates.

The test have been done using the wave files as filter files, no cfg files.
I tried to use a simple cfg named test.cfg file with the same results:


96000 2 2 0
0 0
0 0
filter96.wav
0
0.0
0.0
filter96.wav
1
1.0
1.0



Best regards Jörg

[mattkhan]

what was the output format set to in jriver?

[joergstumpp]

Output format was same as  source, ASIO of DAC said it was 96000 32Bit.

[mattkhan]

Output format was same as  source, ASIO of DAC said it was 96000 32Bit.

well I can't think of a reason either

perhaps you could make the files available somewhere? I could repeat your test locally and then we can see if it specific to your setup or not.

[joergstumpp]

Thanks for the help, i will try to do so. Cuurently i'm in office so it will take some time ..

It is already helpful to see that  it is intened to work that way, using 96000 stereo wave files as filters.

[joergstumpp]

you can download the filse ause at

https://owncloud02.iosb.fraunhofer.de/owncloud/public.php?service=files&t=792b1ac7094cefd9bb4ca13712c6ee77

The zip file cointains the following:

cor1xxx.wav are the filter files used by JRiver convolver ( different samle rates)
dirac96 ist the wav played to record the result of the convolution using the different filters.
It is a 96K wave file.

the files recorded_xxx   shows the recorded result of the convolution using filters at different samplerates. They are all 96K 64Bit wave filtes.
The FFT should be the same as the used filter files !

Only using the a filter file with  44K1sample rate gives the correct result. It is correctly upsampled to 96K  by convolver before using it.

All other filter files  a not correctly used ( detected ?) by convolver.

I used the files without a cfg file.

Best regard Joerg

[mattkhan]

I tried your files and get similarly incorrect results. Some pics of what I came up with, I've attached my zone config & the output of your dirac pulse convolved with the different filters via jriver. The output was captured via audacity recording in a 96k project and the input is taken from a loopback via my mixer app (rme fireface 800 with totalmixfx).

clearly only the 44.1kHz one is correct

[mattkhan]

I then verified via an offline convolution and got the following comparison. I presume the shifting is a result of the mismatch sample rate and so this is expected behaviour given there is no resampling here.

cli_96.png compares the offline convolution against the filter, the other pic compares the 3 offline convolutions against each other.

Commands used are of the following form

Code: [Select]

C:\Users\Matt\Downloads\stumpp>convolverCMD
Usage: convolverCMD nPartitions nTuningRigour fAttenuationDB config.txt|IR.wav i
nfile outfile
       nPartitions = 0 for overlap-save, or the number of partitions to be used
       nTuningRigour = 0-4 (Estimate|Measure|Patient|Exhaustive|Take 1 minute)
       fAttenuationDB = the attenuation to be applied in dB
       config.txt|IR.wav = a config text file specifying a single filter path
                           or a sound file to be used as a filter
       input and output sound files are, typically, .wav

C:\Users\Matt\Downloads\stumpp>convolverCMD 0 1 0 Cor1S96.wav dirac96k.wav dirac
_to_96.wav
Using overlap-save convolution
Input file format: Stereo WAV (Microsoft) 96kHz 1429504 frames
Filter format: 2 Paths (Stereo to Stereo direct) 96kHz 131072 taps Lag: 65536 ta
ps 0.68s Estimated gain: 6.9dB Peak gain: 19dB
Optimum attenuation: -12dB calculated in 0.128s
Using attenuation of 0dB (ie, scaling factor of 1)
Convolved and wrote 1572864 frames to dirac_to_96.wav in 0.129s (ie, at 1.3e+002
 times real time)

C:\Users\Matt\Downloads\stumpp>convolverCMD 0 1 0 Cor1S44.wav dirac96k.wav dirac
_to_441.wav
Using overlap-save convolution
Input file format: Stereo WAV (Microsoft) 96kHz 1429504 frames
Filter format: 2 Paths (Stereo to Stereo direct) 44.1kHz 131072 taps Lag: 65536
taps 1.5s Estimated gain: 1dB Peak gain: 18dB
Warning: Filter format and Input file have different sample rates
Optimum attenuation: -6.7dB calculated in 0.127s
Using attenuation of 0dB (ie, scaling factor of 1)
Convolved and wrote 1572864 frames to dirac_to_441.wav in 0.145s (ie, at 1.1e+00
2 times real time)

If I get time then I will try to recreate this independently using my own filters.

[mattkhan]

as an aside, what sort of system are you correcting here? you seem to have a lot going on between 2-19Hz for example.

[mattkhan]

I repeated using my own (acourate generated) correction filters, same jriver setup as shown in previous pics and same method (looping back through the rme driver).

myfilter_48.png = result of applying my 48k filter to your dirac pulse
myfilter_96.png = result of applying my 96k filter to your dirac pulse

Both of these look normal to me.

I then compared them against the actual filter, there were some discrepancies at low frequencies so I zoomed in.

Cor96_vs_48 = 48k shows v minimal difference to the filter but does seem a bit sharper
Cor96_vs_96 = quite a difference at low frequency, seems to turn it into a much coarser filter

I don't know whether this is an expected artefact of the resampling that jriver must do or not (or an artefact of something else).

The conclusion I draw from this is that there is something specific about your filter that jriver doesn't like.

[mattkhan]

I realised one difference is that your filter is a full range filter so I went back and regenerated without the XO in place, again v little difference apart from at the lowest frequencies. Take with the caveat that my measurements only went down to 10Hz so I can't 100% accurately recreate your setup (correction appearing to extend down to DC).

[joergstumpp]

Thanks for the investigations.

So Ulli found that my measurment was not correct using a full scale dirac impuls, which resulted in clipping during measurment.

My filters are not normalized to 0db.

I doubt if doing the measurment using a -40dbfs dirac will give correct results.
It seems that JRiver does not like the gain of my filters.

I will show the results of my new tests here.

Thanks

[joergstumpp]

The results of my latest test can be found at

https://owncloud02.iosb.fraunhofer.de/owncloud/public.php?service=files&t=ea35ca35ec96cabd4cd369921813378a

The test show the convolution results playing a -40dfs dirac at 96000 sample rate using different wav file filters.

JRiver Convolver is  definitly doing the convolution not correctly. This is the case using the wav filters directly and  using a cfg file.

When I use a filte normalized to 0dBFs everthing works fine.

JRiver is not able to handle filters with inherent gain !!!