Re: SF2 on bionic fails audio test

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Fri, May 25, 2018 at 12:08:30PM +0200, Tim Janik wrote:
> I've added ubuntu 18.04 (bionic) to beast's travis-ci build matrix and it fails
> b/c of a sf2 similarity mismatch:
>
>       https://travis-ci.org/tim-janik/beast/jobs/383605840
>
> This can also be reproduced in docker, just run:
>
>       misc/dockerbuild.sh ubuntu:bionic gccbuild
>
> Can you please look into that and make a suggestion how to resolve the issue?

Ok, I've now compared the old (16.04) and new (18.04) soundfont-test.wav files.
They appear to be perfectly identical in shape, but the 16.04 version is about
2.5% louder.

This is also consistent with the 18.04 error message:

af-tests/soundfont-test.ref: similarities: end_time=99.98%, spectrum=100.00%, avg_spectrum=100.00%, 
avg_energy=99.06%, end_time=99.98%, spectrum=100.00%, avg_spectrum=100.00%, avg_energy=99.05%
af-tests/soundfont-test.ref: average similarity rating (similarity below threshold): 99.757%

Features that judge the sound quality (end_time, spectrum, avg_spectrum) are
near 100%, where as the feature that checks the amplitude (avg_energy) is
nowhere near 100%.

I assume the fluidsynth dsp code was updated in some way. It is really
unproblematic, since for all practical use cases, soundfonts will be usable,
just about 2.5% less loud starting with 18.04. This means, I don't believe that
our own code is in any way buggy or wrong.

I think we should update the ref file to the new volume (as the new fluidsynth
should be our standard) and move on.

Just as to not break 16.04 audio tests, I suggest that we lower the comparision
threshold to 99.7% for old fluidsynth versions. A configure check should be
added, like

if pkg-config --modversion fluidsynth < 1.1.9
  FLUID_THRESHOLD=99.7%  # before 18.04
else
  FLUID_THRESHOLD=99.99% # 18.04 and later
fi

If you think I should do it this way and produce a pull request, let me know.

   Cu ... Stefan

PS: I noticed that our audio tests would be a tiny bit more exact if we
wouldn't quantize beast output down to 16-bit wav files during the test. Either
we could use 24-bit wav files, or somehow preserve the full float precision.

Its not a big problem though.
-- 
Stefan Westerfeld, http://space.twc.de/~stefan