SoundFont appears to be corrupted

Bug #924687 reported by Mike Uchima
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
fluid-soundfont (Ubuntu)
In Progress
Undecided
Oskar Wallgren

Bug Description

The fluid-soundfont-gm SoundFont appears to contain corrupted data for the "Electric Guitar (muted)" instrument. Several notes in the octave starting at C2 (notes G thru A# in this octave) play the incorrect pitch. The pitch actually played is drastically off (more than a full octave higher than it should be). Other instruments appear not to be affected.

This issue has been observed on two different systems running the 10.04 LTS release. The same issue appears to exist in the versions of this package available for later Ubuntu releases as well.

Used Rosegarden and Qsynth/FluidSynth to reproduce.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: fluid-soundfont-gm 3.1-4
ProcVersionSignature: Ubuntu 2.6.32-38.83-generic 2.6.32.52+drm33.21
Uname: Linux 2.6.32-38-generic x86_64
NonfreeKernelModules: fglrx
Architecture: amd64
Date: Wed Feb 1 00:03:05 2012
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
PackageArchitecture: all
ProcEnviron:
 LANGUAGE=en_US:en
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: fluid-soundfont

Revision history for this message
Mike Uchima (uchima) wrote :
Revision history for this message
Oskar Wallgren (oskar.wallgren) wrote :

I tried the file FluidR3_GM.sf2
http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/fluid-soundfont/quantal/files

It's sound no. 28 Palm Muted Guitar that is acting up.
The keys G3 to A#3 seem to be transposed wrong.

I'll try and see if I can fix it.

Changed in fluid-soundfont (Ubuntu):
status: New → Confirmed
assignee: nobody → Oskar Wallgren (oskar.wallgren)
Revision history for this message
Oskar Wallgren (oskar.wallgren) wrote :

Ok. I have a fix for this. I'll try and see if I can work around having to upload 141MB for one single edit...

Changed in fluid-soundfont (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Toby Smithe (tsmithe) wrote :

Any progress?

If you do have a fix, and are able to upload it somehow, do you think you would also be able to look at bug 1268174?

Then I can organise a new upload, and fix all the bugs everywhere.

Cheers,

Toby

Changed in fluid-soundfont (Ubuntu):
assignee: Oskar Wallgren (oskar.wallgren) → Oskar Wallgren (oskar-wallgren13)
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.

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

Here is the same Palm Muted Guitar as a separate soundfont with the sample names intact (albeit one char too long if I've got this right).
http://www.freedrumkits.net/sound-fonts/guitars/764-palm-muted-guitar-soundfont

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

This really was countered for in fluidsynth as of revision 1.1.4
(Precise is 1.1.5)

fluid-dev bug report here:
http://lists.nongnu.org/archive/html/fluid-dev/2011-02/msg00045.html

From the fluidsynth 1.1.4 release notes:
Fix for bug with duplicate sample names in [SoundFont] files [jgreen]
http://sourceforge.net/p/fluidsynth/wiki/ChangeLog1_1_4/ <------- (r409)

The samples maybe should be fixed anyway?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.