Huh? I wasn't aware of any issues and we were testing heavily at the time. Perhaps you should have let NI know about it then.

I just tried a 16-position Round Robin SFZ on Kontakt 3 and it worked perfectly. However, I tried the same on Kontakt 2.2 and it didn't recognize Round Robin - but it did import. If anyone has only Kontakt2 and would like this functionality, let me know and I can help. But this was many years ago.

Kontakt currently imports SFZ really well, there aren't any issues I know of. If there are, let me know.

Some corrections:

SoundFont IS an open format, the specifications have been public since inception. I think the poster meant SoundFont is a binary format so regular users can't write one out; that is, it's not textual. But you can compose one using a variety of SoundFont players like Viena or Creatives own tool, or programs like Constructor.

SoundFont is certainly public, it's no secret nor what you call "DRM".

SFZ "2.0": Cakewalk only published the last rgcaudio spec of SFZ (so-called "1.0"), which goes back quite a few years. They have not published what is now being called "SFZ 2.0". It has been documented (out of necessity) by private parties whom have no authority to alter/fix the spec in a managed way. There are several entities that have extended the SFZ spec to suit their own needs, and all of them have attempted to ask Cakewalk/Roland to start managing the format without success, so they just went ahead and did it.

I'm not sure "DRM" is a proper term to describe formats but I know what is meant by it. The common term is "protected".

We can accurately describe three types of formats - Textual (like SFZ or XML), Binary (like SoundFont), and Protected (like HALion 3/4).

Most formats are not protected. The only protected ones are minor: HALion 3/4 and Independence. (Kontakt 5 is also (for now) is in that category.) Kontakt 4 and earlier are not protected.

I do agree, there isn't any excuse for a protected format, and I think it's shameful for Steinberg to protect even user files AND not make it clear to users that they are "trapped" if they make a library of HALion 3/4 files.

Use whats comfortable for you - SFZ if you like it and you can use Kontakt as an engine or something other SFZ engine, provided it handles enough of the SFZ parameters that matter to you.

What do you mean by "for now"?



That certainly doesn't sound like SFZ is a future-proof open format...

There really should be an open all-purpose format supporting all advanced features, which could become the primary safe default format for a composer's instrument library (which is what I am looking for here)...

Currently no one can read Kontakt 5 files besides NI. NI does care about interoperability so that limitation could change in the future. I can't say the same for companies that created the other protected formats.

I think its clear that when Cakewalk bought rgcaudio and the SFZ format, they did not continue the tradition of publicly documenting it. The implication of publicly describing a format is that you WANT people working with it and making files on their own. The implication of NOT publicly maintaining it is that you DON'T want people fussing with it. Cakewalk has their reasons and I personally respect that.

I do see others doing their own maintenance of SFZ and it has been extended, and there will be more of it. Although the spec doesn't explicitly say it, all SFZ loading mechanisms naturally ignore opcodes they don't understand. So SFZ is designed to be extended without breaking backward-compatibility. I could make up 438 new custom opcodes, include it in a file, and the SFZ 1.0 Player would still load it. It won't understand my opcodes, but no one should expect it to. The only thing we all miss out on is a nice rejection or warning from the player, like "This file uses extended opcodes that this player does not recognize, your playback may not be fully accurate." The onus is on the user to understand what that particular SFZ is capable of - and this is confusing when you have a library of thousands of SFZ from different sources. That's why it's a shame that SFZ became de facto unmanaged.

Fortunately, the basic SFZ 1.0 and moreso SFZ 2.0 have pretty much ALL the features people expect from a professional sampler. Any extensions are for the geeky one-percenters.

Now, you mentioned a bunch of adjectives - "future-proof", "open", "all-purpose", "primary", "safe".

Pretty much any format meets those criteria. If you composed this library in Giga, it would meet all that criteria. You can convert Giga to any present or future format. Same with anything else - except HALion 3/4 or Independence.

