use of envelope delay phase in SoundFont causes bizarre playback behavior
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:
- The secondary, delayed strike for each note occurs at weird timings.
- The drum rhythm is all wonky, frequently skipping and/or lagging beats.
- 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:
- Measure 1: this plays a reference recording so you can hear how the instrument is supposed to sound.
- 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:
- Measure 2: the initial note C plays, but none of its note delays are played.
- 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.
- 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.
- 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
This might explain: Problem with the "Sea Shore" sound in MuseScore_General.sf3.
I tried to work around this issue by removing the use of the delay phase from the following instruments:
This change has been made in version 0.1.9 of the SoundFont. You can get the HQ version of the SoundFont here.
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.
I guess it would be better to keep the issue active, it is about the synthesizer implementation rather than the soundfont.
True, I missed that part
In reply to I guess it would be better… by dmitrio95
Yes. This issue still affects other SoundFonts. It would be nice to have it properly fixed.
Should be fixed in version 1.9 of the MuseScore General soundfonts, but that version hasn't yet made it into MuseScore, so marking it "PR created", and hope that the version 0.2 makes it into MuseScore 3.5
Relates to #305424: [EPIC] MuseScore General (HQ) Soundfont issues
Automatically closed -- issue fixed for 2 weeks with no activity.