Drawbar and Detuned Organs 1 and 2 are still one octave too low in MS Basic.sf3

[mkj42]

Issue type

General playback bug

Description with steps to reproduce

All electronic Hammond-style organs should be one octave below concert pitch, as they are in other GM soundfonts. Drawbar and Detuned Organs 1 and 2 as supplied in MuseScore are a further octave lower than that.

Supporting files, videos and screenshots

organ.zip

What is the latest version of MuseScore Studio where this issue is present?

4.3

Regression

No.

Operating system

Windows 10, but probably all

Additional context

I posted about this issue back in this post from 2021: https://musescore.org/en/node/326427 and commented in this 2017 thread as well: https://musescore.org/en/node/163756#comment-1104115

Harmonic analysis was performed. Proof was given, complete with screen grabs and how to reproduce.

This is still the case with the newest version of the soundfont included with 4.3. It should be an easy fix. Replace -24 with -12 in the transposition for the Drawbar Organ instrument in the soundfont (note: instrument, not preset or sample). Then re-save. I could do this easily if granted access to MS Basic.sf2 so there would be no quality loss.

Though one could, one shouldn't simply change instruments.xml, because then MuseScore would be wrong for correctly pitched soundfonts.

I should note: Workarounds are available. You can either edit the soundfont yourself (and lose sf3 sizing) or transpose within MuseScore, but the optimist in me wants it to be correct out-of-the-box.

Thanks

Checklist

• [X] This report follows the guidelines for reporting bugs and issues
• [X] I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
• [X] I have attached all requested files and information to this report
• [X] I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible

[mkj42]

I had looked into revising the instruments.xml file, but in our discussion at https://github.com/Jojo-Schmitz/MuseScore/issues/526 JoJo pointed out that MuseScore would then be wrong for correctly pitched soundfonts. So, it seems that MuseScore General and MS Basic and all derivatives are incorrect and would need fixing to make things right.

[mkj42]

It seems a pity, because all it would take is changing the transposition of the Drawbar Organ instrument (note: instrument, not sample or preset) in the soundfont from -24 to -12. The only trick is using original sources then saving it in sf3 to avoid quality loss.

Unrelated note: I just noticed Drawbar Organ goes through progressively heavier filtering as the dynamics get quieter. This is not how an organ behaves, folks.

[Jojo-Schmitz]

I have the sf2 versions of MuseScore General and MuseScore General HQ, version 0.2.1, 210 MB and 478MB, from Mu3

[mkj42]

Note: I updated 'additional context' section.

[mkj42]

I've already changed the transposition for 3.6.2 and 3.7 Evo on my personal Musescore General HQ.sf2. I need MS Basic.sf2 to get started on Mu 4.x. MS Basic.sf3 has 2194 samples; the former Musescore General HQ has 1246, so it seems much has changed.

[mkj42]

I thought I had solved it with Cognitone's sf2convert. Though it completes. the resulting sf3 will not load in Polyphone and only makes noise in MuseScore.

[mkj42]

Semi-success! Cognitone's sf2convert still failed even with reduced quality settings, but... I have sf3convert running in Linux Mint 21 and at least the Drawbar Organ sounds correct in MuseScore. FYI my first pass resulted in a 24 meg file, so some tweaking with the parameters is probably necessary.

[mkj42]

I now have an sf3 with correct Drawbar Organ instrument transposition based on MuseScore_General as included in 3.7 Evo.

Generated via sf2 with sf3convert, a 0, q 0.795 v0.2: 1246 Samples 204 Instruments 309 Presets 38970KB

If the soundfont folks care to include this in 4.x it's available. If I could get access to MS Basic.sf2, I could perform the same modification quickly.

[mrbumpy409]

Not long ago, I was the primary developer working on MuseScore_General. Once MuseScore began looking into acquiring the samples for what would become Muse Sounds, I was basically told my efforts were no longer needed. I wasn't sure what was going to happen with sounds in MuseScore, and nobody was really communicating plans with me. So I waited to see what would happen with MuseScore 4.

