The most future proof format for sampled instruments is SFZ

[Uncle E]

I guess another thing I should have mentioned is that when you’re sampling keyboards, C5 often isn’t literally C5. The instruments are usually transposed to make the best sounds fit within the keyboard’s range.

[audiojunkie]

I guess another thing I should have mentioned is that when you’re sampling keyboards, C5 often isn’t literally C5. The instruments are usually transposed to make the best sounds fit within the keyboard’s range.

That makes sense. That's how I was thinking with my sample plan and using just 5 octaves.

[pljones]

A few of those won't work for drums where how hard you're hitting changes a lot of factors, not just volume - you get pitch changes as the skins tense differently with sticks and even more differences with brushes. So what you're sampling really makes a massive difference.

I'd also be wary of

* Balance the volume levels between the various multisamples as needed, and then normalize each sample

Because of the above, you'll need multiple velocity layers and the separate hits on a drum kit each have a peak loudness that differs relatively widely to the others - particularly dependent upon the kit mic'ing. If you normalise, you can find the amount of adjustment to get back to reality goes beyond what you want to be doing in the mapping itself. Then you need to consider something like the hi-hat, where the differences in space between the two surfaces also need taking into consideration.

[audiojunkie]

A few of those won't work for drums where how hard you're hitting changes a lot of factors, not just volume - you get pitch changes as the skins tense differently with sticks and even more differences with brushes. So what you're sampling really makes a massive difference.

I'd also be wary of

* Balance the volume levels between the various multisamples as needed, and then normalize each sample

Because of the above, you'll need multiple velocity layers and the separate hits on a drum kit each have a peak loudness that differs relatively widely to the others - particularly dependent upon the kit mic'ing. If you normalise, you can find the amount of adjustment to get back to reality goes beyond what you want to be doing in the mapping itself. Then you need to consider something like the hi-hat, where the differences in space between the two surfaces also need taking into consideration.

Yeah, I haven't even started thinking about drums and one-shots yet. Everything I've been thinking through has been for chromatic instruments. I'm pretty sure I mentioned that, but it's good that I make it clear. I agree, drums would be very, very different. Also, I change my sampling plan all the time when I find things that I think will be better for the samples. I'm glad you mention those things above, because when I get to the point where I'm ready to start building a generic SFZ script for drums, I'm going to want to keep everything in mind. With drums, I have absolute plans for multiple velocity layers and round robins and things like hi-hat mute groups, but I'm not quite ready for that part yet. In fact, I really think my generic "fill-in the blanks" SFZ script for chromatic instruments is going to need a complete rewrite. There are a lot of things that I've learned or taken into consideration since then, and I no longer feel it is adequate (or even correct).

What I would love to do, is create (as much as possible) a good generic set of scripts that everyone can use to create future-proof personal sample libraries. Some things that I definitely think need to be added to my current script is Velocity to volume control, and a way to activate legato mode, when wanted. It's all a work in progress, but the one thing that I am convinced of, is that multisamples that have been properly labeled and looped, with an SFZ script included, is an excellent future-proof long term storage medium that should survive any OS used, and just about any sampler out there. I don't think many people will try to make giant libraries like SM Drums or some of those 40GB sample libraries. That level of sampling is not my intent (although it could be done). The idea is to be able to put creative sampling through SFZ into the layman's hands and allow those custom libraries to be future-proof.

I've had big ideas before. We'll see how long the energy and enthusiasm holds up.

[audiojunkie]

A few of those won't work for drums where how hard you're hitting changes a lot of factors, not just volume - you get pitch changes as the skins tense differently with sticks and even more differences with brushes. So what you're sampling really makes a massive difference.

I'd also be wary of

* Balance the volume levels between the various multisamples as needed, and then normalize each sample

Because of the above, you'll need multiple velocity layers and the separate hits on a drum kit each have a peak loudness that differs relatively widely to the others - particularly dependent upon the kit mic'ing. If you normalise, you can find the amount of adjustment to get back to reality goes beyond what you want to be doing in the mapping itself. Then you need to consider something like the hi-hat, where the differences in space between the two surfaces also need taking into consideration.

Yeah, I haven't even started thinking about drums and one-shots yet. Everything I've been thinking through has been for chromatic instruments. I'm pretty sure I mentioned that, but it's good that I make it clear. I agree, drums would be very, very different. Also, I change my sampling plan all the time when I find things that I think will be better for the samples. I'm glad you mention those things above, because when I get to the point where I'm ready to start building a generic SFZ script for drums, I'm going to want to keep everything in mind. With drums, I have absolute plans for multiple velocity layers and round robins and things like hi-hat mute groups, but I'm not quite ready for that part yet. In fact, I really think my generic "fill-in the blanks" SFZ script for chromatic instruments is going to need a complete rewrite. There are a lot of things that I've learned or taken into consideration since then, and I no longer feel it is adequate (or even correct).

