Is .sfz support something devs consider also thank you for the library

[ghost]

First this is great 'lil library. I used it in my custom build of Godot, Goblin Engine to implement a fully functional MidiPlayer which not only plays songs but can also plays notes.

Now I am wonderinf if sfz is something worth considering even? I know that sfz is compressed with sfark. Would it be complicated to unpack a sfz into a sf2 in memory?

[schellingb]

SFZ is a completely different format than SF2 and not related to sfark as far as I know.

While SFZ seems to aim to replace SF2, in my opinion it is an awful format that is completely misdesigned. It relies on having a file system and hundreds or thousands of files scattered around in many directories. The samples all are encoded separately and the specs say samples can be "wav" or "ogg" without specifying if the wav files can be compressed or not. On top of that the few SFZ files I looked at also contain "aif" files... Then there are the .sfz files themselves (which a font consists of multiples) which a stated benefit for it is to be editable with a text editor, which just is about the dumbest idea ever. Making a soundfont with intricate parameters without having a tool that can preview the font while editing is an insanely dumb proposal. Especially when free SF2 tools like Viena exist. It also isn't meant to cover general midi which immediately makes it lose all its appeal for many if not most users.

sfArk is a proprietary file format so it cannot be supported. Though it just seems some old lossless compression on top of SF2 so it isn't very interesting. Something like it could easily added to a program that uses TSF by passing a custom tsf_stream to tsf_load that handles the decompression.

SFPack and sf2pack seem other formats that are very similar to sfArk. None seems to be popular enough to be worth supporting inside TSF itself.

The last remaining format is SF3/SF4. This is the only one that in my opinion is interesting and actually useful. It's 100% SF2 except that the audio sample block isn't raw PCM, it's compressed either with OGG Vorbis (SF3) or FLAC (SF4).
While I don't think it's feasible to include OGG or FLAC decompression inside TSF, it would be a decent idea to support special #define macros to enable SF3 support if stb_vorbis is available, or SF4 if dr_flac is available.

Which one are you interested in? If it's just something like sfArk/SFPack/sf2pack, does Godot not support asset compression which can store the SF2 in a compressed asset archive of some sort?

[WindowsNT]

I use sf2cute to pack a SFZ into SF2 to be used then with TSF.

[ghost]

I wasn't aware sfark is proprietary. The engine i am working on does have the ability to decode ogg optionally (but not flac) so could implement SF3 but to be honest I am happy with .sf2. And I feel like SF3/SF4 are more for high end production probably not for me though it does sound very interesting. I'd be more interested to see it supported in my DAW. The goal was to implement a .midi player in the engine which I did. And sfz was more of an after thought to further compress the game data but sf2 are usually small package anyway .

[ell1e]

IMHO the memory use might be more interesting to target than the disk space. E.g. I have a 30MB soundfont named "GeneralUser", and loaded up in TSF it spreads out to a constant 50MB of memory. Which makes me wonder if e.g. a sample cache (could be done via custom cache/uncache user callbacks that could write to disk, apply .ogg, or whatever the app wants) applied on samples not used for a while would be a useful addition. Most low spec hardware still tends to have more persistent storage than faster non-persistent memory, so I think this would be a more obvious thing to target to lower requirements.

[ghost]

I think .sf3 might produce a more compact package than .sf2. Ogg data of equal quality as PCM is much smaller. But I think ogg (sf3) might create audio artifacts.

I was reading on MuseScore and is pretty big difference. sf3 is 38 mb vs 200 sf2. It makes a really big difference on bigger size soundfonts. PCM is losless while ogg is lossy. Seems almost everyone confirms artifacts with sf3 so it might in a way be a downgrade from sf2. Also very slow to load. Sf4 might make more sense with flac for high quality audio and sf2 for portable high quality .

[ell1e]

Ogg data of equal quality as PCM is much smaller.

I assume it would be decoded on soundfont load, so for memory use it wouldn't make a difference then.