The Future of the SFZ Format

Sampler and Sampling discussion (techniques, tips and tricks, etc.)
Post Reply New Topic
RELATED
PRODUCTS

Post

larm wrote:
davidv@plogue wrote:For some developers, the interest in the format is mainly as an insurance policy that their mapping/editing hard work will still be human/machine readable in 10 years or more, something that obviously cannot be said about much of the other 'closed' binary formats, however cute and efficient their graphical editor may be.

I think if an SFZ is wrapped, hidden or otherwise severely obfuscated for protection reasons it should not be called SFZ.
I 'rescued' a lot of samples from an old sample cd into 30+ sfz files. Did a dir *.wav piped to a text file, then some smart search and replace (NotePad++) and copy/paste to different text files. Could then import the sfz to the sampler and continue from there and save in native formats.

Instead of having to mess with a mouse and some custom file selector for 100+ .wav files the human readable text editing and the batch processing was a time/life saver. In this case I used the sfz format much like a .csv file.
It's one of those things where it's great where it works, when the heavy lifting is already done (or there is no heavy lifting to be done). For the creation of instruments from scratch though, particularly more involved ones, I just wonder if there's not something better to be had, or does the format as it is truly defy the nature of such tools. It probably does, but getting heads together and mulling it over in the laboratory of thought might be beneficial to some extent all the same.

Post

Maybe a large SFZ project that would be very useful, require quite a few people to accomplish, but mostly use fairly basic opcodes would go a long way towards building some community and cooperation.

An SFZ orchestra would be an example of such a project, but since Sonatina already fills that void, how about a jazz/Latin big band?

Post

stanlea wrote:Maybe one major issue of sfz is that it's not a closed format. How do you protect sfz banks ?
I can see why some developers would go that way, but honestly, the protection on other formats is pretty imaginary. Pretty much all the Kontak libraries are out there warezed.

Encryption would kill the open SFZ format dead. The main draw for SFZ is that it is open. You can take SFZ file and load it to Directwave, Dimension, Rapture, Alchemy or any other synth or sampler and use it as a basis for new sound design. You can use SFZ files easily for layering or you can lift out individual samples out of SFZ files and use them for the basis of new instruments. It is a very easy format for transfering sounds from one synth to other synth and back.
No signature here!

Post

Only mandatory encryption would kill it.

Post

metamorphosis wrote:Only mandatory encryption would kill it.
Which is the same as saying an encrypted file isn't an SFZ file, really. I mean, if you can't decrypt it, you don't know it's SFZ, so it might as well not be.

Post

DSmolken wrote:Maybe a large SFZ project that would be very useful, require quite a few people to accomplish, but mostly use fairly basic opcodes would go a long way towards building some community and cooperation.

An SFZ orchestra would be an example of such a project, but since Sonatina already fills that void, how about a jazz/Latin big band?
Sonatina partly inspired my initial rambling missive in the OP, as I was perusing its various instrument mappings and realized how spartan/simplistic they are. Obviously just gathering the samples and fine tuning them at that level so as to give them a sonic unity was a huge undertaking for the author and the project deserves every bit of the appreciation it gets, but as a demonstration of the format's potential, it'd be almost too generous to say it even scratches the surface. Being fair, the author disclaims in his write-up that it wasn't to be as ambitious as commercial offerings and such, but it just had me wondering if doing anything more "ambitious" in SFZ is just too much of a pain in the ass in the first place. Does its openness and readability retard its viability for more advanced applications? Being generally out of touch with what's going in the commercial realm, are there any notable offerings that are pushing the possibilities of the format? Or any free ones for that matter that might have slipped my radar?

I really think the idea of a jazz-oriented project is a great one, but maybe instead of aiming simple, the goal could be to really push the format (using the 1.0 standard of course) to its limit by trying to render as organically and usably as possible each instrument, playable articulations and all, with as few samples as possible.

