Comment 5 for bug 924687

Revision history for this message
Oskar Wallgren (oskar-wallgren13) wrote :

Sorry for the late response!

I'm trying to recreate the crash but am failing so far. It seem to work fine in the latest source.
As I remember it one sample were named wrong, but I don't actually hear it.
In Swami editor I see the problem however. Two samples are named the same
'PalmMuted Guitar Bb' have two instances and this is against the sf2 specifications. However. sf2 also suggests that any application loading an instrument with two samples having the same name, should rename the later instances 'on the fly'. So this may have been corrected in fluidsynth in the mean time. I'll check into this.

Basically what's wrong in the soundfont is that the original samples somewhere has dropped the last char since they were 20 signs long and the array can hold 19 ASCII signs plus /0.
CHAR achSampleName[20]; <-------------------------- 'PalmMuted Guitar Bb', last sign cut off!

A bit overkill perhaps but for the geek, the sf2 standard is here:
http://freepats.zenvoid.org/sf2/sfspec24.pdf
From here on text is quoted from the sf2 specification, page 28...

7.10 The SHDR Sub-chunk

struct sfSample
{
 CHAR achSampleName[20];
 DWORD dwStart;
 DWORD dwEnd;
 DWORD dwStartloop;
 DWORD dwEndloop;
 DWORD dwSampleRate;
 BYTE byOriginalPitch;
 CHAR chPitchCorrection;
 WORD wSampleLink;
 SFSampleLink sfSampleType;
};

The ASCII character field achSampleName contains the name of the sample expressed in ASCII, with unused terminal characters filled with zero valued bytes. Sample names are case-sensitive. A unique name should always be assigned to each sample in the SoundFont compatible bank to enable identification. However, if a bank is read containing the erroneous state of samples with identical names, the samples should not be discarded. They should either be preserved as read or preferably uniquely renamed.