[lstein]

Summary

Follow-up to #9833, stacked on its branch. #9833 stopped re-encoding the earlier video when a source is trimmed before extending. Its soundtrack was still re-encoded in full: extract_video_range decoded the kept audio and encoded all of it to AAC again. So every extension of a trimmed source cost the earlier audio one AAC generation. The docs' own advice for quality drift, "trim the bridge point a few frames back from the end", made this the common case.

extract_video_range now stream-copies the source's AAC packets for every output frame wholly inside the range. It encodes only a short lead-in before them (unless the range starts at frame 0) and a short tail after them.

• One splice primitive, shared. aac_splice.splice_soundtrack is used by both nodes: an optional lead-in, the copied packet run, an optional tail, then verification. The verification requires a bit-exact copied interior and seams no noisier than an ordinary encode of the same samples. video_concat keeps its behaviour and now calls the same function.
• Each seam stays clean. Every new encode starts 4 frames of pre-roll before its seam, up from 2. Two still left an occasional ~40 ms burst on music, at 8× a full re-encode's error locally. The lead-in and the tail each hold at least 5 frames, which keeps every seam away from the encoder's cold start and its end-of-stream flush. A tail of under a frame had produced a glitch. video_concat uses the same constants, so its audio cut now sits 4 frames before its transition.
• The lead-in is grid-aligned. It is padded so its frames fall on the copied packets' grid, and the padding is hidden by the audio edit list: _set_audio_edit now also writes media_time. A trimmed output therefore skips more than the encoder's priming, and the splice gate now accepts any leading edit at least that long. So a trimmed clip can be trimmed again or extended, and the copy still applies.
• PNS is off (-aac_pns 0) for every soundtrack the app writes, through both the WAV mux path and make_mp4_writer. The decoder fills noise-substituted bands from a random generator whose state carries across packets. A lead-in that used PNS therefore changed how the copied packets after it decode, and verification failed. That happened even on pure tones: with PNS on, 6 of the 8 new trim-audio tests fail. Sources written earlier with PNS on can still be copied wherever their packets verify.

Trimming a test clip before extending it, in each case after the trim:

	Before	After
Source audio inside the range	one AAC generation per extension	bit-identical
Re-encoded audio	the whole range	5–6 AAC frames at each end (≈ 0.1 s each at 48 kHz)

Related Issues / Discussions

Stacked on #9833; merge that first. This PR's base is #9833's branch, so the diff shows only this change.

QA Instructions

• uv run --no-sync pytest tests/app -n 4 -k "video or mp4 or metadata or wan or ltx2 or minimax or h264 or audio": 1680 passed (the ingest tests included).
• uv tool run ruff@0.11.2 check invokeai tests and format --check: clean.
• New tests/app/invocations/test_video_frame_extract_range_audio_splice.py, real ffmpeg. It covers:
  • trims starting at frame 0, mid-clip, and running to the last frame, on tone and on noise content;
  • a bit-exact interior, seams within a full re-encode's error, and an exact container duration;
  • verification rejecting copied audio that doesn't decode back;
  • the Extend chain (trim → join) keeping the source's audio bit-exact.
• Mutation-checked: turning PNS back on, setting the lead-in/tail minimum to 1 frame, or dropping the lead-in padding each fails tests.
• Not run in the browser. To check manually: trim a Wan or LTX-2 clip with sound a few frames back from its end, extend it a few times, and listen across the joins.

Review

Review found no correctness defects in about 300 real-ffmpeg trims, joins and chains, including trim→trim, trim→join→trim and join→trim. Those chains produced leading edits other than 1024 (1232–1824), and every result verified bit-exact against the original source.

Material findings, all resolved:

• Ingest kept PNS on: the upload transcoder still encoded AAC with PNS, so transcoded uploads passed the gate and then usually failed verification. It now uses the same encoder options.
• Silent skip at fractional samples-per-frame: at rates where a frame holds a fractional number of samples (44.1 kHz at 24 or 16 fps, 16 kHz at 30 fps), the trim splice was silently skipped. The trimmed span was rounded independently of the sample window, so it came out one sample off. That also made the full path linearly resample the whole window by ±1 sample. At the source's own rate the window is now used as-is.
• Occasional tail-seam burst: with 2 frames of pre-roll, the seam after an encoded tail occasionally carried a ~40 ms burst on music, at 8× a full re-encode's error locally. The seam check can't see this, because its reference encode has the same cold start. Pre-roll is now 4 frames.

Remaining limitations:

• Older files mostly fall back. Soundtracks written before this change (PNS on), and uploads, usually fail verification on trims that start mid-clip, and are then re-encoded once. That's the previous behaviour, plus a wasted attempt of about 0.4 s on a 5-minute source.
• Seams are not quite as clean as a full encode. For 1–2 frames (20–40 ms) at the lead-in and tail seams, error is still about 2.5–3× a full re-encode's, measured in 512-sample blocks.
• The seam check is coarse. It averages over two frames against a reference that shares the encoder's cold start, so correctness rests mainly on the pre-roll and margins.
• Players that ignore edit lists would start a trimmed soundtrack up to about 43 ms late, instead of the usual 21 ms. ffmpeg and browsers honour edit lists.

Compatibility / Rollout

No persisted-state or API changes. New soundtracks are encoded without PNS, so noisy content gets spent as waveform bits rather than substituted noise. At the default 128 kb/s AAC-LC bitrate this is a minor trade.

Checklist

• The PR has a short but descriptive title, suitable for a changelog
• Meaningful regression coverage added / updated where needed; obsolete tests/code removed
• Persisted-state and API changes include required migrations / compatibility validation
• Relevant performance/efficiency opportunities considered; material claims have evidence
• Material review findings resolved and relevant checks rerun
• Documentation added / updated (if applicable)
• Updated What's New copy (if doing a release after this PR)

---

^{Need help on this PR? Tag @codesmith-bot with what you need.}

[JPPhoto]

Approved.