It'd be interesting too to have contributers offer up a little overview of their processes for creating the mappings. For instance, auditioning while editing is one of the things about SFZ that I find extremely off-putting--I don't know if some of the more robust plug-ins or conversion tools offer a more streamlined experience, but "1) edit in text file 2) save text file 3) reload in plugin 4) bang midi keys for a bit 5) repeat" gets tedious when working at the fine details, the part that turns a collection of samples into a true virtual instrument. It'd be interesting to hear how people deal with issues like that while neck-deep in the opcodes necessary to achieve an ambitious SFZ mapping.
pljones wrote:Which is the same as saying an encrypted file isn't an SFZ file, really. I mean, if you can't decrypt it, you don't know it's SFZ, so it might as well not be.
This sort of evokes a question that was floating around in my head while I was rambling, but couldn't quite articulate in previous go-arounds: is SFZ just a format then, or is it too a programming language? I can program something in C++, for instance, and you'd say its a C++ program, but not necessarily a Windows program, or a Linux one, or Mac, etc, which would (I think?) more or less determine its "format" as a particular executable for a particular platform. Does the fact that its compilation to a binary format that obfuscates its origin change the fact of its origin being C++ source files, with standard includes and all that? Does it make C++ less useful a language? So what if, theoretically, you could write up your instruments in the SFZ language and then compile it as another format (eg the hypothetical SFZ-Protected or Super SFZ or whatever) with a theoretical SFZ compiler? Can SFZ (or maybe an evolution or of it) form the core of such a source language, somewhat more separate from its utility as a readable/editable, simple means of playing back samples? Perhaps that conflating two basic questions--there's the question of how the SFZ format might be made easier to use "as-is," then there's the question of how SFZ might be adapted into something more advanced, with perhaps a different purpose than its original...

As I said earlier, having at least a simple level of standardized abstraction of some kind attached to the meat and potatoes SFZ would be really cool, but I can see too that beyond a point it might become a bit self-defeating--why bother programming your instrument in SFZ when you could code up in another language a VSTi rompler, etc. That's all probably beside the point anyway. Considering some of the fairly elaborate offerings of even some free VSTi romplers and Kontakt instruments out there, it just comes back to asking, why aren't there more sophisticated SFZ offerings? Again, I'd love to hear of any that truly impress on the programming level--maybe a list, a ranking of the best of the best, which SFZ instrument can we hold up as the pinnacle of its format, to which others should aspire? Or does the format just make it too cumbersome/tedious/complicated/time-consuming to pursue the deeper aspects that produce these sort of gems? Is SFZ content to linger in a self-imposed mediocrity? And if so, can it something be done to improve that, without seriously compromising its openness and simplicity?

Feels like I'm chasing my own tail thinking about each aspect of it and how it impacts other aspects. But that's why I'm so fascinated, too; it has a sort of Schrodinger's Cat-ness about it still, as if we're seeing it in its super-state, dead, dying, living, thriving all at once. Maybe that's just the way it should be?

Post

infectedpimple wrote:This sort of evokes a question that was floating around in my head while I was rambling, but couldn't quite articulate in previous go-arounds: is SFZ just a format then, or is it too a programming language?
No, its solely a format. Its a description of data, not a means of manipulating the data.
I can program something in C++, for instance, and you'd say its a C++ program, but not necessarily a Windows program, or a Linux one, or Mac, etc, which would (I think?) more or less determine its "format" as a particular executable for a particular platform.

Does the fact that its compilation to a binary format that obfuscates its origin change the fact of its origin being C++ source files, with standard includes and all that? Does it make C++ less useful a language?
Im not entirely sure what you're trying to say here, to be honest. Source code has to be compiled into executable code suitable for its target system for it to be executable on that target system. Im not sure what the 'origin' of that, or 'usefulness' of that comes into the equation. C++ code can be developed on one system and compiled for a completely different target system, or several target systems; those possibilities are not defined by the development system, though, they're defined by the C++ compiler. It might be impossible to test on the development system, but that's not the point.
But this has nothing to do with the the sfz format whatsoever.
So what if, theoretically, you could write up your instruments in the SFZ language and then compile it as another format (eg the hypothetical SFZ-Protected or Super SFZ or whatever) with a theoretical SFZ compiler?
To me, you're sort of conflating the notion of a language compiler with a data translator here. You wouldnt 'compile' sfz files because they dont describe program behaviour, just data organisation. You might transliterate them into a protected format, but that's not the same thing as compiling a programming language, and theoretically you could bundle them up with some working code into something executable, but it would be the code you bundled it with that would be responsible for the program behaviour, including interpreting the sfz data.

