Why does the audio go out of sync with the video in a dual-camera recording?

What keeps audio and video together in any video file

A video file does not store one continuous stream. It stores two: a sequence of video frames and a sequence of audio samples, each stamped with a time relative to the same clock, and a player reads both against that shared timeline to decide what to show and what to play at any given moment. As long as the timestamps on both tracks come from the same clock and nothing downstream disturbs them, the two tracks stay locked together no matter how long the file runs.

Desync, when it happens, is really a statement about the timestamps, not about the sound or the picture separately. Either the two tracks were never stamped against the same clock to begin with, or something after recording — a re-encode, an edit, a playback pipeline with its own delay — shifted one relative to the other.

Why one composited file does not have the classic multi-camera problem

The sync problem most people run into with multi-camera setups is really about two separate files: a front-camera clip and a back-camera clip, each recorded by its own device or its own capture pipeline, each running on its own clock. Any tiny difference between those two clocks compounds over a long take, which is exactly why real multi-camera productions rely on a clapperboard, a shared timecode feed or a sync tone to give an editor one moment both clips can be trusted to agree on.

A dual-camera app that composites in real time never creates that situation. The front and back images are drawn into one frame on the GPU as they arrive, and that one frame — along with whatever the microphone is capturing at that same moment — is what gets written to the file, on one capture session with one clock underneath it. There is no second clip's timestamps to drift against, because a composited recording only ever produces one video track and one audio track, in one file, for the entire take.

Where a real desync actually comes from

Re-encoding on the way out

Messaging apps, social platforms and most sharing tools re-encode a video before sending it, trading quality and sometimes exact frame timing for a smaller, faster file. A normal re-encode preserves sync fine, but a re-encode that gets interrupted — a flaky upload, an app that crashes partway through processing, a share that times out and retries — can leave the two tracks stamped slightly differently than the original. This is the most common real-world cause, and it happens downstream of the recording, not inside it.

An editor exporting at the wrong frame rate

Dropping a clip into a video editor and exporting the project at a frame rate that does not match the source is a classic way to introduce drift that was not there in the original file. The audio track plays at its normal rate while the video track is quietly stretched or compressed to fit a different number of frames per second, and the gap between them grows the longer the clip runs. Matching the project settings to the source before exporting avoids this entirely.

A delay introduced by how you are watching it, not by the file

Some playback paths add their own small delay on one side only — a Bluetooth speaker or a TV's audio processing being the most common culprits — without touching the file at all. This shows up as the same fixed offset from the first second to the last, rather than a gap that grows over time, which is the tell that the file itself is fine and the delay is coming from whatever is playing it.

How to tell which one you are dealing with

Open the original recording where it actually lives — DualCam's own library, or the copy saved straight to Photos — and check it near the start of the clip and again a minute or more in. If it holds up there, the source file is fine and the problem was introduced by whatever you used to send, edit or play the copy you are comparing it against. If a growing gap shows up even in that original, on the device that recorded it, that points somewhere else entirely: heavy load during a long take can make a recording stutter under a fixed 30fps ceiling, and that is worth reading about on its own rather than treating as an audio problem.

DualCam writes exactly the structure described above: one composited video track and one mono audio track, created together and finalized together the moment you stop recording. There is nothing to reconcile afterwards, because the two were never separate in the first place.