I'm not sure what you mean by "open" - why would it be a concern for you? If the composer wants to do some editing, they simply open it in their playback engine and edits it. If thats SFZ, they use a text editor. If it's Giga, they use Giga if they playback on Giga, if they are converting/loading it into something else, then they edit on that "somethings elses" editor in that engine. (Same with SFZ as it happens.)

You are going to have to advance 15 years into the future where I can imagine someone saying "oh, we don't convert SoundFonts anymore, nobody cares about that". Even if they do, there's still a pathway to convert the SoundFonts into something else.

I wouldn't worry about these things. Concentrate on what platform serves your library compositional needs the best. If SFZ helps you make the library faster, easier, and enhances its quality - use that.

I did... no reply, so I assumed they'd done nothing about it. It would have been around K2/K3 time, so maybe they knew K3 would fix all the issues I reported. But they are annoying not to reply. (There were other things like cross-fades and stuff that simply got dropped. Even simple stuff like the "key=" shortcut was dropped...) At some point I may once more have time in my life to spare..!

By "open" I mean something like PDF, which is an ISO standard.

Why is "open" an important aspect? For the same reasons why DRM is bad. If it's closed, it can expire anytime and your music files stop playing. If it's open, I can hire a programmer to write a custom editor for it, etc. There are no limits to what you can do with an open format, as long as you comply with the published standard.

When you say "dropped", what do you mean by the term? That NI just didn't answer your question, or that Kontakt doesn't respond to it now?

Kontakt should handle any SFZ you throw at it AFAIK. If there's any issues let me know.

Xleth: regarding "open" and "DRM", there isn't any Instrument format that "expires" or is controlled externally like you are saying that DRM does. Only HALion 3/4 and Independence are protected formats, where a programmer would have to figure out the encryption to decode it (which would be unlikely).

Any other format you have total full access to: 1 - 5 - 10 - 20 years from now, without restriction.

I mean that "key=" had no effect (didn't set lokey, hikey and pitch_keycenter), it was as if it hadn't been included. Also, the position of line breaks caused K2 problems in parsing (like each keyword needed to be on its own line). And many, many keywords weren't supported (I think amp_velcurve_NNN was a specific example at the time and, like I say, I'm fairly sure the xf* keywords too -- but that could have been the line break issue). I've not tried since, though, as there has been no information from NI that things have changed.