Try thinking about it the way you'd think about any other purely descriptive data format : would you talk about 'compiling' a wordprocessor document into an executable program, or would you expect to open it in a word-processor.


Can SFZ (or maybe an evolution or of it) form the core of such a source language, somewhat more separate from its utility as a readable/editable, simple means of playing back samples?
Some theoretical evolution of it could, I guess. But it currently doesnt.
Perhaps that conflating two basic questions--there's the question of how the SFZ format might be made easier to use "as-is," then there's the question of how SFZ might be adapted into something more advanced, with perhaps a different purpose than its original...
I'd question why you'd want to do the latter (cf 'compilation') without completely negating the point of sfz
it just comes back to asking, why aren't there more sophisticated SFZ offerings?
I'd hazard the fact that there are various reasons. But the fact that sfz is an open standard allowing use by multiple tools means that multiple tools use it; the result of that is going to be that those different tools use it in different ways (ie different synthesis engines), and hence to get a specific degree of 'sophisticatation', a set would need to built with a particular tool in mind. And that makes the engine more important than the data format. When the engine becomes the primary focus, then why prioritize sfz in the first place if there's a 'better' choice of engine.
And bear in mind that many of the tools using sfz sample sets dont actually use sfz as their preset format; the tool-specific stuff is contained within their own preset information. sfz describes the sample set data, but not the audio engine data.

sfz has two types of 'utilisation' benefits, as I see it. For developers, it gives them a defined target for sample sets which they can utilise in their synth engines, which saves them having to design such a thing from scratch. For users who dont just use presets it means they can reuse a certain amount of sample design work out there even if its not targetted for their specific tools (which is a selling-point for the tool developer).
my other modular synth is a bugbrand

Post

Can Sfz read the loop points of wav files automatically or you have to tell the Sfz file that he have to read them in a certain way?

From my experiment, it's a very limited format. I begin to understand why Kontakt is so popular. Even Wusikstation has more to offer...

Post

SampleScience wrote:Can Sfz read the loop points of wav files automatically or you have to tell the Sfz file that he have to read them in a certain way?
Again with the "can SFZ do". Its usually an implementation matter. If we say the reference is sfz.dll and Dimension Pro, then yes, they both take the wav smpl chunk (or similar) as the region defaults for loop_start/loop_end and loop_mode.

This is sadly not explicitly written in the SFZ 1.0 spec. I think its obvious that what's needed is proper public documentation and a nice FAQ.
Last edited by davidv@plogue on Sun Apr 06, 2014 2:51 pm, edited 1 time in total.
David Viens, Plogue Art et Technologie Inc. Montreal.
https://twitter.com/plgDavid
https://plogue.com

Post

SampleScience wrote:Can Sfz read the loop points of wav files automatically or you have to tell the Sfz file that he have to read them in a certain way?
The sfz file is a set of settings. You dont 'tell' it anything, the sfz file exists to tell something else stuff. The something else can do whatever the hell it likes with the information in the sfz file.
From my experiment, it's a very limited format. I begin to understand why Kontakt is so popular. Even Wusikstation has more to offer...
You just compared a sampleset format to a sampler and a synth. That makes no sense. Might as well complain that Reaktor has more to offer than a .wav file.
my other modular synth is a bugbrand

Post

infectedpimple wrote:Being generally out of touch with what's going in the commercial realm, are there any notable offerings that are pushing the possibilities of the format? Or any free ones for that matter that might have slipped my radar?
Did you check my Analogue Drums Tape Series 2 mappings? David looked at them and jumped a bit... ;) (OK, they're not much use to you if you don't have the samples but this thread is about the format.)

Post

infectedpimple wrote: For instance, auditioning while editing is one of the things about SFZ that I find extremely off-putting--I don't know if some of the more robust plug-ins or conversion tools offer a more streamlined experience, but "1) edit in text file 2) save text file 3) reload in plugin 4) bang midi keys for a bit 5) repeat" gets tedious when working at the fine details?
It doesn't have to be this way. sforzando monitors the file for changes and automatically reloads it. So you can at least skip step 3).
Note 2) can be easily dealt with a 'CTRL-S' while editing.
infectedpimple wrote:Considering some of the fairly elaborate offerings of even some free VSTi romplers and Kontakt instruments out there, it just comes back to asking, why aren't there more sophisticated SFZ offerings?


