ACIDCAT . FILE FORMAT REFERENCE

Analog Lab Bank Anatomy

Arturia Analog Lab.labx . zip + boost
rev 2026.07
magic PK zip
entries STORED
preset Boost archive
lineage Analog Lab 2013

A .labx is an Arturia Analog Lab bank — and under the hood it is just a ZIP. Each entry is one preset, stored uncompressed, its path spelling out the identity: <Engine>/User|Factory/<Bank>/<PresetName>, with a cover image at the top level. The entry bytes are a Boost C++ text-serialization archive — ASCII, length-prefixed strings — carrying the preset's name, bank, author, tags, save time, and engine version. So the whole bank is legible without a binary decoder: the zip census and the per-preset metadata read straight out of the text. The tabs open the zip framing and the archive, drawn byte by byte from a real bank. Hover a field to light its bytes, click a field with a + for its table. Color marks kind (see the key).

Analog Lab is Arturia's front end to its whole V Collection — Pigments, the Piano, the Wurli, and the rest — and a .labx is a bank of presets exported from it. Open it with any unzip tool and you get a folder tree: one entry per preset, its path encoding engine, user-or-factory, bank, and preset name, plus a cover image. Every entry is STORED (uncompressed), and its content is a Boost text archive — readable ASCII. The bank below is a real one, Solstice.

a real bank, laid out
Solstice.labx (a ZIP) 105 presets, STORED ├─ Pigments/User/'Solstice'/90s - Solstice Boost archive ├─ Piano/User/'Solstice'/Low Notes - Solstice Boost archive ├─ Wurli/User/'Solstice'/Accountable - Solstice └─ Solstice.png — cover image (top level) path = Engine / User|Factory / Bank / PresetName
Analog Lab, dated
2013Arturia Analog Lab — one plugin that hosts presets from every Arturia engine, browsable by instrument, type and style. Banks of presets move between users as .labx files.
zipa plain archive. No custom container — .labx is a standard ZIP. The presets are STORED, not deflated, so each entry's bytes sit verbatim in the file.
Boosttext serialization. Each preset is a Boost C++ serialization::archive in text mode: length-prefixed strings, space-separated — legible metadata, not a binary blob.
nowa marketplace format. Producers sell Analog Lab banks; the census (engines, banks, preset count) and each preset's name / author / tags / save-time are all legible, which is enough to catalogue a bank.
the path is half the metadata. Before reading a single byte of an entry, its zip path already gives engine, factory-vs-user, bank and preset name: Pigments/User/'Solstice'/90s - Solstice. the path carries identity and the archive body carries the rest — two sources that cross-check each other. The preset name ends the path with no file extension, so identity comes off the path shape: any entry three or more levels deep is a preset, the shallower ones (the cover) are assets.
STORED means carveable. Because entries are uncompressed, a carve of a preset's byte region is the literal Boost archive — drop it back into Analog Lab and it replays. each preset has a real offset and size, so the bank doubles as a directory of extractable presets.
a cover ships with the bank. Commercial banks include a top-level .png/.jpg cover (the artwork you see in a store listing). It is the bank's cover image, distinct from the preset entries.
signaturePK 03 04method0 (STORED)namethe preset pathdatathe Boost archive

Each preset sits behind a standard ZIP local file header: the PK\x03\x04 signature, a compression method, CRC, the compressed and uncompressed sizes, and the filename length — then the filename and, immediately after, the entry data. The method is 0 (STORED), so compressed size equals uncompressed size and the data is the raw archive. The map is a real preset's local header.

ZIP local file header (30 bytes)

Hover method (0 = stored) and name_len (42 = the preset path length).

method 0 is the whole trick. A DEFLATE entry would need decompressing before you could read it; a STORED entry does not. Analog Lab writes every preset STORED, so compressed_size == uncompressed_size and the bytes right after the filename are the Boost archive. seek past the local header and the metadata reads in place.
the data offset is not the header offset. A zip entry's directory record points at the local header, not the payload — you must skip 30 bytes plus the filename and extra field to reach the data. compute that data offset or an extracted region begins with the PK header instead of the archive.
formatBoost text archiveopensserialization::archivestringslength-prefixedreadas plain ASCII

A preset's bytes are a Boost serialization archive in text mode — the C++ library's human-readable format. It opens with a length-prefixed class name, serialization::archive, then a run of version integers, then the object's fields as space-separated tokens where each string is written <length> <bytes>. the preset name, bank, author, tags, save time and engine version all read straight out of this text. The map is the archive's opening bytes.

Boost archive header (opening 37 bytes)

Hover len_prefix — 22, the length of the class name that follows.

every string is length-prefixed. Boost text serialization writes a string as its byte count, a space, then the bytes — so 22 serialization::archive means “a 22-byte string: serialization::archive”, and 20 Low Notes - Solstice is the 20-byte preset name. That length prefix is how a value containing spaces can be read without guessing where it ends.
the metadata is right there. After the header, the archive lists its readable fields: preset name, bank, author, a comment, a Unix save time, the engine version, and a Characteristics/Genres/Styles tag blob. No decryption, no binary layout — the same tokens a human can read are what land in the index. A forged or truncated archive simply fails to yield them, which is itself the tell.