SigMF is what you get when you apply the raw-PCM-plus-header idea to radio. A software-defined radio dumps a headerless stream of IQ samples to a .sigmf-data file; a JSON sidecar, .sigmf-meta, describes it — a global object (datatype, sample rate, hardware, checksum), a captures list (frequency-tagged segments of the stream), and optional annotations (labeled sample ranges). It is the exact structure of a raw PCM file next to a detached WAV header, which is why an audio tool reads it: IQ is just complex-valued audio. The tabs open the sidecar and the sample stream. This page is drawn from a spec-conformant example (SigMF v1.0.0), not a captured recording. Hover a field to light its bytes, click a field with a + for its table. Color marks kind (see the key).
A WAV file staples its header to its samples; SigMF detaches them. The samples live raw and headerless in .sigmf-data — nothing but back-to-back IQ values — and everything you need to interpret them lives in a separate JSON file, .sigmf-meta. That sidecar has three parts: global (the geometry: datatype, sample rate, hardware, a sha512 of the data), captures (segments of the stream, each tagged with the radio frequency it was tuned to), and annotations (labeled sample ranges — “a signal is here”). The example below is built to the SigMF v1.0.0 schema.
.iq dumps. One open schema for “what is in this pile of samples”..sigmf-meta JSON and the .sigmf-data stream are a pair, joined by base name — exactly like a detached WAV header sitting beside raw PCM..cu8, .cs16, GQRX .raw, PortaPack .C16 + .TXT — the same headerless stream with geometry inferred from the extension, a sidecar, or the filename.sample_rate is the capture bandwidth. The same statistics used on PCM — DC offset, clipping — apply unchanged, which is why RF and audio tooling overlap..sigmf-data file is pure samples — no magic, no offsets, nothing to sniff. You cannot read it without the meta, the same way raw PCM is meaningless without knowing its rate and width. A reader has to anchor on the meta and treat the data plane as the sample stream it describes.sample_start times the datatype's bytes-per-sample is a byte offset into the data file, so a capture (or an annotation) is a real, extractable segment. One tuned segment can be pulled out of a multi-gigabyte capture from offset and length alone.core:frequency on each capture — the center frequency the radio was tuned to (8.428 GHz here). It is why the stream is split into captures at all: a scan that retunes writes a new capture at each frequency, all in one data file.The sidecar is one JSON object with three top-level keys: global, captures, and annotations. The global object carries the fields that make the raw data readable — the core:datatype (sample geometry), core:sample_rate, core:version, an optional core:sha512 integrity hash, and hardware info. All keys live under a core: namespace. The map is the opening bytes of a SigMF meta file.
Plain ASCII. Hover datatype_key — the field that decides how the data stream is read.
core:datatype, the .sigmf-data bytes are meaningless — it alone says whether a byte pair is a complex int16 or half of a float. It must be parsed into a geometry (complex/real, int/uint/float, bit width, endianness) before touching the data. The Datatype tab breaks the string down.core:sha512 is a hash of the entire data file, so a recording is tamper-evident: recompute it and you know the samples are intact. Verification is opt-in in practice — hashing a multi-gigabyte capture is expensive enough to skip by default.The core:datatype is a tiny grammar that packs a full sample description into one token: a required c (complex) or r (real), then i/u/f (signed int, unsigned int, or float), then the bit width, then an endian suffix for anything wider than a byte. The map breaks down ci16_le — complex, signed 16-bit, little-endian, so 4 bytes per sample (two int16 components).
Hover each letter — every character is one decision in the grammar.
cu8 is complex unsigned 8-bit (2 B/sample, no endian needed); rf32_le is real float32; ru8 and ri16_le are the real counterparts; ci16_be is big-endian complex int16. Real and complex both take a leading letter — there is no bare form. The grammar is regular: a type missing its c/r prefix, or a multibyte type without its endian suffix, is invalid.c is why the data stream reads I Q I Q ... — each sample is two components, in-phase then quadrature. That is identical to how a stereo WAV interleaves left and right; here the two channels are the real and imaginary parts of one complex signal.The .sigmf-data file is nothing but samples — no magic, no length, no framing. Under the ci16_le geometry from the meta, it is a run of complex int16 pairs: an in-phase (I) and a quadrature (Q) component per sample, little-endian, back to back. The map is the first two complex samples, decoded with the meta's datatype.
Hover a pair — I then Q, each a little-endian int16. Sample 0 = (−4, 2).
core:datatype resolves it. That is the whole trade SigMF makes: keep the data plane utterly plain, and put every interpretation decision in the sidecar. Lose the meta and you are back to guessing geometry, exactly the problem headerless PCM has always posed.core:frequency has no PCM analogue. One wrinkle: an unsigned datatype is offset-binary, so its zero sits at half-scale — cu8 (the RTL-SDR native format) reads silence as 0x80, not 0x00.