What I would love to do, is create (as much as possible) a good generic set of scripts that everyone can use to create future-proof personal sample libraries. Some things that I definitely think need to be added to my current script is Velocity to volume control, and a way to activate legato mode, when wanted. It's all a work in progress, but the one thing that I am convinced of, is that multisamples that have been properly labeled and looped, with an SFZ script included, is an excellent future-proof long term storage medium that should survive any OS used, and just about any sampler out there. I don't think many people will try to make giant libraries like SM Drums or some of those 40GB sample libraries. That level of sampling is not my intent (although it could be done). The idea is to be able to put creative sampling through SFZ into the layman's hands and allow those custom libraries to be future-proof.

I've had big ideas before. We'll see how long the energy and enthusiasm holds up.

Edit: BTW, I love the feedback everyone is giving! It's really helpful!!!

[Uncle E]

Because of the above, you'll need multiple velocity layers and the separate hits on a drum kit each have a peak loudness that differs relatively widely to the others - particularly dependent upon the kit mic'ing. If you normalise, you can find the amount of adjustment to get back to reality goes beyond what you want to be doing in the mapping itself. Then you need to consider something like the hi-hat, where the differences in space between the two surfaces also need taking into consideration.

You’re right but then the keyboard’s velocity will also affect the level. You’d need to have velocity control sample switching but not output volume.

[Trensharo]

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.

Kinda not true, considering how broad support for EXS24 and Kontakt formats are (unless encrypted).

Unless the library is encrypted, you can just load them in HALion, Structure, Presence XT, and other samples. Drag and Drop, and they just work.

Of course, if you depend on scripting that is another story, and that's kind of where SFZ falls behind those other samplers (and why everyone is using Kontakt or another in-house or third party sampler platform).

A lot of great libraries would be decidedly mediocre, if not for the scripting.

[Ah_Dziz]

I still think that a folder named "patch name" containing properly named wav/aiff with all proper loop, BPM, etc. Metadata included will beat out pretty much everything for future proofing. At the end of the day all "patch" formats are gonna be dependent on the amount of support that developers give them. Unfortunately very complicated sample based stuff (with crazy scripting etc) is always going to depend on some ongoing support. Being able to pull each articulation into a sampler where it's auto mapped to the proper key and velocity layer based on it's name is good enough for many many instruments to get up and running.

I do think SFZ is a very cool and well implemented format that should be included in some form with pretty much any sample library.

[pljones]

One way of looking at SFZ is as documentation of how the samples were intended to be used, for those who want to read it. If your sample player is intiated in the ways of SFZ, great. Otherwise, it's useful in explaining to your "other brand" sampler what it should do.

[JeffLearman]

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

I guess I should have been clearer.

A lot of people use commercial samplesets. It would be nice to have those samplesets in a more future-proof format. If SFZ supported encryption, then more commercial samplesets *might* be in sfz format. Thus providing more future-proofness for those commercial samplesets.

I future-proof my hardware keyboards. For any patch I use a lot, I make an sfz sampleset. One reason I do this is because frankly it's a lot easier to do MIDI editing with a softsynth than a hardware keyboard. But the other benefit is that my DAW projects still work if my keyboard dies (or isn't hooked up at the moment.) Or if I've sold it (though I usually donate when past the lifetime.) The last bit is probably a technical copyright violation, but since nobody even hears my music I'm pretty safe.

While I know a fair bit about encryption (I'm currently writing code to provide IPsec encryption for inter-cloud communications), I wouldn't know where to begin, to add encryption to SFZ, due the the key distribution issues. Frankly I don't really know how security works in commercial products like Kontakt -- how the key distribution works so that Kontakt doesn't have to use security by obfuscation. And it's harder for sfz since it's open source; it'd be hard to provide an encryption plugin for sfz that wouldn't be easily thwarted by intercepting the unencrypted sound in the signal processing chain, using a fairly simple modification to the open source software. Sigh.

[JeffLearman]

Kinda not true, considering how broad support for EXS24 and Kontakt formats are (unless encrypted).

You might have a point there, though I'm not familiar with the limitations of EXS24. Is there a lot of support for Kontakt format by other players?

[JeffLearman]

I still think that a folder named "patch name" containing properly named wav/aiff with all proper loop, BPM, etc. Metadata included will beat out pretty much everything for future proofing.

I use a number of SFZ features that don't fit in metadata (like velocity layer, which is REALLY important to me, and velocity crossfading, which I often use, and velocity filter control when I don't have velocity layers, and ... well, I bet the list goes on, and I only build REALLY SIMPLE sfzs compared to my friends like DSmolken.)

