Audio repair at step 33500 — what it fixed, and what it cost

Ten held-out clips. The two generated columns differ only in weights — same clips, same corrected audio latents, same per-entry seeds.

A trade-off, not a win. The fine-tune was run after a mel filterbank regression (torchaudio norm=None/htk instead of librosa slaney/slaney) was found to have made every encoded target mel 122× too hot. Retraining on corrected latents recovered the audio — and cost about 40% of the video edit strength.

The video drop is caused by the fine-tune, not the regenerated data: the pre-fix checkpoint scores the same on this corrected data as it did on the old data.
Both metrics plateaued by step ~10500 — steps 10500, 14000 and 33500 land within noise of each other, so the extra 23,000 steps changed nothing either way.

Checkpoint trajectory

Every checkpoint on these same 10 clips with the same seeds. Video gap = L1→target − L1→input (more negative = stronger edit); audio = median log-mel correlation vs the pseudo GT.

Per-clip

256×256, 81 frames @ 16 fps (5.06 s), mono 16 kHz, cfg 1.0, 50 steps, no reference frame. Audio scored as log-mel correlation with both sides peak-normalised through the pipeline's own normalize_wav — unnormalised, the −80 dBFS residuals sit on the log-mel clamp floor and the score measures clamping, not content. N=10: enough to see a 40% video drop and a 0.2 audio gain, not small step-to-step wiggles.