Stem Sync, and the Autopsy of Two 7-Hour Chats
Measured from Brandon's own files, 2026-07-19. Two parallel sessions burned ~14 hours on one jam. Here is what broke, why the stems still line up, and how to get the ones that matter.
A band recording got split into separate tracks for each instrument by two different computer programs, one after the other. The worry was that the drum tracks and the guitar tracks would not line up in time. Good news: they line up perfectly. The bad news is two chats took way too long and fought with themselves instead of just doing the job.
1. The question you asked: how hard are these to sync?
Answer: not hard at all. They are already sample-locked.
Guitar and bass come from pass 1 (Demucs 6-stem) on the song cut. Kick, snare, toms, hihat, cymbals come from pass 2 (DrumSep MDX23C) run on pass 1's drums.wav. Two model passes, nested. Frame-count and rate identity proves a shared sample grid; the multi-window correlation test below proves no latency and no drift.
| song | frames (all 7 stems) | rate | ch | = source cut? |
|---|
| song01 | 25,970,931 | 44100 | mono | exact |
| song02 | 9,966,600 | 44100 | mono | exact |
| song03 | 8,388,702 | 44100 | mono | exact |
| song04 | 9,040,500 | 44100 | mono | exact |
In Ableton: drop all 7 clips at 1.1.1 and they stay locked. No warp, no nudge, no drift. It works because both separators are offline mask-and-invert models, so output sample n maps to input sample n with no delay. DrumSep runs on the drum stem, which is already aligned to the cut, so the drum pieces inherit the cut's time-zero. Same 44.1k on both passes, length equal to the cut, mono because the source is dual-mono. Bass and guitar are 16-bit PCM while the drums are 32-bit float, different bit depth, same timing, so that changes nothing.
The decisive test (Brandon's method): summed DrumSep vs the Demucs drums stem
Frame-count and rate identity prove only a shared sample grid and equal length. To prove no fixed latency and no drift, the correct probe sums the five DrumSep pieces and cross-correlates against the Demucs drums stem, a clean reference with no foreign instruments, at five windows per file using raw waveform and onset envelope. Run on all five of tonight's songs:
| song | pass-2 raw lag @ 5/25/50/75/90% | drift span | kit → drums residual | verdict |
|---|
| song01 | 0, 0, 0, 0, 0 | 0 | −20.3 dB | no latency, no drift |
| song02 | 0, 0, 0, 0, 0 | 0 | −31.6 dB | no latency, no drift |
| song03 | 0, 0, 0, 0, 0 | 0 | −34.8 dB | no latency, no drift |
| song04 | 0, 0, 0, 0, 0 | 0 | −30.4 dB | no latency, no drift |
| song05 | 0, 0, 0, 0, 0 | 0 | −30.6 dB | no latency, no drift |
Raw-waveform lag is exactly 0 at every window on every song, and the drift span (end lag minus start lag) is 0 samples. The onset-envelope measure shows only a ±1 to ±3 sample wobble on sparse or faint windows, the unstable correlation peak on thin material, with no timing meaning. Pass-1 (the six Demucs stems summed against the source cut) is likewise 0-lag across every window, reconstruction residual −11 to −26 dB from ordinary separation leakage.
Conclusion. All seven stems share the source timeline and need no manual realignment. They carry identical sample rates and frame counts, and the summed-DrumSep-versus-drums test returns zero-sample raw lag with zero drift on all five of tonight's songs. Import every clip at Arrangement time zero. No fixed latency, no accumulating drift.
The hardness you sensed is real, it just did not bite. Three ways a two-pass chain drifts: a sample-rate mismatch between passes (progressive drift, the true nightmare), tail-padding from model chunking, and mixing stems from different cuts or runs. The packager's "uniform frames + uniform rate" gate caught all three. Keep stems from one cut together and you are safe.
One genuine limit, and it is not timing. Separated stems do not sum back to a bit-exact original (bleed shares and loses energy). And the 7.3.26 jam source is 24 kbps AAC lowpassed near 4 kHz, so its cymbal and hihat stems are perfectly timed yet thin up top (song03 cymbals peak measured 0.064). Source ceiling, not a sync flaw. The 7.18 band-practice WAVs do not have that ceiling.
2. The two chats, side by side
2276d10bStem audio chat
"it keeps refusing to pull original 4 hour audio"
- 7h 03m, 465 assistant turns
- 163 tool turns, 0.0% batched
- 98 Bash, 20 Write, 16 Read
- Chased "why won't it pull" for hours. The file was byte-identical to the local copy the whole time. The Drive tool was never called on the first attempts, then Drive throttled the real pull to ~30 KB/s.
2a6a341aAbleton stem engine
"give me my files i asked for 14 hours ago"
- 7h 06m, 487 assistant turns
- 177 tool turns, 0.0% batched
- 91 Bash, 24 Edit, 21 Read
- Drifted from "build the skill" into full-stream null tests on 4.3 GB files to prove takes were dual-mono, while disk sat full and 2 of 4 takes would not download.
3. The five shared failure patterns
- Four sessions on one jam. These two ran in parallel, plus c3479a1f (culled + shipped 20 mp3s) and ede85068 (owns stemming). Standing policy is one session. Fix: one session owns the jam, the rest stand down.
- 0.0% tool batching across 340 tool turns. Every call went out alone. Serial calls make you sample instead of sweep, which is how the wrong verdicts survived. Fix: independent checks (df, ls, ps, source probes) go out in one block. This audit did exactly that.
- Gate-fighting loops. The Stop hooks (color, voice em-dash and ellipsis, ask-drift, search-before-blocked, done-claim, fraud-check) blocked replies over and over, and turns were spent rewriting to satisfy formatting rather than moving audio. Fix: write in the house voice the first time; treat the gates as a pre-flight, not a fight.
- Diagnostic rabbit-holes. "Why won't it pull" (answer: it pulls, just throttled) and "is it 4-channel" (answer: dual-mono, provable from one header, not a 4.3 GB stream). Fix: cheapest decisive probe first, one header read beats a full-file null test.
- Mundane blockers ignored for hours. Disk full (Black 0 bytes, main was ~0 writable, T7 down to 4 GB) and gdown's known throttle after two large files. Neither is a "refusal." Fix: a batched df + one working download path surfaces both in two minutes.
4. How to get the stems you need
Two sources, two very different verdicts.
7.3.26 jam — low-fi ceiling, finish it anyway
- Source is the verified 4h32 master (md5 9892b41f), 24 kbps, ~4 kHz lowpass. Real timing, thin highs.
- Song map found 100 performances, 29 with strong drums. 29 lossless cuts already exist. 4 packages done and sync-verified (song01-04). song05 is separating right now.
- Path: let the serial Demucs then DrumSep run finish the remaining cuts through /jam-stem-rebuild, one song at a time, no parallel songs (CPU-bound). Manage expectations on cymbals.
7.18 band practice — the real prize
- 4 WAV takes, 24-bit, ~15.6 GB, full fidelity. No lowpass ceiling. This is the source worth stemming.
- Take 8.07 PM is already stemmed into 7 stems: BandPractice_8-07PM_7stems.zip (bass, guitar, kick, snare, toms, hihat, cymbals + manifest).
- To get the rest: free disk first (need ~70-100 GB on a fast writable volume, Black is at 0, main at ~24 GB, T7 at ~63 GB), then pull the 2 takes gdown throttled (7.49 and 8.00 PM) through signed-in Chrome, then run /jam-stem-rebuild per take.
Short version: the drum jam is already being turned into tracks and they line up fine, but it was recorded at low quality so the cymbals sound thin. The better recording from July 18 is the one to spend time on, and one song from it is already done. To finish the rest, clear space on the drives and download the two missing files a different way.