We've converted at least 3 major Kontakt based library to SFZ/ARIA: Garritan's Personal Orchestra, Jazz and Big Band, and Concert and Marching Band. In fact many of the "ARIA SFZ Extensions" to SFZ 2.0 were created to help this transition and to fill some 'oversights' in the spec. An oversight might be too strong of a word, its hard to define a specification when you have your needs and only your needs in mind. I see SFZ as something alive and evolving. I'm not one to think SFZ 1.0 is an end all and everything should target its strict definition set.

Indeed pljones has been pushing the envelope with his mappings, using (and not abusing), features like the C++ style's #define and #include statements in a very judicious and flexible way.
David Viens, Plogue Art et Technologie Inc. Montreal.
https://twitter.com/plgDavid
https://plogue.com

Post

AUTO-ADMIN: Non-MP3, WAV, OGG, SoundCloud, YouTube, Vimeo, Twitter and Facebook links in this post have been protected automatically. Once the member reaches 5 posts the links will function as normal.
I don't know if any of you have noticed but one of the primary uses of the SFZ format is simple key-mapping of folders full of WAV files so that they can be imported into soft-samplers or sample converting programs like Extreme Sample Converter. This common usage does not require "in-depth" features from SFZ but it takes advantage of Windows Batch Scripting being able to write information to a text file.

One at the forefront of this "movement" is KVRAudio Member Carrieres from France who made SFZ Program Editor (http://carrieres.free.fr/sfz.htm).

I personally use the SFZ format a great deal in "ripping via autosampling" WAV files out of proprietary formats (e.g., SampleTank 2) so I can build my own library of SoundFonts (SF2s). The crucial step for my need is being able to keymap the WAV files to an SFZ quickly using Windows Batch Scripting so it isn't too time-consuming for me (which it could easily be considering there are >5000 instruments in SampleTank 2 libraries I've purchased). Then Extreme Sample Converter can convert SFZs to SF2s for me and I have my instruments in a format of my choice (and I can edit the WAV samples along the way too (e.g., make them mono so they take up half the HDD space)).

For this use (which is extremely important to my workflow), SFZ doesn't need in-depth features. It really only needs keymapping and other basic things like changing "loop_mode" and ADSR envelopes.
Last edited by trillnox on Sat Jun 21, 2014 2:38 pm, edited 3 times in total.

Post

I have been delving into SFZ, mapping a couple of the University of Iowa samples amongst other things. (Thanks to pljones for inspiration and help on your website!) My impression so far is that I'm not limited by the SFZ format; I'm limited by the samples (and by my meagre expertise). The Iowa samples for example are rather short, not divided up logically and the volume's not normalised. What you can do with an sfz mapping is very strictly limited by the samples that were recorded, and I assume that the Sonatina project was similarly limited by the samples that happened to be at their disposal. (The creator says that they found the samples from various free and open sources, including the Iowa ones.) Also, Sonatina's goal was much broader - to create a free and open sampler for a large number of orchestral instruments, and I imagine that the project limited its scope and ambition so that it could focus on including as many instruments as possible in one lean package rather than meticulously crafting an individual instrument to the finest possible quality.
davidv@plogue wrote: It doesn't have to be this way. sforzando monitors the file for changes and automatically reloads it. So you can at least skip step 3).
Note 2) can be easily dealt with a 'CTRL-S' while editing.
I noticed this, and I appreciate it! My way of working is exactly that: edit the file, save, play some notes to test. I don't have experience working any other way. If there were a graphical interface for this purpose I can't see how it would be any quicker because ultimately the same information has to be entered regarding regions, velocity and pitch ranges etc. A text editor seems to me to be perfectly good enough already for this purpose.

Post

trillnox wrote:For this use (which is extremely important to my workflow), SFZ doesn't need in-depth features. It really only needs keymapping and other basic things like changing "loop_mode" and ADSR envelopes.
Totally agree! It would be more than enough to make it compatible with a wide range of soft samplers. Load the sfz and ad whatever effects you have at your disposal on your sampler of choice.

Post Reply

Return to “Samplers, Sampling & Sample Libraries”