Best file format for instruments with round-robin samples?

[Xleth]

Hello,

If you were to decide for the best file format that is capable of referencing at least 16 round-robin samples per zone (a zone may span one or more notes and one or more velocities), which would it be and why?

My criteria:

- The format should be popular, mainstream and widely-supported

- The round-robin samples should not be any kind of "hacks" (such as EXS24, where it's some kind of a trigger-chained-group kludge labyrinth). It should be a clean, simple and straightforward list of samples that are assigned to a zone, forming a round-robin group.

Thanks!

[pljones]

There is only one answer (from me ): sfz

[Xleth]

There is only one answer (from me ): sfz

Well, SFZ doesn't seem to be supported by Cdxtract, which I would personally see as a big disadvantage (and something that indicates SFZ is not a mainstream and widely-supported format yet).

[stanlea]

sfz is not open source, but the specs are available to all, and many samplers can read it - CDxtract development seems a bit sleepy... why should you need it ?

[Baard]

There is only one answer (from me ): sfz

+1 from me. I just converted some rather large libs for a dev here, and sfz has no problems with 8xRR and many/huge samples. As long you use a player that streams from disk and has full support for the opcodes (ARIA or Linuxsampler comes into mind) it can handle both complex and large patches.

[Xleth]

When I look at major sample lib shops, the most popular file format by far seems to be Kontakt. EXS24 and HALion are far behind it. SFZ is practically non-existent in the commercial lib area. Only VSTi beats Kontakt as far as the number of titles is concerned (by about 50%), but VSTi is not a proper file format.

The Kontakt file format should be open too, I guess. How else could producers create sample libraries for it? Conversions from other formats would be risky and forcing them to use the Kontakt editor would be too much IMHO...

The question is: What are the capabilites/limits of the Kontakt format regarding round-robin samples? I haven't used Kontakt yet.

[audiojunkie]

There is only one answer (from me ): sfz

+1 from me. I just converted some rather large libs for a dev here, and sfz has no problems with 8xRR and many/huge samples. As long you use a player that streams from disk and has full support for the opcodes (ARIA or Linuxsampler comes into mind) it can handle both complex and large patches.

And if I may say so, Baard did an excellent job with converting those sample libraries!

--Sean

[Baard]

And if I may say so, Baard did an excellent job with converting those sample libraries!

Thanks mate! Really glad you like them. After all, IIRC it was your thread in the samples forum that got my into it.

Slightly on topic: If you are going to sell your samples, it would be a good idea providing as many formats as possible, or at least provide SFZs for users without Kontakt. From your description, the format is more than capable. But Kontakt is the industry standard, no doubt about that.

I have continued to write SFZs, both paid work and for free since I "had to get Kontakt in the end". Its a very capable format, and open to everybody, which is why users such as pljones, audiojunkie and myself speak highly of its virtues.

On topic: Kontakt is very capable for what you are describing. Try the demo (edit mode will time out after 15 min or so, and have to be reloaded). Look around inside some of the included instruments, and you'll get the idea. Oh and perhaps read the manual?

[audiojunkie]

And if I may say so, Baard did an excellent job with converting those sample libraries!

Thanks mate! Really glad you like them. After all, IIRC it was your thread in the samples forum that got my into it.

Slightly on topic: If you are going to sell your samples, it would be a good idea providing as many formats as possible, or at least provide SFZs for users without Kontakt. From your description, the format is more than capable. But Kontakt is the industry standard, no doubt about that.

I have continued to write SFZs, both paid work and for free since I "had to get Kontakt in the end". Its a very capable format, and open to everybody, which is why users such as pljones, audiojunkie and myself speak highly of its virtues.

On topic: Kontakt is very capable for what you are describing. Try the demo (edit mode will time out after 15 min or so, and have to be reloaded). Look around inside some of the included instruments, and you'll get the idea. Oh and perhaps read the manual?

@Baard: Yeah, that was me. I was the one and only person to purchase Shreddage for Directwave. However, Directwave is so broken, that Zircon and I were never able to get it to work decently. That's when I started trying to get Zircon to see the possibilities in SFZ. I am glad that I recommended you to Zircon, and you've done a wonderful job converting the files! Also, I believe you made an excellent decision to use LinuxSampler as one of the plugins that is primarily supported for the Shreddage library, because it is free and openly available for everyone to use. I'll bet Zircon gets a lot of sales from those who don't use Kontakt!

Back to the topic: Baard is correct. If you are going to sell your samples, providing as many formats as possible is a very good idea. However, examine the market carefully--make sure that you are going to get sufficient sales for your hard work in converting to the different formats. My recommendation would be to focus on Kontakt and SFZ. These two formats are probably the most supported and universally accessible formats in existence. Kontakt is the industry standard proprietary format, and SFZ is the industry standard open format. There are many plugins that support the SFZ format, and if you don't need extensive scripting, it can do virtually anything you want with it.

--Sean

[sellyoursoul]

It seems to me that SFZ isn't well supported by the sample players that have SFZ support. The only sample player that hasn't broken SFZ files in some way for me is SFZ player, and it isn't without it's issues. I see some people mention ARIA, but I don't see it available as a standalone sample player. The last time that I tried Linux sampler in Windows, it was prone to crashing.

[chickeneps]

Some thoughts:

Xleth: I assume from your question and reply that you want to know this because you are going to/thinking about making a sample library? If so, I think what you'd like is to program in a environment where you can program the Round Robins easily and without a lot of guessing. Because to the user it doesn't matter - they just play it. It wouldn't matter to them if the e.g. EXS24 kludge-way is kludgy, it just has to work.

Plus, the file format doesn't make a difference, with the exception of SFZ, because you are typing it in. What does make a difference is the player that you program it on.

The problem with SFZ is a proper player to play it on. SFZ is sort of like a format without an engine (currently), when you are talking about advanced things like Round Robin. Most SFZ players do not support the entire feature set. And the ones that do aren't the easiest to work with.

Round Robin is difficult because it's a parameter that is dependent on other references. Most every other parameter (tuning, looping, envelopes, etc.) just works within itself.

So far I don't know of any platform where it's easy to program RR's as you go. The best thing is to just plan it out on paper and BE CONSISTENT. Don't spread your RR's over multiple keys, and keep the amount of RR's the same - don't have some be 12 RR's and the other 13, etc.

Kontakt has more libraries available for it for two main reasons: they provided copy-protection to those who could pay for it, and Kontakt is hugely popular and can do pretty much everything.

Most people who RR's in Kontakt do it via Scripting. I wrote a comprehensive article about RR scripting in Virtual instruments magazine awhile back. The on-interface Kontakt RR implementation is limited, I'll explain briefly:

Lets say you have two keys with two velocities. Let's be perfect and say each of the 4 areas have 8 RR samples. This works out great, but with one picky problem. If you hit Key1-Vel1, you get Sample1 of that chain. Then if you hit Key2-Vel1, you won't get Sample1, you'll get Sample2. The chaining is global, not polyphonic. But if you are just doing RR for the sake of randomness, that shouldn't matter.

You get in trouble if you have different amounts of RR's in different areas (areas meaning different keys, velocities, or even keyswitches or controller switches). Kontakt will not be nice - since the chain is global, if you hit an area that has (say) 5 less RR's than your largest RR amt, once you run out, the note WILL NOT PLAY until you hit the area the 5 requisite times to get back to the top.

SFZ may or may not have this problem - SFZ is just a spec, and it doesn't stipulate how SFZ is implemented. That's up to the engine, and since SFZ wasn't managed - and still isn't - it's the Wild West.

You said EXS is kludgy, but with EXS you can program different chains for different areas.

Let's not forget Reason. Believe it or not, it's RR is quite good, despite having just a ON-OFF knob for it. The engine is highly intelligent about it under the hood and makes good decisions. You just can't specifically control it.

If I had to pick on a good easy programming solution for RR, I'd do this: I'd program it out on SFZ, minding the good practices advised above, then load the SFZ into Kontakt, it should load in just fine and handle 16 or even more RR levels.

[pljones]

Has Kontakt improved since K2/K3 at importing SFZ files? Back then it was really, really bad. Simple SFZ 1.0 layouts went completely wrong most of the time, unless you stuck to the limited set of instructions they had implemented. And the importer also seemed to get confused by the actual layout - i.e. where you put line breaks, requiring them in places. (So just a note of warning...)

SFZ format is open. René made that clear - it was specifically to counter the closed SF2 format. As stanlea said, anyone can write an implementation of the format. Cakewalk have several implementations of sfz-2, themselves. LinuxSampler (when it doesn't crash) is getting there. ARIA Player (but you need an ARIA-based instrument) is pretty solid.

The main reason I'd choose SFZ over any other format is that it's plain text. It doesn't hurt my eyes or mouse-hand trying to work on it because I can use my favourite text editor. Having mapped many drum kits with weird round robins, I've not come across an implementation that had a problem in that area. (Although I've never had anything complex like that import into Kontakt even vaguely close to what I wrote. I get the vaguest of feelings NI aren't particularly interested in SFZ...)

[enroe]

The main reason I'd choose SFZ over any other format is that it's plain text. It doesn't hurt my eyes or mouse-hand trying to work on it because I can use my favourite text editor. ...

+1. That's it!

[Xleth]

Thanks for the informative replies.

If Kontakt has DRM (copy protection, encryption, w/e), what are the implications? Can an instrument stored in such a protected file be converted using say Chickensys Translator (or other legal software) to another format?

I'm asking because I would avoid DRM-enabled formats like plague. They're not future-proof. If the vendor (NI) decides they will let all old licenses expire or stop supporting an old version of the format, your music files basically "stop playing".

I'm sure the vendor likes the lock-in, though...

[audiojunkie]

Some thoughts:

Xleth: I assume from your question and reply that you want to know this because you are going to/thinking about making a sample library? If so, I think what you'd like is to program in a environment where you can program the Round Robins easily and without a lot of guessing. Because to the user it doesn't matter - they just play it. It wouldn't matter to them if the e.g. EXS24 kludge-way is kludgy, it just has to work.

Plus, the file format doesn't make a difference, with the exception of SFZ, because you are typing it in. What does make a difference is the player that you program it on.

The problem with SFZ is a proper player to play it on. SFZ is sort of like a format without an engine (currently), when you are talking about advanced things like Round Robin. Most SFZ players do not support the entire feature set. And the ones that do aren't the easiest to work with.

Round Robin is difficult because it's a parameter that is dependent on other references. Most every other parameter (tuning, looping, envelopes, etc.) just works within itself.

So far I don't know of any platform where it's easy to program RR's as you go. The best thing is to just plan it out on paper and BE CONSISTENT. Don't spread your RR's over multiple keys, and keep the amount of RR's the same - don't have some be 12 RR's and the other 13, etc.

Kontakt has more libraries available for it for two main reasons: they provided copy-protection to those who could pay for it, and Kontakt is hugely popular and can do pretty much everything.

Most people who RR's in Kontakt do it via Scripting. I wrote a comprehensive article about RR scripting in Virtual instruments magazine awhile back. The on-interface Kontakt RR implementation is limited, I'll explain briefly:

Lets say you have two keys with two velocities. Let's be perfect and say each of the 4 areas have 8 RR samples. This works out great, but with one picky problem. If you hit Key1-Vel1, you get Sample1 of that chain. Then if you hit Key2-Vel1, you won't get Sample1, you'll get Sample2. The chaining is global, not polyphonic. But if you are just doing RR for the sake of randomness, that shouldn't matter.

You get in trouble if you have different amounts of RR's in different areas (areas meaning different keys, velocities, or even keyswitches or controller switches). Kontakt will not be nice - since the chain is global, if you hit an area that has (say) 5 less RR's than your largest RR amt, once you run out, the note WILL NOT PLAY until you hit the area the 5 requisite times to get back to the top.

SFZ may or may not have this problem - SFZ is just a spec, and it doesn't stipulate how SFZ is implemented. That's up to the engine, and since SFZ wasn't managed - and still isn't - it's the Wild West.

You said EXS is kludgy, but with EXS you can program different chains for different areas.

Let's not forget Reason. Believe it or not, it's RR is quite good, despite having just a ON-OFF knob for it. The engine is highly intelligent about it under the hood and makes good decisions. You just can't specifically control it.

If I had to pick on a good easy programming solution for RR, I'd do this: I'd program it out on SFZ, minding the good practices advised above, then load the SFZ into Kontakt, it should load in just fine and handle 16 or even more RR levels.

This is a well thought out response. Thanks for contributing to this topic!

--Sean