The most future proof format for sampled instruments is SFZ

[enroe]

<control>
label_cc100=Attack time
label_cc101=Hold time
label_cc102=Decay time
label_cc103=Sustain level
label_cc104=Release time

At this point, I would strongly recommend taking the assignment that has been
established in the meantime by gm-standards. Simply to be compatible everywhere
and not cause confusion. And that assignment is:

label_cc73=Attack time
label_cc76=Hold time
label_cc75=Decay time
label_cc70=Sustain level
label_cc72=Release time

Or in better order:

label_cc70=Sustain level
label_cc72=Release time
label_cc73=Attack time
label_cc75=Decay time
label_cc76=Hold time

[audiojunkie]

Yeah, at first glance that looks like it would work. You can add that to the top of any instrument, and vibrato would be similarly easy.

Two caveats: some instruments will have multiple <global> headers (defeating the point of the global nomenclature, I know, I know... but even a lot of my free ones have three or four, as that makes implementing unison easier by giving each voice its own global), and this would need to be added to each. Also you might not want the same AHDSR envelope on everything in certain cases, for example when there are separate release or mechanical noise samples.

Cool! I think this will take my samples to a new level. Thank you!

How in the world did you learn this stuff with no documentation?!

[audiojunkie]

<control>
label_cc100=Attack time
label_cc101=Hold time
label_cc102=Decay time
label_cc103=Sustain level
label_cc104=Release time

At this point, I would strongly recommend taking the assignment that has been
established in the meantime by gm-standards. Simply to be compatible everywhere
and not cause confusion. And that assignment is:

label_cc73=Attack time
label_cc76=Hold time
label_cc75=Decay time
label_cc70=Sustain level
label_cc72=Release time

Or in better order:

label_cc70=Sustain level
label_cc72=Release time
label_cc73=Attack time
label_cc75=Decay time
label_cc76=Hold time

Yes, this is exactly my intention. I want to use the most commonly used values in order to stay the most compatible between the various hardware and software that is out there.

[JeffLearman]

BTW, I just discovered that SFZ "DOES" have encryption!!!! Aria is the only player that supports it though. I thought you'd find that interesting.

https://www.chickensys.com/products2/co ... rmats.html

Read the foot note about the Garritan Aria encrypted SFZ format:

"...As of this writing, the only SFZ files that use encrypted samples are the Garritan Aria-Player libraries. Any SFZ file that references an ".audio" file is encrypted."

https://www.chickensys.com/products2/co ... rmats.html

It's been here all along, but just never caught on in popularity. Only the Aria SFZ parser supports it.

Well, summagun. I guess it's just based on ordinary copyright protection, applied to each waveform. I also guess that nobody cares that any licensed user with some computer skillz could very easily decode and create a pirate version. That'd be much harder to do with closed software like Kontakt. Seems like reasonable compromise, though.

