Multi wav fileformat?

[Rock Hardbuns]

I was wondering if there are any resonably established file formats out there for samples mapped to keys and velocity layers, and nothing (or little) else.

Preferably just a series of zones (one per sample) delimited by a keyrange and a velocity range (and of course root key and samplerate and stuff).

The idea is to have a file format that can function as a basic building block in a rompler type VSTi. The practice of using soundfonts and stripping out all the irrelevant info doesnt appeal to me.

The need for such a format seems so obvious so there almost has to be something out there, but if there isnt, would you guys be interested in collaborating on a spec?

[Markleford]

So, do you want a format where the zone info and sample data are all embedded in one file? Or just a "mapping" file to be zipped up with individual multi-samples?

- m

[duncanparsons]

well a wav file stores any number of interlaced channels, doesn't it?

For fun, you could use the channels to hold all the different velocity samples, eg:
ch1-2 : sample at full strike
ch3-4 : sample at mid strike
ch5-6 : sample at low strike

Extra tags could probably be put into the file to indicate stuff like whether the samples are stereo, etc. Always have the loudest strike first, and lowest last, then the dev can decide which samples to play at which given velocity - so user defined curves could be brought into play, etc.

Whadderyafink?
DSP

[Rock Hardbuns]

So, do you want a format where the zone info and sample data are all embedded in one file? Or just a "mapping" file to be zipped up with individual multi-samples?

One file preferably.

duncanparsons>>

hmm, that sounds like asking for trouble.What if someone wants a different sample for each key and each velecity.. thats 16K zones.
I think Id be better off making my own. But some sampler somewhere must have a file format for this.

[duncanparsons]

ha!

tbh it was only an idea of a starting place, rather than a full fledged proposal. My idea would be for one note with different layers! Each note-zone would need it's own file.

Your wish for one file will still incorporate something like this anyway - your essentially asking for files within files. If you can get a structure out of jules for Tracktion Archives, you might find what you are after!

DSP

[pljones]

Isn't this what soundfonts do? Multiple note zone splits with velocity layers per split, each triggering a different sample?

[Markleford]

Isn't this what soundfonts do? Multiple note zone splits with velocity layers per split, each triggering a different sample?

I think the idea here would be to abstract a subset of these features found in the SoundFont format such as to make it more useful to any number of other samplers, romplers, and wavetable-driven synths.

For instance, we don't need envelopes, filters, LFOs, etc for this sort of use, so using the SF2 spec would just have a lot of overhead.

Essentially, this "other format" would create a "sample-based oscillator" mapped across dimensions of velocity and key. I was just thinking about doing this sort of thing myself for my synth project, so I'm definitely interested in bouncing some ideas around.

Of course, the first step would be to determine the intended capabilities of this format: after that's done, the legwork of writing it (and leaving it open for extensibility) is pretty easy.

- m

- m

[Rock Hardbuns]

Markleford, its like youre reading my mind.

A the heart of this line of thinking lies a desire to bring back the good old rompler style of sound editing, but with a sharing of sampledata. (And without being locked into a proprietary format, or having to map all the samples up yourself.)

One question is whether to allow for crossfading or not. No crossfading make the data easy to manage, and the spec easy to write. Crossfading increases to usefullness a great deal though.

[Markleford]

One question is whether to allow for crossfading or not. No crossfading make the data easy to manage, and the spec easy to write. Crossfading increases to usefullness a great deal though.

I've never really had much of a use for crossfading, myself: the precision of mixing two samples in the crossover zone is generally sketchy, such that it sounds distinctly like two (quieter) samples in unison rather than a morphing average between the two. (Though Cameleon makes this sound pretty good, but not with samples! )

Exceptions to this are sometimes group unison sounds (like brass or strings) or percussion. Still, it doesn't really get me excited ever!

Best use of crossfading that I've found is to have one sound constant and one mixed in gradually via velocity or keyboard scaling. But that's not really crossfading, even: it's two sample layers, with one with an extreme velocity->amp curve!

