open-standards/wai/live-conformance/audio-mark/README.md

# live-conformance/audio-mark — the audio watermark scheme `wai-mark:band64`

The corpus of the registered audio scheme of the second marking layer,
[`extensions/synthesis.md`](../../extensions/synthesis.md) §7.10, of its measurement (§7.10.7), and
of its robustness records ([`extensions/robustness-evidence.md`](../../extensions/robustness-evidence.md)
§10).

**Provenance.** Every signal here is generated: `wai_audio_mark_vectors gen` writes the voice and the
music from fixed seeds (`audio_mark::voice`, a source-filter model, and `audio_mark::music`, a few
synthesised instruments), integer throughout. No recording is stored. The recorded speech the
measured records name (`robustness/measured/speech*.json`) is the test-clean set of the LibriSpeech
corpus of read English speech (Panayotov, Chen, Povey and Khudanpur, ICASSP 2015), licensed CC BY 4.0
(<https://creativecommons.org/licenses/by/4.0/>), fetched from openslr.org/12 as `test-clean.tar.gz`
with SHA-256 `39fde525e59672dc6d1551919b1478f724438a95aa55f874b576be21967e6c23`. It is named here
only by the SHA-256 of each item's samples, read as 16 kHz mono and cut to its first 20 s (or
10 s); its samples are not in this repository.

## Files

- `scheme-band64.json`: the scheme's definition, the bytes whose SHA-256 is the scheme's digest
  (§7.10.1).
- `audio/<SHA-256>.pcm`: the unmarked audio the vectors name, raw S16LE, channels interleaved, each
  file named by the SHA-256 of its bytes: a voice of 7 s at 8 kHz, one channel, and music of 6 s at
  12 kHz, two channels.
- `vectors.json`:
  - `scheme`: the term, the digest, the cosine tables' digest, the shuffle's first and last 16
    entries, the first 16 signs, the mask, and the false-positive bound of §7.10.6;
  - `lg` and `shift`: values of the integer logarithm and of the gain's shift *S*(*a*) (§7.10.2,
    §7.10.4);
  - `embeds`: each stored audio (`audio`), its rate and channels, a payload, the marked samples'
    digest (`marked`), the cells that carried a bit, and each cell's last gain (two bytes each,
    big-endian, in cell order);
  - `detects`: each audio a `source` names, its size and digest, and what the detector reads: the
    `payload`, the `offset`, the `phase` and the `errors` corrected, or `null`;
  - `battery_sample`: every pinned attack of §7.10.7 applied to the stored voice, marked and
    unmarked, at the attack's seed, with the result's digest and what the detector reads;
  - `cases`: cases of §11.1. Their `decoded` and `unmarked` samples are each named by a `source`:
    stored audio (`audio`, with its `rate` and `channels`), optionally marked under a payload
    (`marked`), then optionally transformed (`derive`: a transform of robustness-evidence §4.1,
    its parameters and seed), then optionally with one sample's lowest bit flipped (`flip`). Each
    case states what a verifier gives it, as `live-conformance/synthesis/` states its vectors'.
- `battery-band64.json`: the measurement of §7.10.7's pinned attacks over the generated sets,
  `voice` (16 voices of 20 s at 16 kHz, one channel) and `music` (8 pieces of 15 s at 24 kHz, two
  channels). It holds each item's SNR and segmental SNR, each attack's tallies per set, the
  unmarked items' readings, the statistics of the words the detector reads from unmarked items
  (§7.10.6), the bound, and the attacks every item survived.
- `robustness/`: the scheme's robustness records (robustness-evidence §10).
  - `corpus/`: the corpus documents.
  - `records/`: the conformance record over the two stored sounds, reproduced end to end; the
    records over the generated sets; and their claim.
  - `measured/`: the records of the whole battery, its measured transforms among it, over the
    generated voices and over the recorded speech, with their claim, the measurements they come
    from, the recorded speech's corpus documents, and the unmarked detections over the whole
    recorded set and over generated music (`negatives*.json`).

## The encoder of the measured transforms

The measured records (robustness-evidence §4.2) were run on an arm64 host by
`wai_audio_mark_vectors measure` and `measure-dir`, through FFmpeg 9.0.2 with libopus 1.6.1
(`wai-attack:opus`, application `voip`), LAME 4.0 (`wai-attack:mp3`), and FFmpeg's own AAC, G.722,
G.726 and G.723.1 encoders. Each codec's result depends on its encoder's build, so the records are
stated. The same command on the same builds writes the same bytes.

## Running

```
cd ../../wai-rs
cargo run --release --no-default-features --features robustness --bin wai_audio_mark_vectors -- verify ../live-conformance/audio-mark
cargo run --release --no-default-features --features robustness --bin wai_audio_mark_vectors -- gen ../live-conformance/audio-mark   # regenerate
cd ..
python3 -I live-conformance/audio_mark_verify.py live-conformance/audio-mark
```

Re-measuring needs an FFmpeg-compatible encoder:
`wai_audio_mark_vectors measure <corpus-dir> <ffmpeg>`, and for a directory of recordings
`measure-dir <corpus-dir> <ffmpeg> <name> <audio-dir> <seconds> <count>`.

Pass is byte equality, and every case reaching the outcome it states. A difference is a
conformance failure of the file or the implementation. Report it as a failure, never as close
enough.