The most future proof format for sampled instruments is SFZ

[audiojunkie]

I have been thinking about this for a while, and I want to share my reasoning behind my thoughts:

I maintain that the most future proof format for sampled instruments is SFZ.

SFZ formatted instruments containing properly named multisamples with loop point metadata stored in the WAV file are the most compatible and most future proof medium for sampled instruments. They are compatible with everything having to do with samples.

Think about it. At its highest level, most samplers import and read SFZ mapped instruments. Often the the most important configuration data can be imported into the sampler as well. So, at the highest level, SFZ is not only compatible with SFZ parsers such as sfizz, sforzando, LinuxSampler, etc, but with nearly every available sampler on the market.

But what if there are some samplers that can't read and import the SFZ instrument information? That's where a properly named and looped set of multisamples come in. Nearly all samplers, even those who can't read SFZ instruments can at the very least read the WAV files. If the WAV files are properly named and looped, the majority of the work is already done--even for these samplers. If the loop points are already assigned and you know the root notes and such for the samples, all you have to do is map them to the sampler you use. It's a little more work than being able to completely import the complete instrument data, but it still saves a huge amount of time from having to build a sampled instrument from scratch. At the absolute lowest level, you can at the very least import WAV file samples into any sampler out there. This provides future proofing for your instruments, no matter what sampler you may use in the future.

Let's compare this future proofing capability against common big name samplers. Nearly all of the "popular" formats for sampled instruments are encrypted, which tie those formats to the single specific sampler they were created for. What if that sampler is no longer available for you to use? What if the company goes under? What if your preferred choice of sampler changes? You are completely out of luck, and your sample investment is rendered useless, unless you can find someone to buy them from you.

There are other formats that are good as well, and don't encrypt their libraries. With these formats, you can at least use a converter to change the instrument format from one type to another. Among these formats, you would find Soundfonts, Decent Sampler instruments, etc. But without the converter, you can't grab the WAV files. For this reason, they are not as future proof as SFZ files.

Over all, for all of the reasons mentioned above, SFZ is the most future proof format for sampled instruments. Is the format perfect? No. Basic scripting for simple instruments is not difficult, but it can get very difficult to do complicated scripting with SFZ, especially since there isn't much official as far as GUI-based instrument creation. That is a hurdle yet to be overcome with SFZ. However, there is a common denominator of basic opcodes that nearly every SFZ parser must use, and that common denominator of basic opcodes are the ones that I mentioned that are very easy and basic for scripting. Therefore, even despite this drawback, SFZ is still the most future proof format in existence today for sampled instruments.

[KBSoundSmith]

Sounds reasonable to me. I think for people rolling their own samples and libraries, SFZ is probably the way to go. If using 3rd party samplers and sample content, one should expect the possibility that if the company goes down, their proprietary sample content may go down with it (EDIT: although that seems a worthwhile tradeoff for certain types of samples, like orchestral libraries and so on). So, for a person's custom content (especially if it doesn't require lots of scripting), SFZ probably is best.

[audiojunkie]

I made a simple generic SFZ instrument template that can be used by anyone who doesn't know (or want to know) how to program SFZ files. It is a simple fill in the blanks faire. All a person essentially needs to do, is add the filenames of their looped WAV files to the text file. SFZ is not that hard for the kind of sampling that most of us using samples for personal content would do. I would never create a library like D. Smolken's deeply sampled instruents, personally--that's where I leave it to the professionals to make the really deeply sampled libraries. For most of what I do, I would involve samples for round robins or differing velocity layers and attack and release settings. This level of stuff is absolutely simple for people to do, and even more simple with a generic instrument template.

[enroe]

Nearly all of the "popular" formats for sampled instruments are encrypted, which tie those formats to the single specific sampler they were created for.

What if that sampler is no longer available for you to use? What if the company goes under? What if your preferred choice of sampler changes?

Exactly that.

This is really a nightmare. It is therefore very important for
building your own library to choose such a future-proof format.

Even if the company with the proprietary sample format doesn't
go under, there are many circumstances to leave the format. In
the beginning we had the AKAI format - still today(!), then the
GIGA format, then Halion (Steinberg, Cubase), EXS (Apple-
Logic) and finally Kontakt.

We all know: Some formats disappeared completely (AKAI, GIGA).
Some changed encryption or their company policy (Halion, EXS,
Kontakt) towards a closed purely proprietary container. This was
extremely annoying in individual cases - and it cost us almost a
year of work just to migrate libraries.

Today we have everything - really everything (!) - in SFZ format.

I can only underline Audiojunkie's argument: The format is open,
freely accessible, editable - and therefore future-proof. If you
really want to do it well, you take SFZ.

Also compare this thread .

[j_e_g]

Seems I've heard this all before. Oh wait, I just visited LinuxMusicians forum.

