A .wt is a vawt wavetable: a fixed 12-byte header, then raw samples -- 32-bit float, or 16-bit if one flag bit says so. The header names the length of one single-cycle wave and how many waves are stacked; the data is those waves laid end to end, frame-major, no interleave. Surge and Bitwig both write this container and disagree on exactly one thing: Bitwig stores int16, Surge stores float32, and only the flags word says which. Neither producer ever varies. The .wt extension is also shared with at least two unrelated formats, so dispatch on the magic, never on the name. Hover any field or byte to light its exact span and read the decode. Color marks kind, the way syntax highlighting does (see the key). Example: vawt + 2048 samples/wave + 64 waves, a real 512 KB float32 table.
Top to bottom, what a reader walks. There is no footer: the file is exactly 12 + frame_count * frame_samples * 2 bytes.
The whole header, drawn below as a byte map. Four fields, all little-endian: the magic, the wave length, the wave count, and the offset where samples begin.
From a 64-wave Surge table. The last field decides how wide a sample is, and it is the one that gets misread.
Immediately after the header: frame_count * frame_samples samples, laid out frame-major. They are 32-bit float unless flag 0x04 is set, in which case they are signed 16-bit. Wave 0's complete cycle comes first, then wave 1's, and so on. No per-wave header, no interleave. For int16, flag 0x08 selects full scale (-32768..+32767); without it a full-scale sample reaches only about +/-16384.
frame_samples is not fixed. 2048 is by far the most common.