Its own decoders first. Everything else is routed, and labelled.

One UHD remux of a single title carried six audio streams — LPCM 5.1 at 96 kHz, DTS-HD MA 5.1, a TrueHD 7.1 Atmos track, an AC-3 core, and stereo LPCM and DTS-HD MA. Those are different mixes with different DR, not different encodings of one mix.

With no explicit choice, crête takes FFmpeg's own pick, which ranks by bitrate and channel count. That is reasonable but it is not the container's default flag and not stable across remuxes: on the full file it selects the 13.8 Mbps LPCM track; on a 60-second stream copy of the same six streams it selects the TrueHD one, because the copy carries no bitrate tags. Same audio, different measurement, and originally nothing in the output said so.

Warning: album.mkv has 6 audio streams;
measured stream 2 (PCM_S24LE, 6 ch, 96000 Hz).
Use --stream N to choose.

The chosen index and the stream count appear in the detail output and in JSON, so a measurement is reproducible from its own record. Single-stream files gain no warning and no extra keys — verified byte-identical.

AC-3 and E-AC-3 carry dynamic-range-control metadata and FFmpeg's decoder applies it by default. That is correct for a player and wrong for a meter: DRC is a playback-time compressor driven by authoring metadata, so measuring it means measuring a rendition that is not on the disc. crête pins the DRC scale to zero.

The difference is large and easy to miss.

DR barely moves because it is peak minus RMS and DRC scales both. If crête disagrees with a player's readout, this is usually why.

On one 5.1 bed, leaving DRC enabled moved

There is no Atmos or DTS:X renderer in the chain. What gets decoded is the underlying channel bed — TrueHD 7.1, or E-AC-3 5.1 for Dolby Digital Plus with Atmos — and the object metadata is discarded. crête's numbers for such a file are the bed's numbers, which is exactly what a non-Atmos playback chain delivers, and not what a renderer would produce.

That is a complete measurement of something real, but an unqualified "crête measures Atmos" would be false — so the profile is reported separately from the layout, and JSON carries codec_profile and an immersive_bed boolean. It is identification, not decode, following the precedent MQA detection already set: name the premium layer from an authoritative bitstream field, never imply it was rendered. The field is descriptive — no measured value depends on it.

A non-immersive profile such as DTS-HD MA is reported too, without the bed qualifier: there is nothing unrendered about it. And the profile comes only from the FFmpeg tier, since the zero-dependency binary cannot decode these codecs at all.

Format:   TRUEHD 24-bit / 48000 Hz
Profile:  Dolby TrueHD + Dolby Atmos
Layout:   7.1 · L R C LFE Lrs Rrs Lss Rss
          [bed -- Atmos objects not rendered]

Auro-3D is not detectable this way

FFmpeg reports an Auro carrier as plain DTS-HD MA, so no profile field can see it. On the one disc measured here the "Auro-3D 9.1" label was a container title tag, with the height channels buried in the carrier's low bits — a real signature, since on a solo-piano recording whose LFE is otherwise digitally silent that carrier held 803,853 non-zero samples within ±24 against the DTS:X carrier's exact zero. But reading it is inference rather than a declared field, so if it is ever built it belongs in a confidence-scored forensics namespace, gated off, never in the metrics.

A discrete Auro-3D file is a different case: one PCM channel per speaker, as downloads ship and as the Auro encoder takes them. It declares its layout in its channel mask, and since 0.21.0 crête labels and weights it from that mask — see Standards.

DST is SACD's lossless compression, and multichannel areas commonly use it — on that disc the stereo area is plain DSD at 1.72 GiB while the 5.1 area is DST at 2.16 GiB against the 5.16 GiB it would need uncompressed. crête carries its own decoder, written from the published coding syntax and zero-dependency like everything else, so both areas of a hybrid disc go through the same chain and nothing downstream can tell which the disc used. DST is lossless; this is not an approximation.

Every frame must consume exactly its own coded length, and the decoder asserts it. Arithmetic coding is exact: a decoder consumes the encoder's bits if and only if it applies the encoder's probabilities. That assertion exists because the first version of this decoder was wrong in a way nothing else could see.

