Private broadcast-audio handoff preflight

Broadcast WAV / BWF / RF64 Batch QC Auditor

Open one file or a complete group of stems. Audit RIFF/RF64 structure, audio-format declarations, BEXT and iXML metadata, exact durations, and cross-file start-time consistency without uploading the audio.

Local batch input

Choose WAV, BWF, RF64, or BW64 files

No files selected.

Up to 100 files, 256 MiB each, and 512 MiB total are read in this tab. Audio samples are not decoded or played.

The teaching pair contains matching 48 kHz, 24-bit BWF stems with BEXT, iXML, and identical starts.

Choose one or more audio files from your device.

This is a structural handoff preflight, not an audio-quality measurement. It does not decode samples, measure peaks or loudness, hear clicks, verify channel identity, interpret ADM, validate every iXML extension, or certify compliance with a broadcaster's delivery specification.

File bytes stay in this browser tab. ToolQuill does not upload audio, production names, originator references, UMIDs, notes, or timecode metadata.

What the batch QC checks

The chunk walker verifies the RIFF, RF64, or BW64 header; WAVE form type; declared container and chunk bounds; even-byte padding; mandatory format and data chunks; duplicate singleton chunks; RF64/BW64 ds64 placement and 64-bit sizes; PCM block alignment; byte rate; whole sample frames; and declared versus actual file length. Unknown chunks remain in the inventory rather than being treated as damage.

How BEXT start time is interpreted

BWF stores TimeReference as a 64-bit count of the first sample since midnight. The auditor divides that exact count by the sample rate declared in fmt and shows the result as a clock. Batch comparison uses seconds, so stems with different sample rates can still be compared without pretending the raw sample counts are equivalent.

BEXT and iXML metadata

The fixed BEXT fields include description, originator, reference, origination date and time, TimeReference, BWF version, UMID, version-2 loudness words, reserved bytes, and optional CodingHistory. For iXML, the tool checks UTF-8 and element balance, disables DTD/entity processing, and extracts common production fields such as project, scene, take, tape, timecode rate, file sample rate, bit depth, and track count.

Validation boundary

A clean result means only that the selected bytes passed the checks implemented here. The page does not hash files, decode compressed audio, scan PCM sample values, calculate programme loudness, validate UMID semantics, enforce a station-specific metadata profile, verify timecode drop-frame arithmetic, inspect compressed BXML/SXML, or fully validate ADM/chna/axml. File-name pairing and editorial intent remain human decisions.

Frequently asked questions

Why is an unknown chunk retained?

RIFF readers are expected to ignore chunks they do not understand. Private and vendor chunks can be legitimate, so the auditor maps them and checks their declared bounds without guessing their payload semantics.

Why can matching stems still show different durations?

A one-frame or one-sample edit, tail, handle, export setting, or malformed size declaration can change duration. The report gives exact seconds and underlying sizes so you can decide whether the difference is intentional.

Can this repair a damaged WAV header?

No. This tool is deliberately read-only. It identifies the failed declaration and byte offset, but does not rewrite sizes or audio files.

Authoritative references

EBU Tech 3285 defines BWF and the BEXT fields. ITU-R BS.2088 defines BW64 and its ds64 model; the EBU's Tech 3306 page explains RF64's transition to that recommendation. Microsoft's RIFF overview documents FOURCC chunks, payload sizes, and word padding.

Browse audio and broadcast tools · Calculate video timecode