[JeffLearman]

SFZ has (almost) everything except encryption of proprietary data. So, most commercial sampleset makers won't use it -- at least, not the big dogs who are worried about piracy.

And while we could add support for encryption to SFZ, I can't see how it could work in a way that isn't rather easily broken, assuming there's an open-source player that supports encryption.

[audiojunkie]

Encryption is the last thing I would want in a format for future-proofing.

[DSmolken]

In the sense that the format is open, and anybody can develop an SFZ player in the future without needing any permission from anyone, yes. Where does the DecentSampler format stand? Tbh I haven't really compared them or tried any DecentSampler instruments, but, well, someday I'll get around to it...

[audiojunkie]

In the sense that the format is open, and anybody can develop an SFZ player in the future without needing any permission from anyone, yes. Where does the DecentSampler format stand? Tbh I haven't really compared them or tried any DecentSampler instruments, but, well, someday I'll get around to it...

DecentSampler is good, and it converts to SFZ well, but but the player is closed source. To me that makes it less suitable for being a future-proof archival format than SFZ.

[Burillo]

Is sfz anywhere as capable as something like Kontakt is? Like, can it do legato samples, round robin, and other complex scripting? I mean, the base assumption behind this thread is that loop points and wav samples is all you need from a sampler, but that's not true for like 90% of instrument sample libraries out there.

[audiojunkie]

Is sfz anywhere as capable as something like Kontakt is? Like, can it do legato samples, round robin, and other complex scripting? I mean, the base assumption behind this thread is that loop points and wav samples is all you need from a sampler, but that's not true for like 90% of instrument sample libraries out there.

LinuxSampler has a scripting system nearly on par with Kontakt’s. It works with SFZ, but it is native to LinuxSampler only. None of the other SFZ parsers have Kontakt-like Scripting. HISE may have something equivalent to scripting as well, but because it is aimed more at developers, and that is not my strength, I haven’t done more than a cursory investigation of HISE. Over all, SFZ itself does not to my knowledge have scripting as deep as Kontakt’s scripting. SFZ, however, is very very deep, and I view myself as a beginner with it. DSmolken is following this thread and is the resident expert on the subject, so I hope he will speak up and correct me on any points that I have incorrect.

My point with this whole thread is that SFZ is ideal as a long-term sample archival format, chiefly because of the access to the multisamples, and the almost universal import support—very few samplers don’t have at least rudimentary support for importing SFZ instruments.

But, as I suspect you are alluding to with your scripting question, it is not an ideal format for retaining highly scripted instruments. Unfortunately, sampler instruments like that are deeply tied to their native, encrypted format. SFZ will not likely help in those situations. But then again, It would be unlikely that a normal user will ever create an instrument of that depth by himself or herself. If a person isn’t going to use the multisampled wave files to recreate the instrument, there is little point in having access to the wav files.

My point is that SFZ is the the most future proof format because it provides access to the wav files, which when properly labeled and looped, allow for easy transfer to almost any sampler.

Edit: I just realized that I only partially answered your question. Sorry. Yes, SFZ can do legato, round robin, cutoff muting like with high hat drums, and much, much more. It is very advanced for that kind of stuff. I don’t think it is capable of advanced guitar strumming patterns and such that Kontakt can do, I’ll let DSmolken correct me if I’m wrong.

[pljones]

I've not studied why scripting is used in libraries in Kontakt, to be honest. I've never needed to as SFZ's always given me all I need. ns_kit7 drum library works better in SFZ (using my own mappings) than it did in Kontakt (using the native mappings) - I can't compare with Halion as I never bought it. DSmolken's Sforzando instruments all work great, too. Maybe because I really only use drum libraries I'm not seeing much need for scripting, though.

I don’t think it is capable of advanced guitar strumming patterns and such that Kontakt can do

You could probably get something working by thinking about what you were trying to achieve carefully. That's the thing, SFZ is a scripting language, fundamentally, in my view - you just have to understand its limitations and nuances to get the best out of it.

[DSmolken]

Pedantically: it's not a scripting language as such, it's an event filter configuration.

It is possible to do multi-mic samples, true or fake legato, and a lot of other stuff. It's not possible (at least in current players and as far as I know) to have variables that have persistence between notes or free-running LFOs.

[Uncle E]

I made a simple generic SFZ instrument template that can be used by anyone who doesn't know (or want to know) how to program SFZ files.

Where can we download this?

[audiojunkie]

It’s on the SFZformat repository site right here:

https://github.com/sfzinstruments/sfzte ... mplate.sfz

I’ve had some time to think about things, and would probably change a few things about this script to make it even more universal, but you should easily be able to get the gist of things by looking it over. DSmolken also has a generic script availabe there that you can use to do things a bit differently.