# live-conformance/dred — Opus deep redundancy, decoded exactly

The corpus of [`extensions/opus-dred.md`](../../extensions/opus-dred.md) §9: the integer profile
`dred-int/1` of the deep redundancy (DRED) of draft-ietf-mlcodec-opus-dred-07, decoded from Opus
packets, and streams of packets under seeded loss patterns, each with a record of its
reconstruction and a player's log that presents it.

**Feature equivalence.** A conforming implementation, given the draft's weights file (§4.1),
reaches the outcome each vector states:

- each **payload vector** (`payloads`): its `packet`, in hexadecimal, carries DRED (`outcome`
  `"dred"`), carries none (`"none"`), or is refused (`{"refuse": code}`). For one that carries
  DRED, `dred` states its `frame_offset`, its header (`q0`, `dq`, `extended` or `null`,
  `indicator`, `qmax`), its `dred_offset` (§3.3 step 3), its `latents`, the SHA-256 of its integers
  (`symbols_sha256`, §9), its `rows`, the SHA-256 of every row (`features_sha256`) and row 0 itself
  (`newest`, 20 features at `2^16`);
- each **case** (`cases`) over a **stream** (`streams`, by name): the stream is its `objects` (each
  received packet as a `WAI1` envelope of `wai.audio.opus.packet` in hexadecimal, `null` where the
  packet was lost), its `frame_ticks` (one packet's duration in units of 2.5 ms) and its `loss`
  pattern (`seed`, `enter`, `stay`, §5.1). The case gives the `record` of its reconstruction
  (`weights_sha256`, `lost`, `slots`, `output`, §5.4) and the `player`'s log, each entry the text
  of a signed `wai-player` record (synthesis §10.3). Its `outcome` is `"accept"`, or `refuse` with
  the code and where, `["record"]` or `["player", i]` (§5.5, §7.2).

The file also states the profile's identities: `tables_sha256` (§4.2), and under `lowering` the
constant `exp_c0` and the two activation tables' digests (§4.5) and the two graphs' identities
(§4.6). An implementation that reaches another outcome, code, place, digest, row or identity does
not conform.

**The weights are not here.** The corpus names the draft's weights file by its SHA-256 and holds
no copy. `fetch.sh <dir>` fetches it from the location the draft gives ([DRED-Weights], draft
§7.1) and checks the digest; `fetch.sh <dir> vectors` also fetches the draft's test vectors, which
the measurement of §6 reads (`wai-rs/tests/dred_exact_measure.rs`) and this corpus does not.

**Provenance.** Generated here: `wai_dred_vectors gen <dir> <weights>` writes `vectors.json` from
fixed seeds. Every packet is written by the generator: a code-3 packet of one 20 ms Silk wideband
frame, the frame empty (length 0, RFC 6716 §3.2.1), and the DRED extension in its padding (the
experimental ID 126 with its prefix for one stream, ID 32 for the other). Its DRED indices are
drawn from the draft's own distributions, by decoding a stream of SHA-256 output with §3.3's
coefficient rule at `q0`, and requantized to each chunk's quantizer; the generator drops a final
latent the decoder would not read (draft §3) until the payload decodes to exactly what it holds.
Each loss pattern's seed, and the player's key, is SHA-256 of a fixed label; times are constants;
Ed25519 signing is deterministic (RFC 8032). So every byte is the same on every machine. No
recorded speech: the latents are drawn, not encoded from audio, so the features they decode to
describe no real utterance. The generator asserts that each vector reaches the outcome it states,
and that the corpus gives every reason of §8, before it writes.

**Checks.** `wai_dred_vectors verify <dir> <weights>` and `wai-rs/tests/dred_exact.rs` regenerate
the corpus byte for byte and require no other file here but this README and `fetch.sh`.
`../dred_verify.py`, written from the extension's text and sharing no code with wai-rs, recomputes
every outcome, digest and row in its own integer arithmetic, and requires every mutated copy of
the corpus to fail:

    python3 -I live-conformance/dred_verify.py live-conformance/dred <weights-file>