Once MuseScore 4 became available, I saw that the SoundFont had a new name. I didn't compare sounds to see what else might have changed, but the MS Basic_License.md file appears to be unmodified from version 0.2 of MuseScore_General. The latest MuseScore_General version I created is 0.2.1, so this would mean that MS Basic.sf3 does not include my fixes for #314547 and #324917 or the metronome sounds I added for users to be able to export audio containing the metronome (see issues #154666 and #320431), and a few other improvements.

I would be happy to implement bug fixes for MS Basic, but I have no idea who at MuseScore to even approach at this point as there has been so much changeover since I last worked with them. My latest update (version 0.2.1) went unimplemented, and I just haven't felt like there has been a green light for my continued work.

Regarding the organs, I can confirm the following instruments are not at the correct pitch compared to the GS standard set by Roland (bank:preset numbering):

• 000:016 Drawbar Organ: 8va too low
• 008:016 Detuned Organ 1: 8va too low
• 008:017 Detuned Organ 2: 8va too low
• 000:019 Church Organ: 8va too high

A proper fix for the church organ will involve editing the sample mapping at the instrument level (it is not as simple as using a -12 or +12 coarse tune, as this will not correctly re-map the samples). If there can be clear and understood development proceedings for the MS Basic SoundFont, I am happy to do this work. I can also remove any velocity-based filtering, as that should not be there either (there is some odd programming in a lot of the instruments inherited from Fluid R3).

[mrbumpy409]

Okay, I have fixed this issue in my current development version of MuseScore_General. Now to figure out how/if MuseScore might want to include these updates in a future version.

[mkj42]

@mrbumpy409

Thanks for the reply. I had no idea the soundfont crew at MuseScore was so unreachable. I had hoped you might know if anyone.

Thanks also for the heads-up on Church Organ; I need to look at that one. Please also consider checking out https://github.com/Jojo-Schmitz/MuseScore/issues/526, where we have pursued similar fixes for 3.7 Evo.

[cbjeukendrup]

I can't fully agree with the statement that we are unreachable; note that you've just reached out to us by commenting on this issue, and besides GitHub issues we have a Discord server as mentioned in the GitHub wiki, where many of us can be reached directly. But it is true that communication has not been very effective, especially before the release of 4.0. Fortunately, we're now in easier times, so things should be better by now.

@mrbumpy409 I will ask @bkunda and @RomanPudashkin to reply about this issue and the future of the sound font. (My personal opinion is that it would be awesome to have it maintained again; even though sound fonts might not be able to produce the same advanced playback as the more complicated MuseSampler tech, I see no reason for not welcoming improvements to the sound font as well.)

[mrbumpy409]

Thanks Casper! I would be more than happy to work with the MuseScore team on maintaining/improving MS Basic as needed.

[shoogle]

@mrbumpy409, we spoke before (via email) about your 0.2.1 version and the difficulties of storing SF2 / SF3 files in a Git repository.

You mentioned that you wanted to create an "SF2 compiler" that would take samples as FLAC and parameters as CSV, and spit out an SF2. Did you manage to get round to doing that?

