Create Deterministic Audio and Video Test Files in Your Browser

A random clip can prove that a player opens something. It cannot tell you why a decoder failed, whether a resampler shifted a boundary, or whether a new encoder build changed the output. Useful test media needs a recipe: duration, sample rate, frame rate, pattern, seed, codec, container, and every limit that shaped the result.

The Audio creator and Video creator generate synthetic fixtures locally in your browser. They do not record a microphone, read a camera, upload an existing file, or call a media service. You choose a compact recipe; the workspace renders known samples or pixels; the browser produces an artifact and reports the hashes needed to identify it later.

That makes the tools suitable for parser smoke tests, upload validation, player checks, codec capability tests, and regression fixtures where provenance matters more than cinematic content.

For audio, begin with one or two short tone segments. A one-second mono tone at 48 kHz is enough to test most demux, decode, waveform, and duration paths. Add silence only when you are testing trimming. Add a second channel only when channel order or downmixing is the assertion. Seeded noise is useful for compression tests because it spreads energy across the spectrum, but it is a poor default: it creates larger outputs and makes a visual waveform harder to inspect.

For video, use a short test grid or colour-bar sequence. A moving marker makes frame order and dropped frames visible. An A/V sync recipe adds a predictable tone pulse at the same cadence as a visual event. Keep the first run at 640×360, 30 frames per second, and a few seconds long. Increase dimensions or duration only after the pipeline works.

The workspace checks limits before it allocates large buffers. Audio recipes run from one to sixty seconds and stay under the documented sample and memory ceilings. Video recipes run from one to ten seconds, use the offered 24, 25, or 30 fps presets, and stay within the pixel-frame and output budgets. A rejected oversized recipe is a successful safety check, not an encoder failure.

The result card uses two different claims because browser media stacks are not all deterministic in the same way.

Byte reproducible means the same canonical recipe, implementation version, and pinned encoder path are expected to produce the same output bytes. The PCM container writers and the pinned audio encoder paths use fixed timestamps, ordered metadata, seeded samples, and fixed options. You can generate twice and compare the output SHA-256 directly.

Content reproducible means the source samples or frames, timestamps, dimensions, duration, and requested codec remain the same, while the compressed bytes may differ. WebCodecs deliberately exposes the codecs available in the current browser and operating system. Hardware acceleration, driver versions, and implementation choices can change the encoded byte stream without changing the decoded content contract.

Do not turn “content reproducible” into a weaker-looking badge called “mostly deterministic.” It is a different and honest assertion. For a WebCodecs video, compare the recipe hash and source hash first, then probe the resulting container, codec, dimensions, frame rate, duration, and decoded frames. Comparing only output bytes would flag harmless encoder variation as a regression.

Audio creation always offers the deterministic PCM containers and the pinned encoder formats available to the workspace. Capability-gated formats appear with the result of the current browser check. Video presets are enabled only when the browser can encode the exact codec and the selected container can mux it.

If an AVC-in-MP4 preset is unavailable, the tool does not quietly produce VP9-in-WebM with an .mp4 name. It keeps the requested preset disabled and explains why. That behaviour matters in a test fixture generator: a convenient substitution would make the filename, MIME type, recipe, and actual bitstream disagree.

Some legacy media families remain downloadable catalog fixtures rather than browser-authored outputs. WMA, AMR, WMV, FLV, and other older combinations may require encoders that are unavailable, unsuitable for a local-first bundle, or subject to different licensing constraints. A real existing fixture is more useful than a modern codec hidden behind the wrong extension.

Use this repeatable workflow for each format you intend to keep in a test suite:

1. Select a built-in recipe and change only the property under test.
2. Confirm the capability message names the requested container and codec.
3. Generate once and save the canonical recipe JSON beside the artifact.
4. Record the recipe SHA-256, source SHA-256, output SHA-256, reproducibility tier, and encoder information.
5. Generate the same recipe again in the same environment.
6. For a byte-reproducible path, require identical output hashes.
7. For a content-reproducible path, probe and decode both outputs, then compare semantic properties and source hashes.

The source hash is especially valuable. It identifies the exact PCM samples or raw video frames before compression. If two outputs have the same recipe but different source hashes, the renderer changed. If their source hashes match but their compressed hashes differ on a content-stable path, the encoder or platform changed. Those are very different investigations.

Media generation is heavier than editing JSON. A good browser tool must remain honest when work is canceled or fails halfway through.

Start a larger permitted recipe, cancel it during rendering or encoding, and verify that no download appears. Generate a small recipe immediately afterward. The second job should run in a fresh worker and complete normally. Repeating this test catches stale worker messages, leaked object URLs, retained sample buffers, and encoders that were canceled visually but kept running.

Open the browser network panel before pressing Generate. Encoder modules and WASM payloads should not load merely because the page opened. After generation, there should still be no upload request carrying media bytes. The only network activity should be static application assets and the locally selected encoder code.

Avoid generating every available format for every test. Build a small matrix whose rows each prove something distinct:

• WAV or AIFF for exact PCM samples and channel layout.
• MP3 or FLAC for a pinned audio encode/decode round trip.
• AAC in ADTS and M4A for elementary-stream versus container handling.
• One capability-gated Opus or Vorbis case for runtime feature messaging.
• One MP4 or WebM video for dimensions, timing, and decoded-frame checks.
• One HLS package for ordered manifests, segments, and deterministic ZIP metadata.
• One deliberately unsupported preset to test the disabled-state explanation.

Store the recipe next to each result and link back to the relevant audio fixtures or video fixtures when you need a control authored outside the current browser. A generated artifact is strongest when it sits beside an independently produced reference.

Determinism is not a promise that every browser, driver, and hardware encoder emits the same compressed bytes. It is the ability to explain exactly which parts are fixed, prove the source content was fixed, and detect the layer where a change occurred.

Use byte hashes where the implementation controls every byte. Use semantic media checks where the platform controls compression. Keep capabilities visible, reject unsupported combinations, and preserve the recipe with the result. That is enough to turn a convenient browser generator into a reproducible testing tool.