It read a comparison from a syntax figure that the clause prose contradicts. Every frame decoded without throwing. Every header parsed to stable, sane values. Mispredictions came out at a healthy-looking 0.75 %. The output was 1-bit data at the right density that decimated to audible sound. It was the prediction filter free-running on its own output, consuming 15 % of each frame.

The two checks reached for first are structurally incapable of catching this. The misprediction rate is low because the decoder consumes few bits, and per-bin probability consistency is vacuous — an arithmetic decoder fed any probability sequence produces events matching that sequence. It proves the coder, not the probabilities.

Frames are byte-interleaved across channels. The other reading — contiguous per-channel blocks — was implemented first and "confirmed" with the obvious test, the left/right split. That test is worthless here: both readings give a plausible DR and a plausible L/R difference, because a wrong de-interleave of a 1-bit stream still decimates to something music-shaped.

What settles it is the property DSD exists for. Byte-interleaved gives the textbook picture — music at low frequency, a quiet 2–20 kHz band, shaped noise climbing above 40 kHz. Blocks give a floor rising at every frequency with no quiet band anywhere. The two are 34 dB apart where it matters.

Two more traps in the same reader produced equally plausible wrong answers. The frame-format value for compressed is zero and the uncompressed forms are 2 and 3, so reading it backwards labels a DST area uncompressed — and DST bytes fed to the DSD path decode to something that still looks like a measurement. And a DST sector's frame header carries one byte more than a DSD sector's, which taken unconditionally overruns the first packet and drops that sector's audio entirely: 14 % of every track lost with no error, 58.65 seconds of a 68.45-second one. Both are now cross-checked, and the header length is read from the sector rather than assumed from the area.

Mean level by band, decimated to 352.8 kHz

Provenance

Both readers are written from the format descriptions — structure layouts and coding syntax are facts about a format, used as documentation. No implementation was consulted: the reference extractor is GPL-2.0, which is strictly worse for an MIT project than the LGPL conflict the DSD engine swap existed to remove, and its DST decoder is a console SPU offload with no software path in it at all. The other software DST decoder available is LGPL. crête stays MIT plus BSD-2-Clause.

Fleetwood Mac's Rumours (2001, Warner) is one title set holding four titles — a 96 kHz 5.1 mix, a 96 kHz stereo mix, a 48 kHz 5.1 version and a one-second tail — 39 tracks across five .aob fragments, and the group boundaries do not align with the fragments. The 6-to-2-channel change falls partway through ATS_01_3.AOB, so even a single .aob can cross one.

Left to itself FFmpeg decodes straight through the change into a resampler configured for the previous format, and reports nothing but a parity-check failure and a timestamp discontinuity on stderr. The numbers stay in range and nothing says they are meaningless. crête stops at the change, measures the first group, names it, and exits 2 — a warning over the wrong numbers would be the silent wrong answer in camouflage.

The probe had the same blind spot one level up: it can read deep enough to reach a later group and report 2 channels for a stream whose first frame is 6. So the channel layout and rate now come from the first decoded frame, not the container — the decision already taken for the sample format, extended to the two fields the probe can get wrong the same way.

Warning: audio format changes partway through
this stream (a DVD-Audio title set holds several
audio groups); measured the first group only,
6 ch / 96000 Hz

Reading the disc's own tables

make dvda-info builds a zero-dependency tool that parses a title set's formats, titles and track lengths without decoding anything — one second on a 4.5 GB title set. On Rumours the track lengths sum to each title's own stated total exactly, on all four titles, in fields held in separate structures; a wrong offset or byte order cannot produce four exact matches. The three format entries agree, in order, with the three groups decoding had already found.

crête does not yet use it to measure per track or per title. Durations do not give byte offsets — MLP is variable-rate — and the table that would is still a hypothesis. A wrong offset into a lossless stream yields audio that plays and a DR that looks reasonable, so it waits for the same arithmetic proof the track table met.