Now one thing I'm infinitely more interested in is alternating/randomizing/round-robin of several samples in the same key/vel group! But really, that's probably a bit outside the realm of this idea...

- m

[Midiworks]

Its simple, use the sf2 format and disalbe the
"Articulation" and voila !

Merrry christmas

[Markleford]

Its simple, use the sf2 format and disalbe the "Articulation" and voila !

Well, admittedly, I've only got so far as downloading the SF2 spec docs, so maybe it's easy enough to leave those chunks out...

In which case, what would need to be written would be C++ class that does file IO on SF2s and leaves those parts out on reads and puts in dummy info on writes.

But honestly, sometimes reinventing the wheel can be *fun*!

- m

[thockin]

If you define a meta-data convention, you can use an established format like 'zip' or some other compression that does wav data well (rar?).

You can make a layers.xml DTD format which defines the metadata. Then you just open the zip file, read layers.xml and load the wave files as needed.

A benefit of using actual wave files is that you can use other codecs in wave files. For example, all the wave files can be ogg encoded, if you want to do a low-quality demo version of your file.

Extraction to wave is simple, modification is simple. Simple, open standards, combined together.

<key range="0-5">
<velocity range="0-64">
0_5_low_velocity.wav
</velocity>
<velocity range="65-128">
0_5_high_velocity.wav
</velocity>
</key>
...


This could replace soundfont, if you got enough momentum to knock down Creative

[pljones]

Extraction to wave is simple, modification is simple. Simple, open standards, combined together.

Now this kind of thinking I like. I'd tend to go with ZIP, even it doesn't perform as well as RAR, because I believe there are more portable ZIPfile handling libraries around. And OpenOffice uses ZIP to hold its XML and data collections in exactly this way. I imagine the project would happily provide standards support for the format... OpenSample, anyone?

Using libsndfile, you could support a huge range of sample formats pretty easily (if not entirely transparently - I'm not that familiar with the library).

Using XML, you can define a base level standard - e.g. not requiring a definition of cross-fading - and then add to it later. Old implementations should still be able to understand later versions of the file format because the XML parser should simply drop unknown information.

There are definitely ways the soundfont format could be improved and doing something like this - opening the format right up - is definitely an improvement.

[thockin]

Unfortunately, I don't have much time, and I don't really think it will supplant soundfont, (or the multitude of other multi-sample formats) unless it offers something much better.

[valley]

Using zip and XML is a great idea.

A few ideas I had to allow for safer degradation:

(I'm using a sample mapping method similar to the Yamaha Axxx series samplers - I'm also assuming that only keyboard mapping is an essential standard feature, any degree of layering is optional to the rompler)

A sample container would contain two sections, the primary is a base sample, and the secondary contains extra information and samples for layering. If a rompler only supports a single layer per key it would simply load only the first section, and skip right over the second (and thus not load any uneeded samples either).

If two distinct sample containers are mapped to the same key then the rompler will play as many concurrent layers as it is capable of doing. Priority is given on an order basis. IE if a sample map contains three samples that are all assigned to C3, but the host rompler can only play two layered samples then the third sample container in the xml document will be ignored.

So to slightly alter thockin's example:

<sample>
<primary>
<key range="10-20" upperfade="2" lowerfade="3">
<velocity range="1-64">
0_5_low_velocity.wav
</velocity>
</key range>
</primary>
<secondary>
<velocity range="65-128">
0_5_high_velocity.wav
</velocity>
</secondary>
</sample>

In this form, a rompler that doesn't honour velocity layering (or any sample layering) will simply load only the low velocity sample, and will ignore the velocity range tag in the primary section.

The upperfade and lowerfade properties could perhaps be used to define how a crossfade occurs. In this example the sample is garuanteed to play across the range 10-20 on any rompler, but on romplers that support crossfading would also have a small crossfade range from 7-10 and 20-22. Velocity could also support these two properties.

I've bagged the whole sample up separate from keyrange as you could use this to create multilayer samples in romplers that supported it.

Hopefully some of this makes sense.