07 Audio recovery and alignment

Automatic audio recovery is the primary path: the phone decodes the recording's raw AAC itself. Manual import and alignment is the fallback for audio that will not decode. This chapter covers both, in that order.

Two separate problems

1. Decoding. Turning the bytes that survived into a playable audio stream. The recorder wrote raw AAC access units back to back with no framing, and the index that held their lengths was lost. This is the problem the app solves automatically, and it is solved on the phone itself.
2. Synchronisation. Once a playable audio stream exists, deciding when it starts relative to the video. This is what the offset slider does.

Moving a start time never makes undecodable audio playable. Alignment runs only once decoding has produced a playable track, or after you import one.

Path 1 - Automatic recovery on the phone (primary)

1. On the Recover tab, select the broken recording, and mark a playable recording from the same phone as the reference (chapter 06, step 2). The reference supplies the recording's AAC configuration; without it the engine reports that it has no audio configuration to work from.

2. Open the Audio tab and press Recover audio from the recording.

3. What happens: the engine decides where the audio region is, the phone's MediaCodec decoder consumes that region as one unframed buffer, and the app writes the decoded result as an ADTS file. The log then says the recovered audio "is ready to align with the video and will be muxed with the signed offset when you rebuild."

4. Continue with the alignment steps below, then press Rebuild with the recovered audio to mux it into the repaired video with your chosen offset. The button names whichever audio it is about to mux: the recovered audio for a track the app recovered from the recording itself, and this user-supplied audio for one you imported.

   Until 0.3.0 this step did not work for recovered audio. The app recovered the track, then disabled the offset slider, refused the preview and offered no way to rebuild - it asked about imported audio and ignored the recovered kind. Both now count, and the whole path is covered by an instrumented test that checks the written file actually carries an audio track.

Why the app hands the whole region over in one buffer: on device, a single unframed buffer decoded 88 of 88 AAC frames (90112 samples from 12296 bytes) on a Galaxy S25 Ultra (SM-S938B, Android 16, codec c2.android.aac.decoder, measured 2026-10-12). Offering the same bytes in 4096-byte chunks returned only a third of the samples, and offering ADTS input while a codec-specific-data field was set returned nothing at all. The winning framing is therefore one unframed buffer, and the app uses it.

Path 2 - Import audio you already have (fallback)

Use this when the recording's own audio will not decode - for example the audio bytes were never flushed, or the file was made by an app whose audio configuration the reference cannot supply.

1. Press Import audio and pick any playable audio file: a voice memo, a second recorder, an exported track.
2. Align it as described below, then rebuild.

The app will not invent audio. When a region cannot be decoded it reports that explicitly instead of writing a silent track, and the log suggests importing a recording of the same session if you want to align one by ear.

Aligning the audio

1. Press Preview alignment (available once a playable track and a selected recording exist). The video plays muted while the aligned audio plays over it, so the offset is the only thing you can hear.
2. Adjust the offset: the slider covers about plus or minus two seconds, and -50, +50 and Reset offset step it precisely. A clap on camera or any sharp sound is much easier to judge than lip movement.
3. The readout shows video position, audio position and the offset in milliseconds. Positive means the audio is held back to start later; negative means its head is trimmed so it starts earlier.
4. Press Rebuild with the recovered audio or Rebuild with this user-supplied audio, whichever the button says. The offset is written into the rebuilt file as an MP4 edit list, not by padding silence.

What alignment can and cannot fix

• It fixes a constant offset. If the whole recording is uniformly out by the same amount, one offset makes it right.
• It cannot decode anything. If the audio has no recoverable frame boundaries and you have no playable copy, alignment has nothing to move.
• It cannot fix drift. If the audio and video lengths differ because frames were lost mid-recording, one offset lines up the start and gets progressively wrong towards the end.
• It cannot invent missing audio. Parts that were never flushed to disk are gone.

The same work on the desktop

The desktop Audio tab exposes the same two paths with the managed decoder: Scan for audio regions, then Decode + preview with an offset slider and text box, Play and Stop. A separate section takes audio you already have and aligns it ("Align supplied audio to ms"). Export aligned audio writes both an aligned .m4a and the ADTS .aac the engine's muxer accepts, and Mux into repaired video (keeps full video length) combines them with the repaired video. The desktop lab run verified signed offsets sample-exact (a positive offset of 500 ms moved the audio by exactly 22050 samples; a negative offset of 250 ms trimmed exactly 11025).

What was not re-run for this manual

The Android alignment preview and the rebuild with a non-zero offset were not re-exercised on a phone while this manual was updated: they are described from the frozen UI source and from the unit and engine tests that cover the offset arithmetic and the edit-list muxing. Treat the visual behaviour of the preview (muted video, live positions) as source-verified but not screenshot-verified.