Room correction with convolution per sample rate

[digimuse]

Alan, thanks for the correction. My introduction to convolution was the post (convolution with acourate fir filter). An error message would be helpful if stream.transcode is blank and stream.options has convOut ...

From my earlier tests:

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

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

Now I realize that this should do nothing, because of the blank stream.transcode

I ran a few additional tests:

Test 6: convert FLAC to WAV (no sample rate change)
source: 16/44.1 kHz
stream.options: <blank>
stream.transcode: flac:wav;
SPL: 80 dB

Unchanged SPL is ok, as only transcoding FLAC to WAV.

Test 3-1: convert FLAC to WAV and 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: flac:wav;
SPL: 60 dB

Something wrong here with 20 dB volume reduction.

My only valid tests of convolution are: Test 3-1, and from my previous email Test4 and Test 5.

All of these tests have a roughly 20 dB reduction in volume (for me), which is not right.

Simon repeated Tests 3 and only got a reduction of 3.5 dB, which is very different from the 20 dB reduction I got.

My setup must be different.

I installed ffmpeg using the instructions at:
Installing MinimServer on a Melco N1

If you have installed MinimStreamer and you want to use FFmpeg as a stream converter, you can copy an ffmpeg static binary into the ahare/MinimServer/opt/bin folder and restart MinimServer by powering the N1 off and on. [NEW] You can download a suitable ffmpeg static binary from this page. For the Melco N1, you need the armhf build.

I'm also using JRiver as a control point, which should not be a problem (JRiver is not doing any processing - it's just instructing MinimServer running on Melco to send audio to my DAC directly over the network).

MinimServer is using ffmpeg for convolution, but JRiver is using its own engine(Native JRiver 64bit fp convolution ...), which works for me (when I use JRiver as the server).

[simoncn]

(30-11-2018 01:02)digimuse Wrote:  Alan, thanks for the correction. My introduction to convolution was the post (convolution with acourate fir filter). An error message would be helpful if stream.transcode is blank and stream.options has convOut ...

A forum post doesn't always include full instructions but might assume some prior context. This combination is not an error and it would not be appropriate to produce an error message.

Quote:Test 3-1: convert FLAC to WAV and 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: flac:wav;
SPL: 60 dB

Something wrong here with 20 dB volume reduction.

I have reproduced this problem by changing from FFmpeg 3.4.x to 4.1. My previous results were with 3.4.x. I don't yet know what has changed or why.

[simoncn]

Looking through the FFmpeg commit history, it sees likely that the change in SPL in the current version of FFmpeg is caused by this commit. I don't have enough knowledge of this area to be able to understand the purpose or effect of the changed code.

Can you explain how you created the filter file and why you think the SPL reduction should be 5 dB?

[digimuse]

I was able to get similar results to yours by switching from ffmpeg 4.1 to 3.4.2 (even version 4.0.3 resulted in a severe volume reduction).

I created the FIR filter files using Acourate. Details of the procedure to generate the filters can be found at:Acourate Digital Room and Loudspeaker Correction Software Walkthrough.

When generating the correction filter, Acourate reports the "Correction filter gain ratio approx: -x.y". For example, in the link above, look at the figure below "Run macro 4" (which shows -8.9).

For me, Acourate reported an expected gain ratio of -3.78 dB.

I loaded all the correction filters in JRiver MC, and played a 1 kHz warble test tone from Editor's Choice: Stereophile's Sampler & Test CD.

In JRiver it is possible to turn the FIR convolution filters on/off with a check-box in the DSP Studio. I compared the SPL of the 1 kHz warble tone with/without the filter, and it was approximately 5 dB.

I brought this up with the developer of Acourate, Dr. Ulrich Brüggemann, who thought the difference was not material. It could have to do with level normalization in JRiver (e.g., Re: Native JRiver 64bit fp convolution engine for Room Correction (FIR filters)?).

[simoncn]

In FFmpeg 4.1, the afir filter has some settings for applying different gain computations (see this section). The default is gtype=peak. If you specify gtype=gn instead, you should get something close to JRiver. The syntax for specifying this is:

convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S44.wav -lavfi afir=gtype=gn

Another possibility is to use gtype=none. This seems (for me) to produce results similar to gtype=gn.

[simoncn]

By looking at the verbose output from FFmpeg, I have confirmed that upsampling takes place after filtering.

A simpler alternative to specifying a different convOut string for each sample rate would be to add support for substitution parameters in the convOut string, as follows:

#samplerate# would be replaced with the sample rate of the input file (44, 352, etc.)
#samplebits# would be replaced with the sample bit depth of the input file (16, 24, etc.)

