A Bitwig preset is not audio. It is an ASCII BtWg header, a big-endian self-describing metadata block, an opaque device tree, and, when "embed files" was on, a ZIP archive of the referenced assets. The same container backs .bwpreset, .bwclip, and .bwmodulator; everything below is field-verified against real Bitwig Studio 6.x files. Hover any field to light its exact bytes and read the decode; click a field with a + to open its table. Color marks kind (see the key).
Top to bottom, what a reader walks. The metadata a producer wants sits right behind the header; acidcat inspect (and inspect --pretty) decodes it and flags the embedded-asset zip.
All ASCII: the 4-byte magic, ten format/version digits, then a run of hex digits. Careful with the family: .bwimpulse is not this container at all, it is a plain FLAC file.
A list of key/value entries, each one self-describing: a u32-BE length and that many ASCII key bytes, then a type byte (0x08 = string), a u32-BE value length, and the value bytes. One worked entry is drawn below: device_name = "Drum Machine". The keys, in order:
The Grid and device graph: a nested CONTENTS/MODULES/N/CONTENTS/... structure holding every module in the patch. acidcat v1 leaves it opaque; the meta block already carries what the browser needs.
With "embed files" enabled, every referenced asset is packed into a DEFLATE ZIP embedded in the preset. Unzip it and the referenced files come back whole. acidcat inspect flags the archive when it is present.
Not this container, but from the same writer: audio bounced out of Bitwig carries its own tempo trail in the WAV.