Re: [fluid-dev] same-named samples in soundfonts in 1.1.3

[Element Green]

Hello,

Although I do plan to add libInstPatch support to FluidSynth, I think it likely makes sense to leave the old loader as well, for a standalone option.

As per the SoundFont spec, samples should not have identical names, but FluidSynth's handling of this definitely seems wrong.  Line 1411 in fluid_defsfont.c does look like the offending code.  The original SoundFont loader was taken from my ancient Smurf SoundFont Editor code base.  The part where things are going wrong in this regard is the routine that imports those structures into the FluidSynth specific ones.  

I've committed a fix for this to SVN (rev 409).  It seems that the defsfont loader isn't directly exposed to the public API, so I took the liberty of adding a fluid_sample field to SFSample for doing a proper fixup of samples when doing the import and removed the no longer used fluid_defsfont_get_sample() function.

Please let me know if this fixes your problem or not.

Best regards,

Element

On Sun, Feb 27, 2011 at 1:25 AM, David Henningsson <address@hidden> wrote:

On 2011-02-23 23:01, Krzysztof Foltman wrote:

Hey all,

I've found an odd property of Fluidsynth's soundfont loader. It wouldn't
be a big deal, but it gives some trouble when using soundfonts created
using some tools (like Lear Jeff's Nerd Soundfont Tools), and may be
hard to diagnose at first.

The problem occurs when the soundfont file has more than one sample with
the same name. In such cases, it seems to ignore the distinction between
those samples. In case of soundfonts created using jsftools, the samples
for the left channel and the right channel have the same name.

SWAMI and other tools seem to deal with it just fine - but when I try to
use Fluidsynth directly, using its own SF2 loader(?) instead of SWAMI's,
I get mono sound, because a single sample (left channel, for instance)
is used for both sample references in an instrument.

Just for a test, I've created a soundfont with all samples having the
same name - loads and plays fine in SWAMI, but not using command-line
Fluidsynth program, where again only one sample is used instead of many
different samples.

I haven't been trying too hard to find where the problem actually is,
but at least in one place the sample to use in the zone is resolved via
name (fluid_defsfont.c line 1411). If that's where the problem is, I may
try to fix it myself, but maybe someone's been thinking about the best
way to do it before?

(Of course, the simplest workaround for new soundfonts is to guarantee
that sample names are unique, and that's what I'm doing now - but it
doesn't help when using other people's unmodified soundfonts)

Thanks for your bug report. I believe Josh/Element Green had some thoughts of FluidSynth actually using the libInstPatch loader (used in SWAMI) instead of FluidSynth's current loader.

I don't know if that will happen in the near future though, so I'm happy to accept patches that fixes the current issues.

// David