Come to think of it, it's the same compromise as for any digitally-licensed audio, since there are open-source players that can play them. Such as players like VLZ, I assume. Though maybe you need superpowers to compile it yourself and have access to the decryption. Unlike most copyright violations, that would be a criminal infraction, not just civil, thanks to DMCA. That's one of the DCMA provisions I applaud, but like most other DCMA provisions, it went way too far, prompting the arrest of the encryption researcher who gave a talk and said "You can override that copy-protection scheme by holding the shift key when you insert the disk!" (IMHO there's a big difference between breaking a copy-protection scheme and pointing out the flaws in one, as a researcher in the field.)

Thanks for the info.

[JeffLearman]

Audiojunkie, regarding "<global>" sections:

I use <master> instead, if I'm not already using it for some other purpose in an SFZ. The reason is that I sometimes concatenate a lot of SFZs into a single one (so I can switch sounds by changing MIDI program in my live setup, for example.) Then I can reserve <global> for things that really are global.

This is why I wish there was a scoping syntax that wasn't tied to specific names like <master> and <global>.

[JeffLearman]

Cool! I think this will take my samples to a new level. Thank you!

How in the world did you learn this stuff with no documentation?!

Actually, there was documentation: the original sfz spec (as it was intended as an open format.) Of course, there were two issues:
- the spec left a lot of things unsaid. It's hard to write a comprehensive spec even if you're a pro in this area (as I was, for networking standards, back in the 90's)
- the moving target issue, since stuff got added to SFZ by various parties.

So, it was a process of reading the available information and then a lot of testing and investigation (plus gracious answers from people like David from Plogue, once upon a time.) We get to thank people like DSmolken, RedTide, and Kinwie for a lot of that (and many others, like the VCSL guy whose name I don't recall.) Not me so much; I merely sit atop the shoulders of giants.

And thanks to these people, we now have resources like http://sfzformat.com which answers so many questions (and raises so many new ones, since there's still a lot we don't know.)

[audiojunkie]

Audiojunkie, regarding "<global>" sections:

I use <master> instead, if I'm not already using it for some other purpose in an SFZ. The reason is that I sometimes concatenate a lot of SFZs into a single one (so I can switch sounds by changing MIDI program in my live setup, for example.) Then I can reserve <global> for things that really are global.

This is why I wish there was a scoping syntax that wasn't tied to specific names like <master> and <global>.

I don’t remember seeing “Master” listed as an available opcode header in the sfzformat notes. Is it even there?

EDIT: Ah, yes. It is there. It is an Aria opcode. That’s probably why I didn’t pay attention to it. I doubt that opcode is well supported by SFZ parsers outside of Aria. I’m interested in maintaining the widest compatibility with my SFZ files as possible, with as many SFZ parsers as possible. My interest is in using opcodes that are available in all players, rather than supporting opcodes that are specific to just one commercial player that most people will probably never buy.

Nevertheless, thank you for mentioning it. I read up on it since you mentioned it, and I can see how it would be a useful timesaver if the parser the person is using supports is ge opcode.

[JeffLearman]

Ah good point, I didn't realize that <mater> was Aria-specific. Fortunately, the way I use it in my public samplesets, it's OK if ignored. My samplesets are pretty simple.

[essejlc]

<master> is supported in sforzando and sfizz, at least... and is quite handy... I wouldn't be surprised if it worked elsewhere too. I'm with Jeff about wishing the scoping capabilities were better...

[Logga]

with loop point metadata stored in the WAV file

I don't agree with this part. It's too easy to lose this metadata if you're not careful, especially when converting to a different format. FLAC can keep it if you explicitly tell it to, but some or most converters will silently drop it. Better to just store it separately, which AFAIK is possible with SFZ.

And frankly I think audio files should be delivered in a compressed lossless format. FLAC is well documented and just as future proof as WAV. WavPack is an option too.

[audiojunkie]

You can store the loop point data separately in the SFZ if you want, but most sfz parsers don’t make use of those opcodes, so it would be a wasted effort.

[Logga]

most sfz parsers don’t make use of those opcodes

Do they have a good reason for not using them?

In any case, I'm not that fussed about loop data being here or there.
I'm a bit more fussed about using uncompressed WAVs in this day and age. It just seems unnecessary. FLACs seem to work in just about any sampler that I looked at recently.

[essejlc]

I'm a bit more fussed about using uncompressed WAVs in this day and age. It just seems unnecessary. FLACs seem to work in just about any sampler that I looked at recently.

For disk streaming samplers (which most of the SFZ ones are), there is likely some extra CPU overhead involved in the decoding of the lossless codec, which it constantly needs to do. It would be interesting to benchmark this to see how much of an impact there really is.

[enroe]

You can store the loop point data separately in the SFZ if you want, but most sfz parsers don’t make use of those opcodes, so it would be a wasted effort.

Mmhhh, that's mysterious: "loop start" and "loop end" are both version sfz1,
so they should be compatible with all sfz-players.

[audiojunkie]

You can store the loop point data separately in the SFZ if you want, but most sfz parsers don’t make use of those opcodes, so it would be a wasted effort.

Mmhhh, that's mysterious: "loop start" and "loop end" are both version sfz1,
so they should be compatible with all sfz-players.

…only if all SFZ players support all of the SFZ v1 opcodes, which they don’t. That has been a problem since the beginning. Most developers of SFZ parsers only implemented the opcodes they felt were useful to them, and added their own extensions (new opcodes) that they felt they needed. I don’t believe there is an SFZ parser in existence that supports every opcode and extension that has been created. Some come close, but none succeed. That is why I have continually pushed for a recommended minimal subset of opcodes—a common denominator list of essential opcodes that is supported by the majority of parsers and players. I am not pushing for a new standard, per se, but rather a scientific approximation of the most commonly used opcodes for those seeking to code their SFZs for the largest cross plugin compatibility.