Wavetable file format?

[joshb]

Does anyone know of any documentation for, what I assume to be, the common format?

From what I can tell, Serum uses up to 256, 2048 sample single cycle waves in a .wav file. Pretty simple. What I can't figure out is the format to distinguish between separate waves or morphed waves. There seems to be some bytes in the header that are either 0x30 or 0x31 for morphed waves. There's probably more to it than that.

Anyone know where to find this documentation?

Thanks.

[BertKoor]

Common format?? Each to their own....

If the synth maker wanted you to find any documentation, you'd have it already.

[gvamp]

I think the only common format is the mentioned wav file. It's up to the creation software how many samples are saved per wave, most times (not always) it's a power of 2 e.g. 256 - 2048.

[yellowmix]

Serum wavetable WAV files definitely have metadata. If you ask Steve he'd probably tell you the specifics.

[bitcrusher]

This is an example CMNT [edit: oops, not CMNT, 'clm '] chunk from a Serum-created wavetable (.wav) File:

Code: Select all

<!>2048 01000000 wavetable (www.xferrecords.com)

Serum currently assumes 2048 (samples per frame) at all times, so as of now 2048 should always be written there. If someone wants the ability to write 1024 or 4096 frame tables, I could make Serum support that with little effort - maybe drop me a line on xferrecords.com so I can update Serum to support that ability.

Only the two first flags are currently used:

• the first flag is the WT interpolation [0 = no interpolation, 1 = linear crossfades, 2,3,4 = spectral morph]

• the second flag is "Serum Factory WT" which means Serum assumes this file comes with Serum and everyone already has it - thus it will not embed in to user presets to keep file sizes down. PLEASE DO NOT ENABLE THIS FLAG IF YOU ARE CREATING WAVETABLES - please leave it to zero, thank you very much. If you want a similar flag for yourself to identify tables as factory or otherwise for your product, drop me a line and I will reserve you a flag or a different value on that flag.


Warm regards,
Steve

[joshb]

Thank yo very much, Steve!

[Urs]

Hey Steve, thanks for the explanation. I'll happily add this to our wavetable export!

I'd definitely suggest supporting at least 256 samples/frame wavetables. That seems to be the size of choice in Eurorack, and what the free WaveEdit app emits.

We're currently supporting 64/128/256/512/1024 size wavetables on top of 2048 if the user specifies e.g. "-WT256" in the filename. I'm going to implement support for *any* size, so if people know what Hertz their sample is in, they can approximately match frame size to cycle.

This is an example CMNT chunk from a Serum-created wavetable (.wav) File:

Is it CMNT? I always see 'clm ' chunks

[Urs]

Also, I would like to bring up the idea of a unified info chunk for wavetables. We've got our own which stores some information about the table as well as some text we display in an info field. We will extend this with authorship and maybe copyright/license information. Maybe it's possible we can all agree to a set of chunks?

Furthermore, what I'd find totally cool is if us developers could agree on a checksum algorithm/method and info chunk for wavetables. So that wavetables can be identified quickly regardless of file name and location, and don't need to be stored inside presets.

I'm away from office until later his week, but if there's any interest in this I'll happily post what we got so far.

[EvilDragon]

Also, I would like to bring up the idea of a unified info chunk for wavetables. We've got our own which stores some information about the table as well as some text we display in an info field. We will extend this with authorship and maybe copyright/license information. Maybe it's possible we can all agree to a set of chunks?

Furthermore, what I'd find totally cool is if us developers could agree on a checksum algorithm/method and info chunk for wavetables. So that wavetables can be identified quickly regardless of file name and location, and don't need to be stored inside presets.

This sounds really great, if it happens!

[bitcrusher]

Oh, right - 'clm ' not cmnt

I'm totally open for extending this chunk in to more extended "standard" and even try to support some extended features back in to Serum where sensible. When starting work on Serum, I was slightly annoyed having to reverse-engineer a bunch of proprietary WT formats just so I could have some tables to test with. So I used WAV just to be sure Serum wavetables would be open for any other synths, and friendly enough for user homebrew use.

I currently parse the first 10 bytes (<!>2048 XX). As mentioned I even ignore the 2048 right now, but I included that for future-proofing - I'll add other framesize support (0064 to 8192) to the next Serum update (Serum does allow for any framesize on import, just not from a "serum wt" since this chunk only writes 2048 and the only other software writing Serum wavetables (WaveTerminal and Serum table creator by GlowShrimpSoftware) were both writing 2048 size frames.

Cheers,
Steve

[faxinadu]

We've been working lately wavetables and plan an eco system where users can use our wavetables throughout our own products and with others.

I would like to chime in some observations both from wt synth developer side and user as wt creator side.

- WT synths should ideally specify in the documentation if they allow loading user wavetables, and the information regarding the format. This seems trivial but so many wt products lack this, usually i find the info by digging google for forum posts about the synth.

- 2048 is a good way to go, i think. Setting aside technical discussion on the window size, it just seems a bunch of the big synths now conform to this (serum,kontakt,codex,dune etc) as their base standard, why not strive to go with this across all developers.

- There seems to be no one really deep do it all wavetable editor on the market. I have collected a bunch and we have created our own in house one, but I still find myself juggling my files between these dedicated wavetable editors and soundforge as well. Some important features other than the creation itself I find lacking, for example:
- ability to batch process single cycle waves or wavetable files into interpolated windows for other sizes.
- ability to force the cycle starts and finishes to snap to zero-crossing (not just take the first and last sample and aggressively place it on zero, some sort of clean slopping and smoothing, this exists but not adequate and not everywhere).

- If an agreed upon format is used that adds headers this should be totally optional, as this adds another layer of work when creating wavetables that need to conform to products that don't use these.

[WilliamK]

Nice!

[esaruoho]

would be wonderful if, for instance, Surge ( http://surge-synthesizer.github.io ) could support the other formats, too. seems like a wild west when it comes to .wt formats right now.

[esaruoho]

Warm regards,
Steve

Hi Steve.
There's been talk of making it possible for Surge to load wavetables in the Serum wavetable format. I thought, yay, this is pretty hot stuff, and takes no amount of purchases of Serum away from xferrecords, and no amount of purchases of Serum wavetables away from xferrecords/Serum wavetable commercial sellers.

Instead, I get this type of stuff:

"its not legal to do that, considering serum wt are xferrecords IP"

so, what's the endgame on this - if someone figures out how to make an opensource synth like Surge be able to load Serum wavetable content - if dragged in - is that somehow "not legal" due to "serum wt being xferrecords IP"?

[zzz00m]

SynthMaster and SynthMaster One are already capable of loading any wavetable saved in Serum .wav format