How did you develop Kontakt export/import in Translator? Did you have to reverse engineer it? What are you going to do about the "protected" Kontakt 5 format (I'm still not sure what the word "protected" exactly means)?

Also, I wonder what made you write that "NI does care about interoperability"? That would be a good sign, if it was true, and a reason to prefer Kontakt. Could you specify what exactly NI did to appear to "care about interoperability"?

Thanks.

pljones: Kontakt today imports SFZ reliably which I suppose is the improtnat issue for today. Concerning back then, I don't remember specifics but I don't immediately recall lots of fuss over SFZ. But again it doesn't matter now.

I do recall and agree that "key" wasn't supported (it is now), Kontakt only looked at lokey and hikey which were far more common. Honestly, I just looked past that parameter and thought "who in the heck is going to use that?" =) It's sort of a lazy parameter and wrongly I was biased against shorthand.

NI doesn't detail the specific changes between versions and builds, but in the main updates it stated something of the effect "imports are updated", they just weren't specific about it. Some companies provide a line-item history, NI doesn't.

Anything now that you find it misses, please alert me, I can do something about it on the spot.

xleth: I apologize, I can't comment on everything because I can't speak for NI, but I can say they recognize the value of interoperability and aren't interested withholding features just to force you to use their product. The quality of Kontakt speaks for itself. NI is a good company and it's certainly nice it's them that has such a quality product. Other companies - and reluctantly I have to say most - don't care for the product the same way. The current Kontakt 5 situation may be temporary, best thing you can do is impress on NI the desire for it. (I'm not sure how that's done, but impress away, I guess!)

Let's be clear, I'm not talking about them publicly documenting their format, but just making it possible to access the details of the format through their stuff or a 3rd-party.

For Translator and other Chicken Systems products, we did reverse the NI formats.

Hey Garth, I really appreciate your well thought out responses. It really is too bad that Cakewalk doesn't want to spend time documenting the format.

The good news is, version 2 has been completely documented in a book (I can't remember the name), and the LinuxSampler guys have taken everything publishable, including everything from the book, along with extensions added by aria as well as their own extensions, and everything is published on their site. It is the most comprehensive collection of SFZ data available on the planet. The funny thing about that is, cakewalk basically said that they never really wanted to keep the format from others, but just never bothered documenting it beyond the instruments they were creating---THEY don't even have it documented properly!!! Ha! Ha!

--Sean

The book is by Simon Cann, called Cakewalk Synthesizers. There's version 1 and version 2 of the book, too (okay, it's in its second edition to keep up with some Cakewalk development that happened after the first edition came out). My understanding is that the view of René and Cakewalk is that no one should "own" the format. It's defined in terms of implementations. Of course, that's a complete pain for inter-operability. But it means that any developer can say "that's a really useful way of capturing the mapping, I'll use it", implement the features they want and, if needed, add a few extra bits.

What exactly does the term "protected" mean with regard to the Kontakt 5 format? Is it encrypted? A USB dongle required? Internet activation?

pljones: Right. Someone should own the SFZ format though - MIDI is owned by the MMA and has full legal rights to change it or alter the spec. The purpose of the MMA is to administer and manage the MIDI spec for interoperability. Right now SFZ is unmanaged which prevents 100% compatibility for the user and coder. But the good thing is that at least something is published and the core remains undefiled.

However, having gone through the spec thoroughly from top to bottom, there is a lot of errata and things that are only resolved through mutual cooperation. These things could have been cleared up a long time ago if there was a managed mechanism that simply said "THIS is the way it is".

Like, what would you do if both "lokey" and "key" were defined in the same region, and they were different values? What if there was a "volume" opcode in the Region, and also one in a Group? The spec says nothing about precedence, nor if ganged opcodes are added or overridden. What about the "transpose"? It doesn't mean what the term means in just about every other sampler, in SFZ it actually means Coarse Tune. But the spec is worded poorly so the only way we know that is through seeing how SFZ Player, or Dimension or Rapture deal with it. But it SHOULD be in the spec. What about naming Regions, or Groups? Nothing.

Additionally, being that SFZ has been around while, and since it's public, there are a lot of poorly written SFZ files created or having the potential of being created. I've seen everything!

Xleth: what I mean by "protected" is that the format has been encrypted in some fashion. That means that unless a team of NASA scientists is involved, no one is going to figure our how to write their own file nor be able to read what a created file says.

Refills and Recycle 2 files are good examples. No one can create these files other than Reason or Recycle because only those programs know how to encrypt them. Recycle 2 files can be read just because Propellerheads released a code library that allows other programs to read them. (That code library does not allow files to be created, edited, or rewritten.) Refills cannot be read, period, there is no code library provided.

That's what I was referring to when you were talking about "open" formats and such. Most formats are not like that, a fairly versed programmer can open the file and find out what it means by some intense research and simple reading. A encrypted format is like someone who scrambles the data and has to be descrambled via a key or passphrase or similar. Just like secure Internet connections, like online banking, where secure information is 128-bit encrypted so no one in the transmission can be listening in.

Users can read SFZ, but they can't naturally read something like Akai or other. Fortunately there are 3rd-party programs (like Translator, or other samplers) taht can read and interpret the data, so they are available to you, thus "open".

That's not what I consider "open". To me "open" means no reverse engineering (let alone breaking encryption) is required to read and write data in the format AND no software from the overseeing body is required to read/write it. Reverse engineering is very much prone to errors.

Good examples of such open formats are: WAV and MID (standard MIDI files).

Only such formats deserve to be called industry standards. Samples and notations can be stored in such open formats (WAV and MID). Instruments so far can't, which is a real shame.
Last edited by Xleth on Sun Aug 12, 2012 8:45 am; edited 3 times in total