Other values could be added later if required (for example, #outsamplerate# or #outsamplebits#).

With this support, you could use a stream.options setting of

convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S#samplerate#.wav -lavfi afir=gtype=gn

to handle files with all sample rates.

[digimuse]

Simon - thanks for researching ffmpeg and figuring out what is going on.

Quote:In FFmpeg 4.1, the afir filter has some settings for applying different gain computations (see this section). The default is gtype=peak. If you specify gtype=gn instead, you should get something close to JRiver. The syntax for specifying this is:

convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S44.wav -lavfi afir=gtype=gn

I switched back to ffmpeg 4.1 with your suggested stream.options:
convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S44.wav -lavfi afir=gtype=gn

The output volume is now only attenuated by about 3.3 dB (83.2 dB with stream.options and stream.transcode <blank>, vs 79.9 dB with stream.options as above and stream.transcode "flac:wav;").

Quote:A simpler alternative to specifying a different convOut string for each sample rate would be to add support for substitution parameters in the convOut string, as follows:

#samplerate# would be replaced with the sample rate of the input file (44, 352, etc.)
#samplebits# would be replaced with the sample bit depth of the input file (16, 24, etc.)

Other values could be added later if required (for example, #outsamplerate# or #outsamplebits#).

With this support, you could use a stream.options setting of

convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S#samplerate#.wav -lavfi afir=gtype=gn

I think this would work fine. It also has the advantage that you aren't forced to upsample and use a single higher sampling rate convolution filter (stream.transcode could be "flac:wav;" with your proposal).

As a comparison, JRiver, can handle arbitrary FIR file names - and resample a filter on the fly to match different sample rates (e.g., see Automatic Resampling). It's tricky, though, to do this right (e.g., this).

The "better" approach is to have separate convolution filters per sample rate, just as you propose. JRiver uses "standard" config files. See Config file, and Config examples. Having defined a configuration file for one sample rate e.g.., "Name2.0_441.cfg", JRiver will automatically search for " Name2.0_48.cfg" for 48 kHz sample rates (similarly for other sample rates).

Your suggestion is simpler - not worrying about config files (without the complexity/flexibility to define input/output channels, channel mapping, delays, ...).

[simoncn]

Unfortunately there is a problem with my proposal for adding support for a setting such as

convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S#samplerate#.wav -lavfi afir=gtype=gn

The problem is that MinimStreamer currently verifies the convOut setting when the stream.options property is configured. It does this by making a test invocation of ffmpeg with the convOut string and dummy input and output streams. If the convOut string uses substitution values from the audio properties of the input file, this test invocation doesn't work because there is no input file to provide the substitution values.

At the time of making the test invocation, the range of actual sample rate values for potential input files isn't known, so attempting to guess a sample-rate substitution value or values for the test invocation could result in a false positive or false negative.

I will give this some further thought.

[digimuse]

I see that one of your goals with MinimServer/Streamer is to catch configuration errors as early as possible.

In this case, when you see a stream.options of the form:
convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S#samplerate#.wav -lavfi afir=gtype=gn

You can test if there are any files that match "Cor1S#samplerate#.wav" in the directory:
/mnt/disk1/share/MinimServer/convolution/

If none, then error.

Else, test one (or all) of the files matching the pattern "Cor1S#samplerate#.wav" at the above directory with dummy input files with the same sample rate. You will need dummy files for sample rates: 44.1 kHz, 48 kHz, 88 kHz, ...., 384 kHz. You might need "n" copies of these for "n" different bit-depths (you mentioned #samplebits# could be another pattern option).

If one (or any) of these tests fail, report an error.

It's always possible that the user has a file at sample rate "x", but there is no FIR filter for sample rate "x" in the specified directory. Not much you can do about this. It seems unreasonable to require convolution filters for all sample/bit rates (but that is the only solution if you allow wildcard patterns, and want to ensure there can be no errors).

[simoncn]

Thanks for this suggestion. My proposed solution is similar but not exactly the same.

The user syntax would be

convOut=-i /mnt/disk1/share/MinimServer/convolution/Cor1S*.wav -lavfi afir=gtype=gn

Step 1 (configuration)

MinimStreamer searches for all convolution files matching the wildcard and reads their contents to check the sample rate. If more than one matching file has the same sample rate, this is reported as an error. Otherwise, MinimStreamer does a test invocation of ffmpeg using the convolution file with the lowest sample rate and dummy input with the same sample rate. The main purpose of the test invocation is to verify that the user's version of ffmpeg can support these convOut options, so a single test invocation is sufficient for this.

Step 2 (transcoding)

When a file is transcoded using ffmpeg, the convolution file from step 1 that has the same sample rate as the input file is selected automatically and used on the ffmpeg command. This doesn't depend on the name of the convolution file but on its contents. If none of the convolution files from step 1 has the same sample rate as the input file, the streaming request is rejected and an error is reported in the MinimServer log.