If not, we might adopt a simpler solution of splitting the SF2 file on RIFF chunks, since the 466 MiB MuseScore General SF2 is too large to store in a Git repository (GitHub's limit is 100 MiB), and the lossy compressed SF3 is unsuitable as a source format.

[mrbumpy409]

@shoogle I would still like to code that SF2 compiler/decompiler some day, but I just haven't had the time to make it all happen. I also have my concerns about the workflow with such a solution. To make changes to a GitHub-hosted "decompiled" SoundFont, one would have to compile the source into a SoundFont, make edits, then decompile again to create a GitHub pull request. Hardly ideal, though future native support for a SoundFont "source" format in an editor such as Polyphone would make this idea a lot more appealing.

I wonder if having a separate GitHub page for the SoundFont, documentation, and issue tracking—with Google Drive links as releases/source SoundFont downloads—might be the best idea going forward.

[cbjeukendrup]

Polyphone is open source (https://github.com/davy7125/polyphone) so if you have time at some point, you could consider building this compile/decompile functionality into Polyphone. That would strongly increase the dependency on Polyphone, but would lead to a pretty smooth workflow, I think: store the sound font in a separate Git repo consisting of samples and CSV metadata files (or whatever format is convenient); then open this repo in Polyphone by opening some top-level metadata file; edit via Polyphone; and write back to the repository as samples+metadata. Compile to an SF2 or SF3 locally from Polyphone, to test it in MuseScore, but don't store the compiled sound font in the repo. Then push the changes to GitHub. Use a GitHub Actions workflow to compile the sound font on GitHub, and create a release with the compiled sound font as an attachment. In the MuseScore buildscripts, we download the soundfont attached to the latest release, and build it into MuseScore. Anyway, just daydreaming about a possible workflow. I can imagine that the compilation/decompilation may be time-consuming to implement. But perhaps parts of the Polyphone codebase can be useful for that.

[mrbumpy409]

Unfortunately, I don't know how to code in C++, and one of the reasons I haven't created this SoundFont compiler/decompiler yet is that I am only a fledgling with Python. I have written some tools for manipulating WAV files, so I have some experience working with RIFF file types, but a SoundFont is a much more complex beast. So, when I finally do get around to creating this system, it will take some time to develop as I will still be learning more advanced Python along the way. In the end, it's all come down to available time and how best to spend it.

[knoike]

I wonder if having a separate GitHub page for the SoundFont, documentation, and issue tracking—with Google Drive links as releases/source SoundFont downloads—might be the best idea going forward.

I vote +1 for this proposal. Because I think it will probably takes time to be available a practical SoundFont compiler/decompiler.

I think it would be better to develop SoundFont compiler/decompiler as a separate project.

[cbjeukendrup]

And even when we have the compiler/decompiler, I think it would still be preferable to keep the sound font in a separate repository, to keep the MuseScore repository light (or rather, to prevent it from getting even heavier, because since the 80MB sf3 was added and modified several times, it isn't quite light anymore, and because of Git won't ever be light again).

[mkj42]

Side problem: I think MS Basic.sf3 has new noise in it to start with. You can hear it plain as day in Polyphone, no MuseScore required. I had noise I blamed on new 4, but if you open MS Basic.sf3, and the last MS General in Polyphone, the additional noise on MS Basic is there. Synth Brass 4 just flat out sounds bad now.

[mrbumpy409]

Side problem: I think SF Basic.sf3 has new noise in it to start with. You can hear it plain as day in Polyphone, no MuseScore required. I had noise I blamed on new 4, but if you open MS Basic.sf3, and the last MS General in Polyphone, the additional noise on MS Basic is there. Synth Brass 4 just flat out sounds bad now.

Oh my goodness, you're right! Investigating MS Basic.sf3, I can see that it is based on the "HQ" version of the SoundFont, but the OGG quality settings they used must be pretty low to get the entire HQ SoundFont down to only 48.9 MB in size. Unfortunately, this also trashes the sound quality in some cases, such as the saw waves used to construct Synth Brass 4 and other synth sounds.

I had determined in my testing that going lower than OGG quality 0.8 would introduce observable artifacts into the sound, often around loop points. You can hear some of the MS Basic instruments now have clicking or buzzing loops that don't exist when converted using quality 0.8.

When converted using OGG quality 0.8, MuseScore_General_HQ ends up being 82 MB in size, but sounds considerably better.

[mkj42]

I certainly haven't compared all the sounds, but In MS4 everything sounds hotter now. I originally chalked that up to them re-doing how the dynamics were followed - mf is at least full-on f now on some sounds. Unfortunately that also ruins Brass Synth 4. It had a lovely wah at the beginning which is gone now - all buzzy. There's no denying the compression though, clipping and aliasing all over.

[Johan-v]

Hello, I tried something. (trying to get the best soundfont quality) I downloaded MuseScore_General_HQ.sf2 (MuseScore_General_HQ_0.2.1.7z) 466MB I renamed it to MS Basic.sf3 I replaced the original MS Basic.sf3 in MU4 with the renamed one above. It seems to work. Is this supposed to work or should I expect problems? This is with windows 11 4.3.2-241630831, revision: github-musescore-musescore-22b46f2 Kind regards, Johan

[Jojo-Schmitz]

You renamed a .SF2 into a .SF3? That seems to be asking for trouble

[mkj42]

I downloaded MuseScore_General_HQ.sf2 (MuseScore_General_HQ_0.2.1.7z) 466MB I renamed it to MS Basic.sf3 I replaced the original MS Basic.sf3 in MU4 with the renamed one above. It seems to work. Is this supposed to work or should I expect problems?

MS Basic absolutely has more samples than any previous MSGeneral, so I would say results are not guaranteed at all... though I did almost exactly what you did - loading in and renaming 3.7's non-HQ sf3 file. Results have so far been fine(ish), though I expect unforseen surprises. Who knows what they might be? A reply from someone directly involved would be helpful.

Speaking of... @cbjeukendrup Is there any chance someone could tell us here exactly how to recreate MS Basic.sf3? or steps to reproduce it from sf2 or better sources? I frankly haven't had the motivation to try to figure what the ~900 extra samples are or where they came from.

@mrbumpy409 MS4 is doing something different with the soundfonts, and I don't know what it is.

Example 1: Load synth brass 4 into both MS3.6.2+ and MS4.3+ 3 has a lovely soft attack and 4 just goes straight to buzzyness No amount of fiddling with the dynamics in 4 ever gets you 3's timbre, even when using 3.7's sf3(!)

Example 2: On the classical guitar listen to the open D string A click is being generated on the attack which is not in the soundfont

[mrbumpy409]

@mrbumpy409 MS4 is doing something different with the soundfonts, and I don't know what it is.

Example 1: Load synth brass 4 into both MS3.6.2+ and MS4.3+ 3 has a lovely soft attack and 4 just goes straight to buzzyness No amount of fiddling with the dynamics in 4 ever gets you 3's timbre, even when using 3.7's sf3(!)

Example 2: On the classical guitar listen to the open D string A click is being generated on the attack which is not in the soundfont

Oh! The SoundFont player in MuseScore 4 (is it even still FluidSynth?) appears to have the lowpass filter disabled! This completely ruins the timbre programming of the SoundFont and has a massive effect on all of the synth sounds. Acoustic instruments no longer get warmer at lower dynamics.

Wow. Between the aggressive compression and whatever they've done to the SoundFont playback engine, SoundFonts in MuseScore 4 can sound far, far worse than they should. I'll file (or locate) a bug report for this.

[mkj42]

Oh! The SoundFont player in MuseScore 4 (is it even still FluidSynth?) appears to have the lowpass filter disabled! Wow. Between the aggressive compression and whatever they've done to the SoundFont playback engine, SoundFonts in MuseScore 4 can sound far, far worse than they should. I'll file (or locate) a bug report for this.

Not a clue anymore, there is no equivalent View/Synthesizer, so there is no control over dynamic handling as well. I was considering starting an issue if I could come up with a gentle / constructive enough title. It does seem like MS Basic and MS4's handling of soundfonts is, well, bad. The cynic in me thinks this is done on purpose to make all users amazed at MuseSounds.

[mkj42]

I might consider bundling in this request for bringing back channel handling in the mixer:

https://musescore.org/en/node/366507 I don't even know if that is possible either.

[mrbumpy409]

I will be properly sleuthing all of this out, but I am also trying to get a major GeneralUser GS update (v2.0.0) out the door. Once that is done, I'll have more time to properly test and report MuseScore issues. Might be another week or two yet. Free time is hard to come by these days.

[MarcSabatella]

Regarding the lowpass filter, see https://github.com/musescore/MuseScore/issues/19859 for a little bit of context. I think there are also threads that could be followed from there for more insight.

For now, though, it is pretty safe to say that the removal of the filter was not done to intentionally sabotage MS Basic.

[fp22june]

Related to #20871 Some msbasic.sf3 sound samples are damaged

[shoogle]

I suspect the 'MS Basic.sf3' file was directly edited in Polyphone at some point, which would have caused further reduction in quality if the lossy Vorbis compression was applied a second time. Perhaps Polyphone wasn't clever enough to only recompress the changed samples (or none if only text parameters were changed). It probably assumes you'll only edit the uncompressed SF2, then convert to SF3 as a final step before publishing.

[mkj42]

I suspect the 'MS Basic.sf3' file was directly edited in Polyphone at some point

The file would be too big for Polyphone. At least the released version of Polyphone has a 127 preset max for exporting to sf3.