Documenting and possibly extending the SF3 format

• Jan 21, 2020 - 07:07

Hi all,

you are probably aware that the SF3 format you created for MuseScore has been adopted by quite a few other software packages. The software that I know of are: Carla, FluidSynth, LMMS, Polyphone, Qsynth, Qtracktor, ... but there are probably even more now.

We at FluidSynth have recently got a request to also support "SF4", which seems to be yet another non-standard SF2 variant that uses FLAC instead of OGG/Vorbis for compression:
https://github.com/FluidSynth/fluidsynth/issues/605

We are generally open and positive about this request (even if only two users expressed an interest in it so far), but feel like there is no need to call this "SF4" as it's really just another compression algorithm which could simply be incorporated to SF3 with an additional sample type flag. And there is the danger of SF2 fragmenting into more and more non-standard variants, of course.

There is an ongoing discussion about this on the fluid-dev mailing list that might be of interest:
https://lists.nongnu.org/archive/html/fluid-dev/2020-01/msg00001.html

So I wanted to ask what you as the creators of SF3 think about an "official unofficial" specification for SF3. Something that the software packages that already support SF3 can check their implementation against and that people can point to in bug reports if SF3 loading/writing does not work as expected across different software. Maybe create this in the sf3convert tool repo, or more independent from MuseScore? And if we had this kind of documentation, we could also use it to define new sample type flags for additional compression algorithms.

Cheers
Marcus


Comments

Hello!

Sorry, I missed your message before. Actually SF3 format was developed (as far as I know) by Werner Schweer who is not actively developing MuseScore anymore. So right now we probably won't know much more about SF3 format than its other users and can mostly rely on its current implementation. Still I believe that some kind of standardization of this format would be useful, and if other projects find it useful as well I believe we could collaborate with the interested projects to create a specification for the format and extend it if necessary. If this helps we could indeed base it on the existing sf3convert tool repo.

As for the name of the FLAC-compressed sound font format, an important difference between such format and OGG-compressed SF3 is that the former doesn't lead to quality loss so it might happen to be better to name it differently to make this distinction more clear. Apart from that I see no other reasons not to incorporate FLAC compression support into SF3 format.

Thanks,
Dmitri

Do you still have an unanswered question? Please log in first to post your question.