Jam session work product

Located 2026-08-17 · second-brain retrieval test · every path below was stat'd on disk, nothing inferred

The answer: the 7.3.26 jam. One 4 h 32 m master recording, mapped into 100 contiguous performances, of which 29 drum-carrying songs were cut and separated. Two full pipeline runs exist: a July 8 silence-cull, and a July 19 drum-aware rebuild that replaced it.

4:32:24

master duration

songs cut

2:06

music extracted

100

performances mapped

full stem packages

Pipeline chain, where it stands

4h32m master ✓→ 100-perf song map ✓→ 29 lossless cuts, gone→ Demucs 6-stem, gone→ DrumSep 5-piece, gone→ 29 mp3 renders ✓→ 6 stem packages ✓

The intermediate audio is gone, and it is reproducible. T7 Shield was mounted during this session (disk3, 1 TB NTFS). The tree the symlinks point at, /Volumes/T7 Shield/jam-7-3-26-rebuild/, no longer exists. A search for cuts_manifest.json across T7 Shield, Black and ~/Projects returned nothing, and no song0*.wav survives on either external. The 24-bit cuts, the Demucs output and the DrumSep output were cleared.

Nothing irreplaceable was lost. The master is intact in three byte-identical copies and song_map.json holds all 100 performance windows, so cut_refine.py regenerates the cuts deterministically. Separation is CPU time, not information.
What that costs to redo: 29 cuts is minutes; Demucs plus DrumSep ran 20–50 minutes per song on CPU, so a full re-separation is a long unattended job.
Six finished 7-stem packages survived off that drive and do not need redoing.

Master verified three times over. md5 9892b41f4d84bb224fdb37c8156a6ff3 matches on all three copies: the run source, the jam-cull repull, and the original capture 7.3.26 - 7_7_26, 4.57 PM_1.m4a sitting at the root of T7 Shield. 49,868,049 bytes, aac 44100 Hz stereo, 4:32:24, full start-to-end decode PASS.

The 29 songs, mapped back to the master

Source windows recovered from maps/song_map.json. The naming is not sequential in time: song01–03 were the three priority drum cuts done first, then song04–29 fill the remaining 26 in timeline order. That reconstruction was validated against three independent anchors it was not fitted to. song09, song10 and song11 each carry a PROVENANCE.md recording exact source timestamps, and all three land within 1.5 s.

File	Source window	Length	Size	Drums	Check
song01	0:01:05–0:10:53	9:48	9.0 MB	HIGH 0.76
song02	1:36:16–1:40:02	3:46	3.4 MB	HIGH 0.7
song03	4:11:22–4:14:30	3:10	2.9 MB	HIGH 0.69
song04	0:14:16–0:17:41	3:25	3.1 MB	MEDIUM 0.46
song05	0:22:04–0:26:10	4:08	3.8 MB	HIGH 0.51
song06	0:26:10–0:31:10	4:59	4.6 MB	MEDIUM 0.44
song07	0:34:39–0:37:58	2:27	2.2 MB	MEDIUM 0.36	DELTA 52s
song08	0:47:49–0:54:08	6:19	5.8 MB	MEDIUM 0.41
song09	1:03:28–1:07:25	3:57	3.6 MB	HIGH 0.52
song10	1:13:34–1:16:53	3:19	3.0 MB	HIGH 0.69
song11	1:23:03–1:26:22	3:17	3.0 MB	MEDIUM 0.34
song12	1:26:22–1:32:17	5:53	5.4 MB	HIGH 0.48
song13	1:41:40–1:44:51	3:11	2.9 MB	HIGH 0.54
song14	1:48:06–1:51:11	3:06	2.9 MB	HIGH 0.63
song15	1:51:11–1:54:22	3:09	2.9 MB	HIGH 0.51
song16	2:24:00–2:28:49	4:49	4.4 MB	MEDIUM 0.31
song17	2:41:14–2:48:14	7:01	6.4 MB	MEDIUM 0.4
song18	2:50:36–2:54:18	3:43	3.4 MB	MEDIUM 0.31
song19	3:00:27–3:03:43	3:16	3.0 MB	MEDIUM 0.26
song20	3:12:12–3:16:03	3:49	3.5 MB	MEDIUM 0.33
song21	3:16:03–3:21:43	5:39	5.2 MB	MEDIUM 0.38
song22	3:21:43–3:24:51	3:08	2.9 MB	MEDIUM 0.32
song23	3:28:01–3:31:13	3:12	2.9 MB	MEDIUM 0.38
song24	3:34:03–3:38:58	4:54	4.5 MB	MEDIUM 0.36
song25	3:47:05–3:52:05	5:00	4.6 MB	MEDIUM 0.3
song26	3:54:31–4:00:10	5:39	5.2 MB	MEDIUM 0.42
song27	4:06:20–4:09:38	3:18	3.0 MB	HIGH 0.54
song28	4:16:06–4:20:08	4:01	3.7 MB	MEDIUM 0.24
song29	4:23:53–4:28:40	4:49	4.4 MB	MEDIUM 0.3

