Room correction with convolution per sample rate

[digimuse]

I am switching from JRiver to MinimServer on a Melco.

I've used Acourate to generate FIR room correction filters for each sample rate (e.g., Cor1S44.wav, Cor1S48.wav, ..., Cor1S384.wav).

JRiver automatically selects the correct convolution file, once you set it up for 44.1 kHz (see Using a Config File).

The key point here is:
"Convolution filters are created at a specific sample rate which means they will only work correctly at only that sample rate."

I found a reference on how to set up convolutions with MinimStreamer (convolution with acourate fir filter).

Quote: A simple way to apply a FIR convolution file is to specify the following in stream.options:

convOut=-i f:\mark_gb\Cor1S44.wav -lavfi afir

Questions:

1. will MinimStreamer ONLY apply Cor1S44.wav to 44.1 kHz files (flac, wav, ....)?
2. how can I tell what transformations MinimStreamer is performing (in JRiver, you can check the Audio Path)?
3. can I specify separate convolution files files for each sample rate by specifying the following in stream.options:
   
   convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S44.wav -lavfi afir, convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S48.wav -lavfi afir, convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S88.wav -lavfi afir, convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S96.wav -lavfi afir, convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S176.wav -lavfi afir, convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S192.wav -lavfi afir, convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S352.wav -lavfi afir, convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S384.wav -lavfi afir
   

I have stored the convolution filter definitions in the directory "/mnt/disk1/share/MinimServer/convolution/"

PS: I had tried upsampling all my files to 384 kHz (stream.transcode: flac:wav24;384), and having a single entry in stream.options (convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S384.wav -lavfi afir), but Melco couldn't handle this, and had audio dropouts every few seconds

[simoncn]

1) If you have more than one convOut setting, only the last is used. It would be clearer for MinimStreamer to produce an error message in this case.

2) MinimStreamer doesn't support the ability to select between different convOut option strings based on the sample rate of the input file.

3) MinimStreamer doesn't parse the contents of the convOut option string. It passes the option string to ffmpeg "as is". This means it doesn't know what filter file is being used and therefore can't select between different filter files based on the sample rate of the input file.

4) MinimStreamer doesn't have any way for you to see the audio path (the list of transformations and the order they are applied). The convOut string is passed to the ffmpeg command before any transcoding options, so anything specified in convOut should (I think) be processed prior to transcoding. If this assumption is correct, it would mean you couldn't solve your use case by upsampling everything to 384 kHz and using a 384 kHz filter, because the filter would be applied before upsampling happens.

To support your use case, the simplest solution would be to change 2) above and support the equivalent of input type filters (see this section) for selecting between different convOut option strings based on the sample rate of the input file. This would only work correctly if convolution happens prior to upsampling. I don't have an easy way to test this. Would you be able to test the combination of convolution and upsampling to check whether this assumption is correct? If the assumption is correct, would this proposed solution meet your needs?

[digimuse]

Simon - thank you for your clarifications.

Quote:To support your use case, the simplest solution would be to change 2) above and support the equivalent of input type filters (see this section) for selecting between different convOut option strings based on the sample rate of the input file. This would only work correctly if convolution happens prior to upsampling. I don't have an easy way to test this. Would you be able to test the combination of convolution and upsampling to check whether this assumption is correct? If the assumption is correct, would this proposed solution meet your needs?

I am mainly interested in room correction (separate filters for each sample rate), and not upsampling.

I had considered upsampling as a way to only use a single convolution filter. I see that this will not work with MinimServer if convolution is done before upsampling (in JRiver upsampling is done before convolution).

I looked at the link (Input type filters). Isn't this only for stream.transcode options?
"The filtered transcoding settings are processed first and are checked for a match in the order that they appear in the stream.transcode property. "

I thought I need to specify convolution filters in stream.options (convolution with acourate fir filter).

Maybe you were considering extending "Input Filters" to stream.options? This should work for me, as I am not interested in upsampling. It should also be more efficient to only do a single convolution based on input filters, instead of upsampling everything to 384 kHz and then applying a 384 kHz convolution filter.

Perhaps you only want to consider doing this if MinimServer currently processes convolutions first and then upsamples. I'm not sure how I could test the order in which convolution and upsampling are done by MinimServer.

Test:
44.1 kHz source
stream.transcode: flac:wav24;384
stream.options: convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S384.wav -lavfi afir

If upsampling is done before convolution, this would be the correct result:
44.1 kHz -> upsampled to 384 kHz -> 384 kHz room correction

If convolution is done first, I'm not sure how "wrong" this should sound:
44.1 kHz -> 384 kHz room correction -> upsampled to 384 kHz

I'm not sure what other test I could do to compare with this to determine the order of convolution/upsampling.

[simoncn]

Your understanding of my proposal is correct. On a point of detail, the possible incorrect result if things happen in the wrong order would be

44.1 kHz -> upsampled to 384 kHz -> 44.1 kHz room correction

rather than

44.1 kHz -> 384 kHz room correction -> upsampled to 384 kHz

Although you don't want to do convolution and upsampling together, some other people will want to do this and I don't want to implement a solution that would produce incorrect results for these people.

Like you, I am not sure how "wrong" it would sound if a 44.1 kHz convolving filter were applied to a 384 kHz source. Also, I have no experience with convolving filters and I don't know how to create them or what effect I should expect them to have on the sound.

