Put Alternative Audio Tracks in One Series Review File
Put Alternative Audio Tracks in One Series Review File
Two approved mixes of the same cut, one file, and a reviewer who needs to hear one and then the other without asking which is which. The answer is a container that holds two complete audio programs as separate streams, one of them marked as what plays first, both labelled so the difference is visible before anything is played.
The distinction that carries the whole job: left and right are two channels of one program; the two mixes are two programs. Put mix A on the left channel and mix B on the right of a single track and you have not packaged alternatives, you have built a third thing that nobody approved. Anyone listening on headphones gets two programmes colliding; anyone listening on a phone speaker gets something close to a sum of both. Every note that comes back describes a file that will never be broadcast. Keeping the mixes as streams also means either one can be selected whole, at full quality, with its channel layout intact.
Confirm that both mixes belong to the same picture
Before packaging anything, write down what you actually have. For the cut: its identity as the team refers to it internally — episode, version name, anything that distinguishes it from the previous assembly. For each mix: the source version it was made against, its start timecode, its duration, and where it ends. If you cannot say which cut each mix was built on, the packaging step is premature.
Then compare. A two-second difference in duration is usually not a rounding error; it is either a different edit or a different tail. Decide which before you open a tool. If mix B runs longer because the music carries past the last picture frame, that is a decision someone made and the packaging simply carries it. If mix B is a different assembly of scene 12, no container operation will reconcile them, and the review file would only hide the disagreement.
Do not pad or trim a mix to make lengths match. Padding a short mix adds silence that looks like a technical success and conceals a cut difference that a reviewer needs to know about. Reaching for a trimming flag such as -shortest does the same thing from the other direction: it ends the output when the shortest stream ends, quietly cutting the picture or a mix. If the inputs disagree, fix them upstream — or hand over the two mixes as two files and say why.
Start timecode is the mismatch no later check will catch. Mapping places every stream at the file's zero, so a mix built with an offset — beginning at 01:00:00:00 against a picture that begins at 00:59:58:00, or carrying a head offset of a few frames — ends up against the wrong frames while the stream count, the durations and the default flag all probe as correct. Compare each mix's start timecode against the picture's before you map anything; if they do not share a zero, reconcile the offset upstream or handle it explicitly at packaging, with an input flag such as -itsoffset placed before the -i it applies to. Neither the inventory check nor the tone-to-the-last-frame check can see an offset — one counts streams, the other confirms a stream reaches the end, and neither knows where the stream starts.
The inputs stay untouched. The review file is a derived package built beside them, with a new name; nothing in this workflow overwrites an approved mix.
One boundary worth stating plainly to whoever asked for the review file: this packages alternatives that already exist. It does not translate dialogue, does not create or fix a mix, and does not establish that an audio-described version or a language version is complete. If one of the two streams is a described version, packaging it correctly gets it in front of a reviewer, which is a different thing from the description having been reviewed and approved.
Map picture and complete audio programs explicitly
Treat the job as three inputs and three outputs: one picture, two audio programs.
ffmpeg -i silent_picture.mkv -i tone_1k.wav -i tone_400.wav \
-map 0:v:0 -map 1:a:0 -map 2:a:0 \
-c:v copy -c:a copy \
-metadata:s:a:0 title="TEST SIGNAL 1 kHz" \
-metadata:s:a:1 title="TEST SIGNAL 400 Hz" \
-disposition:a:0 default -disposition:a:1 0 \
review_fixture.mkv
Those numbers before the colon are input identifiers, assigned in the order the -i options appear. Input 0 is the picture, input 1 is the first mix, input 2 is the second. The -map options then take one video stream from the first input and one audio stream from each of the others.
Input identifiers are not output positions. The output audio streams are numbered by the order the audio maps appear on the command line: the first mapped audio becomes a:0, the second becomes a:1. That is why every later label and disposition in the command refers to a:0 and a:1 — the output's numbering, not the inputs'. Swap the two -map lines and the labels stay where they are in the command while the audio underneath them changes places. The mix called Mix B now plays under the title of Mix A, and nothing about the file looks wrong.
-map selects. It is not a hint, and it does not make a stream optional: every stream you map is required in the output. What you leave out simply is not there, and ffmpeg will not treat a missing map as an error. Run the same command with only -map 0:v:0 -map 1:a:0 and you get a perfectly valid file — correct duration, plays without complaint, one audio stream. The second mix was never included. Nor does listing both audio files as inputs without any maps help: with no explicit mapping, ffmpeg's automatic selection takes one stream of each type, so you still end up with a single audio programme, chosen by the tool. This is why mapping is written out in full, even when it feels obvious.
The commands here are written from the documented options and have not been run to produce the outputs described in this article. Treat them as the shape of the operation and check the details against the tools you actually have. Stream copy is the right default for a review file: it moves the approved audio without touching it. But copy only works when the source codec is allowed in the container you chose and the recipient's player understands it. PCM audio from WAV files copies happily into Matroska or QuickTime; the MP4 muxer typically refuses it, which pushes you toward AAC and turns an approved mix into a derived, lossy review copy. That is usually acceptable for review, and it should be a decision rather than an accident. Pick the container from what the recipient uses, then work back to the codec.
Two streams may also carry different channel layouts — one stereo mix and one 5.1 — because they are separate programs. The player may fold the 5.1 down on a laptop, but that is playback, not the file.
Label the alternatives and choose the default
A title is a claim. So is a default flag. Both travel with the file and both are read by people who will not listen to the audio carefully enough to catch a mismatch.
Titles should let someone pick the right stream without opening anything else: which mix it is, and enough identifying detail to distinguish it from its twin. Keep the two names parallel so the difference lands on the meaningful word. Language metadata goes in only where the language is actually known:
-metadata:s:a:0 title="Mix 1 — broadcast, dialogue + M&E" -metadata:s:a:0 language=eng
-metadata:s:a:1 title="Mix 2 — alt dialogue pass" -metadata:s:a:1 language=eng
Where the language is not known, leave the tag off and say so in the handoff note. A guessed tag is worse than a missing one, because some players use it to decide what a viewer hears by default.
Then set the default deliberately, and clear the ones you did not intend:
-disposition:a:0 default -disposition:a:1 0
The trailing 0 on the second stream clears all dispositions from it. Some inputs carry their own tags and dispositions, and those can follow their streams into the output, so set every output audio stream explicitly rather than only the one you care about. If you set nothing, muxers commonly mark the first audio stream as the default on their own, which means the choice was made by the tool instead of by you. That is fine when it agrees with you and silent when it does not.
In the synthetic fixture, the picture is an original twelve-second silent clip, 1920×1080, with a burned-in counter and a slate naming the cut. The two audio inputs are twelve-second mono 48 kHz PCM tone files at 1 kHz and 400 Hz, cut to start and end with the picture. They are labelled as test signals and given no language tag at all, so nobody can mistake a sine wave for an English mix. The fixture exists to make mapping, order and default flags audible; a tone makes a wrong assignment obvious in a second, where two similar dialogue passes might not.
Metadata describes a stream. It does not change the audio inside it, and it does not force a player to show a selection menu — some players honour titles, some show track numbers only, some show nothing and simply play the default.
Inspect the inventory, then use the receiving player
Two checks, in this order, and neither replaces the other.
First, the inventory. Ask the file what it contains rather than trusting the command that made it:
ffprobe -v error -show_streams -of json review_fixture.mkv
The fields to read: how many streams report codec_type of audio (there should be two), each one's codec_name and duration, the tags.title and tags.language on each, and disposition.default — exactly one audio stream should carry it. A schematic of the shape to expect, not a captured transcript:
index codec_type codec_name tags.title disposition.default
0 video h264 (none) default
1 audio pcm_s16le TEST SIGNAL 1 kHz default
2 audio pcm_s16le TEST SIGNAL 400 Hz (none)
If your installed build's probe options differ, adjust them rather than reading the output loosely; the point is to see the count, the identities and the flags from the file itself.
Second, the player the reviewer will actually use. Open the file cold, without touching anything, and note which signal plays. That is the default as the recipient will experience it, which is what the flag was for. Then select the other stream from that player's menu — if it has one — and confirm the label matches what you hear. Select the first again. Seek to the middle and play on to the final passage, and check that the tone runs continuously to the last picture frame without the picture ending early or the audio dropping out. A tone that starts at frame one and stops before the final frame maps directly onto the question you actually care about: does this stream cover the whole cut.
In the fixture, the wrong-order failure is easy to produce and easy to hear. Select the stream titled 400 Hz and get a 1 kHz tone, and the labels are attached to the wrong audio — the mapping order in the command did not match the labelling order. In real mixes that mistake is much quieter: two dialogue passes can sound plausible under each other's names, which is exactly how a reviewer ends up approving the wrong one.
Keep the two failure modes apart, because the fix differs. If the inventory shows two audio streams but the player offers no way to select either, the package is sound and the route is not: try a container and codec the player does handle, or stop fighting it. If the inventory shows one audio stream, the package is wrong, and no amount of player wrangling will find the second mix.
When the receiving route will not expose a selection at all, hand over two clearly named files instead — same picture, one audio each, with the mix identity in the filename alongside the cut name. A pair of files that cannot be confused beats a single elegant container that half the audience cannot open. Say in the handoff which one is which and why, so the fallback reads as a deliberate choice rather than a failed attempt.
Either way, three things have to agree: the title on the stream, the default flag, and the audio actually inside it. Only the third is audible, and the first two are the ones a reviewer reads before deciding.
Frequently asked questions
Why is putting one approved mix on the left channel and the other on the right not a valid review package?
Left and right are two channels of one program; the two mixes are two programs. Combining them that way creates a third thing nobody approved. Headphone listeners get two programs colliding, and a phone speaker gets something close to a sum of both, so notes describe a file that will never be broadcast. Keeping them as streams lets either be selected whole at full quality with its channel layout intact.
What should be confirmed before packaging two mixes into one review file?
Confirm both mixes belong to the same picture. Write down the cut's identity as the team refers to it internally, and for each mix its source version, start timecode, duration, and end. A two-second duration difference is usually not a rounding error; decide whether it is a different edit or a different tail before using a tool. Do not pad or trim to match lengths, and do not use a flag like -shortest.
Why is start timecode the mismatch that later checks miss?
Mapping places every stream at the file's zero, so a mix built with an offset ends up against the wrong frames while stream count, durations, and default flag all probe as correct. Compare each mix's start timecode against the picture's before mapping. If they do not share a zero, reconcile upstream or handle it explicitly at packaging, for example with -itsoffset placed before the -i it applies to. The inventory check and tone-to-last-frame check cannot see an offset.
How do input identifiers differ from output stream positions when mapping?
The numbers before the colon are input identifiers assigned in the order the -i options appear. Input 0 is the picture, input 1 is the first mix, input 2 is the second. The output audio streams are numbered by the order the audio maps appear: the first mapped audio becomes a:0, the second becomes a:1. That is why labels and dispositions refer to output numbering, not inputs. Swapping the two -map lines leaves labels in place while the audio underneath changes places.
What should be done if the receiving player cannot expose a stream selection?
Keep the failure modes apart. If inventory shows two audio streams but the player offers no way to select either, the package is sound and the route is not: try a container and codec the player handles, or stop fighting it. If inventory shows one audio stream, the package is wrong. When the receiving route will not expose a selection at all, hand over two clearly named files, same picture with one audio each, with mix identity in the filename alongside the cut name, and say which is which and why.