One row does not reconcile. song07's mp3 runs 2:27 while its mapped performance is 3:19, a 52 s gap, well past the few seconds that valley-snapping explains. Every other row agrees within 12 s. The cut manifest that would settle it was on the cleared drive, so treat song07's window as unconfirmed.

Every directory, with status

jam-7-3-26-rebuild: run root: verified master, 100-perf map, PROJECT_STATE.md, logs. Its four audio symlinks now dangle.
~/Projects/_outputs/jam-7-3-26-rebuild/PARTIAL

jam-7-3-26-rebuild-mp3: all 29 cut songs as mp3 (2h06m) plus a playable index.html
~/Projects/_outputs/jam-7-3-26-rebuild-mp3/LOCAL

jam-eligible-sections: 3 complete 7-stem packages (song09/10/11), mono, SHA256 provenance, Ableton .asd analysis files; 7 dirs staged empty
~/Projects/_outputs/jam-eligible-sections/3 of 10

jam-cull-drumkit-stems: 2 full drumkit packages (song02/song04) incl. bright variants, MIX_CHAIN.md, ABLETON_IMPORT.md
~/Projects/_outputs/jam-cull-drumkit-stems/LOCAL

jam-cull-stems: Demucs 6-stem output for 11 songs plus drum_rank.json
~/Projects/_outputs/jam-cull-stems/LOCAL

jam-cull/7.3.26-7.7.26: the superseded July 8 silence-cull: 20 clips (10 tagged “maybe”), SONGS_ONLY_keep.mp3, index.html, and a hand-curated “Session July 3 - 12 songs” folder
~/Projects/_outputs/jam-cull/7.3.26-7.7.26/LOCAL

jam-rebalance/songs-balanced: 20 loudness-balanced mp3 renders
~/Projects/_outputs/jam-rebalance/songs-balanced/LOCAL

jam-fullfreq-verify: the QA toolkit: integrity_full.py, compare_sources.py, scan_mics_v2.py, results.json
~/Projects/_outputs/jam-fullfreq-verify/LOCAL

bandpractice_stems: a separate one-take run from the same night (take_8-07PM_mid12), full 7-stem package
/Volumes/T7 Shield/bandpractice_stems/ON T7

the original capture: 49,868,049 bytes, md5 matches the verified master
/Volumes/T7 Shield/7.3.26 - 7_7_26, 4.57 PM_1.m4aON T7

cuts / demucs / drumsep / packages: the 24-bit cuts and all separation output
/Volumes/T7 Shield/jam-7-3-26-rebuild/CLEARED

Why the rebuild replaced the cull

Silence-splitting cannot find songs in a continuous jam. The July 8 pass cut on volume drops and produced 20 clips, half of them tagged maybe. A jam that never stops has almost no silences to split on, so the drum-driven performances were missed. The July 19 rebuild maps the kick band directly, using periodic pulse plus broadband groove novelty, and found 29 drum performances of three minutes or more inside the same recording, 2h06m of music out of 4h32m. That method is now the /jam-stem-rebuild skill.

Second-brain test result

Semantic retrieval missed this entirely. /ask returned 23 cited hits above the 0.60 gate across corpus, vault, memory and the domain registry. Not one pointed at the 7.3.26 jam. Vault hits went to a Phish video project and a Reba jam-anatomy session; corpus hits went to a mixing-engineering book. The work was found by listing the output directory.

The run has no vault note. PROJECT_STATE.md lives in the output folder, outside the indexed tree, so nothing describing it was ever embedded.
The chats layer ranks by raw term count and surfaced four transcripts whose top matches were boilerplate tool preambles, not jam content.
Fix: write a Brandon-Vault project note for the 7.3.26 jam pointing at these paths, then re-run ask.py index --layer vault --apply. Indexing is incremental.