Does video watermark repair keep an audio track that starts late?

A late stream is different from silence at the beginning

We made a four-second 480×270 animation with 96 source frames, a moving gold pointer, an individual frame counter, three white flashes and a small DEMO mark on a plain patch. Each flash begins at source time one, two or three seconds and lasts three source frames. A generated 1,000 Hz tone pulse accompanies each flash. The footage and sounds are owned synthetic fixtures, not a platform download or a user's quotation.

The 43,928-byte offset input has a genuinely positive first decoded audio presentation timestamp: 0.478 seconds. We had requested a half-second offset during preparation, but we report the timestamp measured from the encoded file, including its codec preparation effects, rather than relabeling it as exactly 0.500. The first audio frame is not the first audible tone. The decoded pulse starts occupy the 1.000–1.005, 2.000–2.005 and 3.000–3.005 second measurement bins on the container timeline.

The 43,596-byte padded control starts decoded audio at zero. Leading silent samples place its three tone starts in those same timeline bins. We verified both encoded files before testing: every source counter from 0 through 95 decoded correctly, every flash was found, and both had three detected audio activity starts. This establishes the intended coarse event relation, not bit-identical AAC waveforms or sample-exact equality between encodes.

Two real downloads from the unchanged tool

We selected each original MP4 in the production tool and checked actual source playback. Both loaded at 480×270 and 4.000 video seconds. For each run, Zone 1 was X 294, Y 95, width 104 and height 40, active from zero to four seconds; Zone 2 stayed off. The repair rectangle covers DEMO without covering the flash panel or counter. Each run reached Ready and produced a downloaded WebM, without an empty-file retry in this pair.

Measure picture and sound on the same saved timeline

We decoded video without manufacturing a fixed output frame rate and retained each actual presentation timestamp. A flash is detected when the mean RGB value in the known white panel, X 50–119 and Y 100–139, exceeds 220. Its sampling bracket runs from the previous non-flash frame timestamp to the first detected flash frame timestamp. The first visible timestamp is also kept separately in the measurement file.

Audio was decoded to floating-point samples at 48,000 Hz without downmixing the saved stereo channels. We read the actual timestamp and sample count of every decoded audio frame. Each sample's position is that frame's timestamp plus its local sample index divided by 48,000. We did not start the late input's PCM at zero, add the stream offset twice or silently concatenate samples while discarding timestamp gaps.

We use global five-millisecond bins. For each bin, RMS is the square root of the mean of squared channel amplitudes over its observed samples. A bin above 0.03 starts detected activity if the preceding bin was not above that threshold. This chosen threshold belongs to our generated pulse fixture; it is not a universal audibility or synchronization standard. The JSON retains the full bin readings and audio-frame timestamps, including overlaps and gaps.

The diagnostic audio-minus-visual span is [audio bin start − first flash timestamp, audio bin end − previous non-flash timestamp]. It combines the chosen bin width with adjacent video sampling. It is not a statistical confidence interval, sample-exact sync measurement or a statement about perception. Saved audio-frame timestamp steps also differed from contiguous sample timing by as much as three milliseconds; that finer uncertainty is retained rather than erased.

Both encoded inputs had an audio bin beginning at 1.000, 2.000 or 3.000 seconds and a first flash frame at that same whole second. Their preceding video samples were 0.958333, 1.958333 and 2.958333. The same method therefore gives an input diagnostic span of zero to approximately 0.046667 seconds for each event. The late-start saved spans move later in this comparison; detecting the tones did not establish unchanged alignment.

The padded control is not a cure

The padded output has audio activity starts at 1.025, 2.025, 2.400 and 3.315 seconds, rather than its source's three starts. Its detected active segments end at 1.150, 2.120, 2.445 and 3.440 seconds respectively. Its three flash first-frame timestamps are 0.968, 2.355 and 3.249 seconds. The second flash is preceded by a non-flash frame at 1.843 seconds, leaving a wide sampling gap.

We retained that output and did not pair four audio segments with three flashes by position or average them into one attractive synchronization number. We did not isolate why the control developed additional separated activity or changed frame spacing. This control prevents us from claiming either that positive audio start is the sole cause or that replacing an offset with leading silence is a verified fix.

Both results decoded completely at 480×270, but video frame counts fell from 96 to 81 and 77. Decoded saved audio contains 192,960 and 204,480 samples per channel: divided by 48,000, that is 4.020 and 4.260 seconds of samples. Actual first saved audio timestamps are 0.032 and 0.016 seconds; the last video frame timestamps are 3.949 and 4.251. Sample duration and timestamp span are different measurements. Neither file is an unchanged remux or a guaranteed exact soundtrack copy.

Inspect the verified late-start source and its actual downloaded result, or the zero-start padded control and retained control result. The full record includes file hashes, all video counters and timestamps, audio-frame records, activity bins and formulas. These files are the evidence behind the answer, not a simulated export.