Hey Garth, Am So., 19. Jan. 2020 um 18:11 Uhr schrieb Garth Hjelte <ga...@chickensys.com>: > 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 _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
