use of envelope delay phase in SoundFont causes bizarre playback behavior

• Jun 29, 2019 - 07:15
Reported version
3.2
Priority
P2 - Medium
Type
Functional
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
Yes
Project

Description

The volume envelope delay phase appears to be broken in Fluid (MuseScore's Fluidsynth implementation), causing very strange playback anomalies whenever it is used.

Tests & Reproduction

The attached ZIP file contains two test projects demonstrating this behavior:

Test #1: volume_envelope_delay_test_01.mscz

This test contains chimes and drumset staves using sounds from MuseScore_General.sf3 (make sure this SoundFont is loaded). The chimes staff is set to the "Church Bell" preset, which uses the volume envelope delay phase to create a quieter, delayed bell strike one second after the initial note has sounded. The drumset staff exists solely to provide a steady rhythm.

When playing test #1, the following anomalies occur:

  1. The secondary, delayed strike for each note occurs at weird timings.
  2. The drum rhythm is all wonky, frequently skipping and/or lagging beats.
  3. Occasionally, playback will speed up considerably and the sound will be garbled. On my system, this happens particularly during measures 13-24 where the chimes' note pattern changes.

Test #2: volume_envelope_delay_test_02.mscz

For the second test, I created an instrument that plays six short saw tones with decreasing volume at a rate of two tones per second. These tones (except for the first) are delayed using the volume envelope delay phase. This test features two parts:

  1. Measure 1: this plays a reference recording so you can hear how the instrument is supposed to sound.
  2. Measures 2-5: this is where MuseScore plays the instrument sound. Measure 2 should sound identical to the reference measure (1), and measures 3-5 should sound the same, but on higher notes.

NOTE: Be sure to load the accompanying SoundFont for this test by choosing "Load from Score" in the synthesizer settings.

When playing test #2, the following anomalies occur:

  1. Measure 2: the initial note C plays, but none of its note delays are played.
  2. Measure 3: the initial note D plays, and some or all of the note delays from note C are finally played, a measure late and with a volume decay that is too long.
  3. Measure 4: the initial note E doesn't play right away, but instead after a short delay. The note delays for note D are also played, and as before, they are a measure late with the wrong decay values.
  4. Measure 5: same pattern as measure 4, except that the initial note F is delayed even further.

Diagnosis

It would appear some bad math/logic might be happening in the synthesizer delay phase.

Workaround

The workaround for this in the meantime is to avoid using presets that use the volume envelope delay phase. This includes the following presets in the MuseScore_General SoundFont, and possibly others:

  • 000:016 Drawbar Organ
  • 000:122 Sea Shore
  • 008:014 Church Bell
  • 008:030 Feedback Guitar
Attachment Size
volume_envelope_delay_tests.zip 221.62 KB

Comments

I tried to work around this issue by removing the use of the delay phase from the following instruments:

  • "000:016 Drawbar Organ"
  • "000:122 Sea Shore"
  • "008:014 Church Bell" - this is the only instrument that sounds significantly different without the delay phase
  • "008:016 Detuned Organ 1"
  • "008:017 Detuned Organ 2"
  • "008:030 Feedback Guitar"
  • "017:016 Drawbar Organ Expr."
  • "018:016 Detuned Org. 1 Expr."
  • "018:017 Detuned Org. 2 Expr."

This change has been made in version 0.1.9 of the SoundFont. You can get the HQ version of the SoundFont here.

Status active fixed

Let's mark it fixed then, even without knowing when this will make it into the MuseScore package or when the HQ Extensions gets updated with this

But I suppose the real fix would be to fix it in our Fluid fork / adopt Fluid upstream code? Sound font change looks more like a workaround indeed.

Status fixed active
Priority P2 - Medium

I guess it would be better to keep the issue active, it is about the synthesizer implementation rather than the soundfont.