[audiojunkie]

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

I guess I should have been clearer.

A lot of people use commercial samplesets. It would be nice to have those samplesets in a more future-proof format. If SFZ supported encryption, then more commercial samplesets *might* be in sfz format. Thus providing more future-proofness for those commercial samplesets.

I future-proof my hardware keyboards. For any patch I use a lot, I make an sfz sampleset. One reason I do this is because frankly it's a lot easier to do MIDI editing with a softsynth than a hardware keyboard. But the other benefit is that my DAW projects still work if my keyboard dies (or isn't hooked up at the moment.) Or if I've sold it (though I usually donate when past the lifetime.) The last bit is probably a technical copyright violation, but since nobody even hears my music I'm pretty safe.

While I know a fair bit about encryption (I'm currently writing code to provide IPsec encryption for inter-cloud communications), I wouldn't know where to begin, to add encryption to SFZ, due the the key distribution issues. Frankly I don't really know how security works in commercial products like Kontakt -- how the key distribution works so that Kontakt doesn't have to use security by obfuscation. And it's harder for sfz since it's open source; it'd be hard to provide an encryption plugin for sfz that wouldn't be easily thwarted by intercepting the unencrypted sound in the signal processing chain, using a fairly simple modification to the open source software. Sigh.

I see where you are going with this now. I did indeed misunderstand your original comment about encryption. More developers would use SFZ if it were encrypted—which I believe would be the case. I also agree completely with your instrument archival process. That is currently what I am starting to do myself—I’d like to get to the point that I could get by fine without anything more than my collection of favorite SFZ instruments.

However, I also believe that encryption would do more harm than good with the format. The chief redeeming feature of SFZ, in my opinion, is the open nature of the format—the very opposite of encryption—without which, you would not likely find SFZ import capability so ubiquitous a feature — currently found on nearly every modern sampler in existence to one extent or another.

However, I do think the biggest thing holding SFZ back, is also one of its strengths—the idea of using hand editable text files—which, while open, leaves a high difficulty level for the normal musician (read: non-technical) trying to do things with opcodes to achieve the desired results.

If I was independently wealthy, I would create an SFZ editing program similar to ChickenSys’ constructor. I would make it support all opcodes, and make it available for Windows, Apple, Linux, Android and iOS. I would then release the completed program as Open Source. I think that would do so much more for SFZ than would encryption.

But alas, I work long hard hours daily to just barely cover my needs.

[audiojunkie]

I still think that a folder named "patch name" containing properly named wav/aiff with all proper loop, BPM, etc. Metadata included will beat out pretty much everything for future proofing.

I use a number of SFZ features that don't fit in metadata (like velocity layer, which is REALLY important to me, and velocity crossfading, which I often use, and velocity filter control when I don't have velocity layers, and ... well, I bet the list goes on, and I only build REALLY SIMPLE sfzs compared to my friends like DSmolken.)

All of us only build simple SFZs compared to DSmolken! (But, for this very reason, his SFZ instruments won’t play in every SFZ sampler. Currently, Sforzando is the only officially supported player, though Sfizz might do ok with playing them as well.)

Which brings me back to my point: The thing that would help SFZ gain even broader industry prominence (in my opinion) would be a GUI-based cross-platform SFZ editor, giving the power of the format to the “everyman”.

That said, I do agree that a folder named "patch name" containing properly named wav/aiff with all proper loop, BPM, etc. Metadata included” would be the format most guaranteed to last for future-proofing your access to your samples—which encryption is unable to do. The nice thing is that SFZ format already does this—and much more, dependent upon what opcodes each sampler in existence chooses to import in addition to the properly looped and labeled multisamples.

But then again, what I’d like to see, if we can’t get a cross-platform editor with full opcode support, is to find the closest bottom denominator of accepted opcodes (the ones most used by most samplers), and support that subset as the “common” accepted SFZ BASIC format. I am trying to incorporate this idea into a basic set of generic “fill-in-the-blanks” SFZ templates that everyone can use.

[audiojunkie]

As a thought experiment, it would be interesting to see if we could all come up with a list of the essential opcodes—the most important codes to us, that most samplers already employ. That is the subset of SFZ I personally am most interested in.