When a single person splices two clips together, mistakes are easy to forgive — the artifact lives on a laptop, gets shipped or discarded, and the story ends. When a team concatenates audio, the same operation suddenly touches review queues, asset managers, version control, and downstream automations that do not care that someone flipped the order on Tuesday afternoon. This article is about the engineering and process choices that make a multi-person audio-join workflow behave like a pipeline instead of a chain of one-off hand merges.
If you want the mechanics of one specific browser-based tool, the merge clips locally guide walks through the on-page pipeline in detail. The rest of this article stays at the level of workflow design and is tool-agnostic.
What a Team Audio Pipeline Actually Looks Like
Most teams that think they "just join audio" are quietly running a small factory. A typical newsroom, podcast network, or training-content group has at least four roles touching the same concatenated output:
- A producer who sequences segments and writes a manifest.
- A reviewer who checks levels and edits continuity.
- An engineer who runs the actual concatenation and produces a single file.
- A consumer (a CMS, a transcoder, a broadcast playlist) that ingests the final asset.
The hidden contract between them is the join — the seam between two clips, including any silence, normalization, or metadata that surrounds it. When that contract is implicit, the engineer guesses what the reviewer meant by "tighten the cut," the consumer rejects the file because of a stray ID3 chunk, and the producer resubmits. When that contract is explicit, the join becomes a record, not a guess.
Defining the Join as a First-Class Object
The single most useful change a team can adopt is treating each join as a small data structure, not as a verb someone performs. A minimal join record should carry:
- The ordered list of source asset identifiers.
- The intended silence between each pair, in milliseconds.
- The target loudness (e.g., LUFS) and true-peak ceiling.
- The output container and codec.
- A run id and the engineer who executed it.
Storing this next to the output file (or in the same folder) turns "what is this audio?" from a tribal question into a queryable one. Even a plain manifest.json next to the WAV is enough to make debugging tractable.
For loudness targets, the ITU-R BS.1770 family is the standard broadcasters and streaming platforms normalize against, and EBU R128 is the practical shorthand most teams adopt. Pick a single target — commonly −16 LUFS for podcasts or −23 LUFS for broadcast — and write it into the manifest so the next engineer does not have to reverse-engineer it from the waveform.
Naming, Hashing, and Why "final_final_v3.wav" Is a Pipeline Smell
Concatenation pipelines fail in recognizable ways, and most of them start with filenames. When intro_v2.wav, intro.wav, and intro_FINAL.wav all live in the same bucket, an automated join will happily pick the wrong one and the team will not know until the on-air monitor shows up.
The fix is not stricter naming conventions — those decay. The fix is to compute a content hash of the actual audio bytes and key every join operation on that hash. A SHA-256 of the file, even truncated to its first 12 characters, is more durable than any human-readable name. The MDN documentation on the crypto.subtle digest method shows how to compute this in the browser without external libraries, which matters if your team happens to run joins in a browser tool rather than on a server.
Once assets are hash-keyed, the manifest's source list becomes self-validating. If the bytes change, the hash changes, and any downstream join that referenced the old hash automatically becomes invalid. That is the behavior you want — silent corruption is worse than a loud failure.
The Silence Boundary Problem
Concatenation is rarely just clip_a + clip_b. There is almost always a deliberate gap: 200 ms of breath room between segments, 1.5 s of silence between a sponsor read and the next block, or a hard cut with zero padding. Teams that do not standardize this end up with audible click artifacts, inconsistent pacing, and reviewers who cannot articulate what is wrong because "it just sounds off."
Pick a small, fixed library of silence profiles and reference them by name in the manifest:
-
cut— 0 ms; for back-to-back edits where silence would be wrong. -
breath— 200 to 350 ms; the default for in-host transitions. -
segment— 800 to 1500 ms; between major segments. -
chapter— 2 to 4 s; between chapters or episodes.
If the team agrees on four profiles, reviewers can say "use breath here" and the engineer does not have to guess. The WAV file format itself supports this kind of metadata through its RIFF chunk structure, so a silence-profile name can travel alongside the file as a custom chunk if your tooling supports it.
Validation: What to Check Before the Output Leaves the Engineer's Desk
The cheapest bug is the one you catch before someone else does. A team should agree on a short, mechanical validation pass that runs after every join. The following checklist is deliberately short because long checklists do not get run.
- Duration sanity. Output duration equals sum of inputs plus sum of declared silences, within ±1 sample. Off-by-one errors and mismatched sample rates show up here.
- Peak and loudness. True peak ≤ the declared ceiling; integrated loudness within 0.5 LU of the declared target.
- No clicks at boundaries. Check the first and last 20 ms of each input for discontinuities. A jump from −1.0 to +1.0 across a sample boundary is a click that no reviewer's ear will localize but every listener will feel.
- Hash matches manifest. The output file's hash is recorded next to the run id so the next consumer can verify provenance.
- Manifest is present and parseable. If the JSON will not load, the file is unreviewable, and unreviewable files should not ship.
This is the only checklist in the article on purpose. Teams that adopt it report a sharp drop in "why does the audio sound different in the CMS" tickets within a sprint or two.
Where Engineers Actually Get Stuck in Production
Three failure modes come up often enough to be worth naming.
Sample-rate mismatch. One clip is 44.1 kHz, another is 48 kHz. The naive concatenator picks one, resamples the other on the fly, and the reviewer hears a metallic shimmer on the resampled segment. The right move is to fail the join loudly until the manifest declares a single output rate.
Container assumptions. Tools that "always produce a WAV" are convenient for archival but hostile to consumers that want MP3, AAC, or FLAC. The fact that WAV is a universal interchange format is documented in the WAV entry on Wikipedia, which makes it a defensible default for a first pass — but a team pipeline should encode the target container in the manifest so the conversion is intentional rather than accidental.
Metadata propagation. WAV files do not carry rich metadata by default, but when concatenated into MP3 or FLAC, ID3 or Vorbis comment tags must either be stripped or carefully merged. A common mistake is to keep the first clip's title tag for the entire output, which mislabels the rest of the program in podcast directories.
A Repeatable Workflow in Seven Steps
For a team that wants a concrete starting point, the following sequence is small enough to adopt in a week and rich enough to grow into.
- Agree on a silence profile vocabulary (the four names above, or your own).
- Agree on a loudness target and write it into a team-wide config.
- Hash every input asset at intake; store the hash alongside the file.
- Producers submit a manifest, not a folder of files. The manifest names assets by hash, lists the silence between them, and declares the output container.
- An engineer (or a small script) validates the manifest against the assets, runs the join, and records the output hash.
- A reviewer runs the five-point validation checklist above before approving the output.
- The output and its manifest are stored together; the manifest is the source of truth for what was done.
If step 4 feels like too much process for your team, you are probably small enough that a single engineer can do all of this informally. The article is mostly useful once two or more people are touching the same output and "informally" stops scaling.
Frequently asked questions
Do we really need a manifest, or is a filename convention enough?
Filenames decay; manifests do not, as long as they are stored next to the output. A filename like episode_42_final.wav tells you nothing about the order of clips, the silence between them, or the loudness target. A manifest.json in the same folder answers all three. For a team of one, filenames are fine. For a team of two or more, manifests pay for themselves the first time someone asks "what order were these in?"
What is the single biggest mistake teams make when concatenating audio?
Treating the join as an event instead of an artifact. If nobody writes down what was joined, in what order, with what silence, the team loses the ability to reproduce the output or to debug a complaint. The artifact can be as cheap as a five-line JSON file. The cost of not having it compounds with every join.
How strict should our loudness target be?
Strict enough that two engineers running the same inputs through the same tool produce outputs within 0.5 LU of each other, and not stricter. Targets tighter than that require per-segment mastering decisions that are not the join's job. Pick the EBU R128 number that matches your distribution channel and treat it as a ceiling on variation, not as a value every clip must hit exactly.
Can a browser-based tool fit into this workflow?
Yes, as long as the tool produces a deterministic output you can hash and validate, and as long as the engineer records what they ran. Browser tools are particularly useful for ad-hoc joins and quick reviews; a team pipeline benefits from them when the surrounding process — manifests, hashes, validation — is already in place.
This article was drafted with AI assistance and reviewed for technical accuracy before publishing.
