ThePendulum
97cbf38d97
Real bug found on the user's actual file (a ~110min recorded capture), not reproducible with any of our synthetic fixtures: plain ffmpeg -vn extraction just concatenates decoded audio packets and ignores their PTS, so a genuine multi-second discontinuity mid-recording (e.g. a brief audio-device dropout during a long capture session -- common in OBS-style long sessions, unrelated to A/V sync) gets silently closed up instead of preserved as a gap. Every onset detected after that point then gets reported however much earlier the gap was, while onsets before it stay correct -- exactly matching the reported symptom: dead-on for some files, off by several seconds on others, with the 'sort of sound' being irrelevant since it's not about detection quality at all. Diagnosed by scanning the real file's audio packet timeline for non-uniform PTS spacing: found exactly one jump, +1.621s at ~928s in, matching (almost to the millisecond) the 1.6s gap between the source's true duration and what plain -vn extraction produced. Fixed by adding aresample=async=1 to the extraction filter chain, which conforms decoded audio to its own PTS and fills gaps with silence instead of dropping them -- confirmed the extracted WAV's duration now matches the source exactly. This is a different failure mode from the leading start_time offset already handled (aresample=async=1 alone does NOT fix that case -- it re-zeros to its own first frame same as plain extraction, confirmed by testing on the existing OUTOFSYNC fixture), so both fixes now run together in the same filter chain. Verified no regression on every existing single-track, leading-offset, and multi-track fixture.