-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Drawbar and Detuned Organs 1 and 2 are still one octave too low in MS Basic.sf3 #23659
Comments
I had looked into revising the instruments.xml file, |
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. Unrelated note: |
I have the sf2 versions of MuseScore General and MuseScore General HQ, version 0.2.1, 210 MB and 478MB, from Mu3 |
This comment was marked as resolved.
This comment was marked as resolved.
I've already changed the transposition for 3.6.2 and 3.7 Evo on my personal Musescore General HQ.sf2. |
I thought I had solved it with Cognitone's sf2convert. |
Semi-success! |
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 If the soundfont folks care to include this in 4.x it's available. |
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 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):
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). |
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. |
Thanks for the reply. Thanks also for the heads-up on Church Organ; I need to look at that one. |
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. @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.) |
Thanks Casper! I would be more than happy to work with the MuseScore team on maintaining/improving MS Basic as needed. |
@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. |
@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. |
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. |
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. |
I vote +1 for this proposal. I think it would be better to develop SoundFont compiler/decompiler as a separate project. |
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). |
Side problem: |
Oh my goodness, you're right! Investigating 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. |
I certainly haven't compared all the sounds, but In MS4 everything sounds hotter now. |
Hello, |
You renamed a .SF2 into a .SF3? |
MS Basic absolutely has more samples than any previous MSGeneral, so I would say results are not guaranteed at all... Speaking of... @mrbumpy409 Example 1: Example 2: |
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. |
Not a clue anymore, there is no equivalent View/Synthesizer, so there is no control over dynamic handling as well. |
I might consider bundling in this request for bringing back channel handling in the mixer: https://musescore.org/en/node/366507 |
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. |
Regarding the lowpass filter, see #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. |
Related to #20871 Some msbasic.sf3 sound samples are damaged |
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. |
The file would be too big for Polyphone. |
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
The text was updated successfully, but these errors were encountered: