Re: [fluid-dev] Support for SF4 (FLAC) format?

[Marcus Weseloh]

Hey Garth,

Am So., 19. Jan. 2020 um 18:11 Uhr schrieb Garth Hjelte <address@hidden>:
> Can I ask why are smaller SoundFonts are even a need in this day of age? I 
> mean, it's NICE to compress data, but isn't this a whole lot of worry and 
> work for minimal - even useless - benefit?

Well, my use-case is to reduce the loading time of soundfonts stored
on an SD-card in an electronic musical instrument. Currently I'm still
using uncompressed samples, because I don't like the idea of lossy
compression. But the lossless FLAC compression might be interesting.
Whether it actually has any benefit with regard to loading times
remains to be seen. But I'm fairly certain that the loading time on my
embedded system is disk-bound, not CPU-bound.

> The other observation I have is that PLEASE if anyone is going to fiddle with 
> the SoundFont format and make some unofficial v3 or v4, administrate it with 
> lots of authority and a heavy hand. And it seems to me that having to have a 
> v4 just means that v3 was done half-baked.

Yes, I was thinking the same thing. As far as I know, the SF3 format
has no specs and no documentation. There are only a few posts in the
MuseScore forum and the implementation in MuseScores sfconvert tool
and now Polyphone and fluidsynth.

But then again, the only change that SF3 brought was the addition of
OGG/Vorbis compressed samples, an additional sample type enum value to
indicate that and the decision to use sample-local start,end and loop
markers for those samples. So I think we should definitely document
the SF3 format as it is currently used and implemented, maybe via a
dedicated github repo/wiki. Maybe even get all interested parties to
join the conversation and agree about the implementation, most
importantly Polyphone, MuseScore, Swami, Qsynth, the various
fluidsynth-as-daw-plugin authors, ... and possibly more that I have
missed.

And I definitely agree with Tom: there is no need for an "SF4" format.
SF3 adds the ability to use compressed samples. What encoder is used
to do the compression can be expressed with the sample type flag.

> One of the great things about the SoundFont spec/format is that a parser can 
> accept or reject opcodes it either doesn't understand or aren't written 
> correctly, thus allowing addition of features without breaking current 
> loaders ability to load them.

Assuming the soundfont loader is written well and checks the sample
type flag, SF3 with different compression algorithms will fit right
in. If a loader does not support a particular compression type, it can
simply ignore those samples.

Cheers
Marcus