Perhaps someone else with experience in this area who does want to do convolving and upsampling together and has a good idea of how the result is intended to sound will offer to help with testing.

[digimuse]

I ran some tests with convolution filters and upsampling. I was trying to figure out the order of upsampling/convolution by analyzing the SPL. Unfortunately, the results are confusing.

When using JRiver as a server, enabling the Acourate room correction FIR filters results in an overall reduction in volume of 5 dB (using a Sound Level Meter). This is close to what was predicted by Acourate.

With MinimServer as a server (running on Melco): Playing the same 16/44.1 kHz FLAC test track for all the tests below:

Test 1: bit perfect
source: 16/44.1 kHz
stream.options: <blank>
stream.transcode: <blank>
SPL: 80 dB

Test 2: upsample all FLAC to 24/352 kHz
source: 16/44.1 kHz
stream.options: <blank>
stream.transcode: flac:wav24;352
SPL: 80 dB

This seems okay. DAC also shows 24/352 kHz data (so upsampling is working)

Test 3: apply 44.1 kHz convolution filter
source: 16/44.1 kHz
stream.options: convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S44.wav -lavfi afir
stream.transcode: <blank>
SPL: 80 dB

The convolution filter should have reduced the SPL to around 75 dB, yet it is unchanged at 80 dB?

Is the convolution a no-op? Or does ffmpeg "normalize" the output for "-lavfi afir" convolution?

Test 4: apply 44.1 kHz convolution filter and upsample all FLAC to 24/352 kHz
source:16/44.1 kHz
stream.options: convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S44.wav -lavfi afir
stream.transcode: flac:wav24;352
SPL: 58 dB!

This seems completely wrong. Would have expected SPL to be 75 dB (5 dB reduction), yet it is way off. DAC also shows 24/352 kHz data (so upsampling is working)

Test 5: apply 352 kHz convolution filter and upsample all FLAC to 24/352 kHz
source: 16/44.1 kHz
stream.options: convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S352.wav -lavfi afir
stream.transcode: flac:wav24;352
SPL: 58 dB!

Again, something is very wrong.


Analysis:

Case 1: If convolution is done before upsampling:

For Test 4: this should be the correct result - but the SPL is incorrect at 58 dB - so the premise is inconsistent
44.1 kHz source -> 44.1 kHz room correction -> upsampled to 352 kHz

For Test 5: this should be incorrect - and the SPL is incorrect - so the premise is consistent
44.1 kHz source -> 352 kHz room correction -> upsampled to 352 kHz

Case 2: If upsampling is done before convolution:

For Test 4: this should not be correct - and the SPL is incorrect at 58 dB - so the premise is consistent
44.1 kHz source -> upsampled to 352 kHz -> 44.1 kHz room correction

For Test 5: this should be correct - but the SPL is inconsistent at 58 dB - so the premise is inconsistent
44.1 kHz source -> upsampled to 352 kHz -> 352 kHz room correction

Could it be that you can't both upsample and convolve?


Note: in between all tests:

1. reset/restart MinimServer (twice with MinimWatch)

2. restart JRiver and re-import MinimServer library: 1) restart JRiver, 2) Library -> Import -> Run Auto-Import Now

I am using JRiver as the Control Point.

[simoncn]

Thanks for doing this testing. Can you post your 44.1 and 352.8 filter files so that I can try some experiments?

[Alandbush]

(29-11-2018 07:52)digimuse Wrote:  Test 3: apply 44.1 kHz convolution filter
source: 16/44.1 kHz
stream.options: convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S44.wav -lavfi afir
stream.transcode: <blank>
SPL: 80 dB

The convolution filter should have reduced the SPL to around 75 dB, yet it is unchanged at 80 dB?

Is the convolution a no-op? Or does ffmpeg "normalize" the output for "-lavfi afir" convolution?

I hesitate slightly in replying because Simon has already replied but not commented on Test3.

However, I would have thought the answer to Test3 is to be found in the Streaming options wording, extraction below.

“convOut A string containing additional output options to be passed to the stream converter program when performing transcoding.”

[simoncn]

Alan,
Thanks for picking up on this. It is indeed necessary to add flac:wav; (for FLAC files) or wav:wav (for WAV files) to stream.transcode. Note the semicolon at the end of flac:wav; which is required to force the use of FFmpeg rather than MinimStreamer's internal converter.

Simon

[digimuse]

Thanks for looking into this Simon:

I've uploaded all my convolution files to:
https://app.box.com/s/272tgj9lfdlrp6txt4c0uc111ubcfmij

Click on the "x" in the green box near the top with the text "Log in to box ...". Then click the "Download" button hidden below. This should download the file "MinimServer.zip". Inside you will find all the .wav convolution files.

[simoncn]

Thanks for this. I have repeated tests 1, 3 (with transcoding enabled to ensure the filter is applied) and 4. I used a hand-held SPL meter (dBA measurement, meter set to fast, measuring max SPL). The figures varied a bit but the results were consistent enough to convince me that what I am seeing represents real repeatable differences.

Test 1: approx 87.9 dBA
Test 3: approx 84.5 dBA
Test 4: approx 85.5 dBA

I also tried test 5 but the results were more variable in a range between 85.5 and 87.5 dBA. The wider variation suggests to me that this combination has problems.