open-standards/wai/live-conformance/dred

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

The corpus of 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>