8.28 tape identification

What the 4.96 GB file actually is, and where the six sliced takes sit inside it · measured 2026-09-06

The six take folders on the T7 are cut from this tape. That is now measured rather than assumed, and the map below gives the exact second each one starts. The reason it matters: the takes account for 11.0% of the tape. The other 4h 38m 02s has never been cut.

1. What the file is

Four things about this file will break a script that assumes an ordinary WAV:

2. Where the takes are

Offsets are seconds into the tape. lag is the residual after cutting at the stated point, measured at 2.9 ms resolution. gate is verdict_gate.py from the notation-evidence-gate skill, run with a block-rotation null.

The cut grid is rigid

Every one of the six offsets sits a constant 430 ms (sd 0.6 ms) above an exact integer second. Six independent takes agreeing to sub-millisecond is not coincidence, it is a fixed registration difference between this tape and whatever copy the slicing was done from. It is reported as a constant rather than absorbed into a wider tolerance, which is the rule the gate exists to enforce.

3. What is not cut

The six sliced takes span 1h 00m 05s of a 5h 12m 25s tape and are numbered song10 through song15. Nothing named song16 or above exists on any volume mounted here. The two shaded blocks above are where that material would be, if it was played.

This does not establish that more takes exist. It establishes that four hours of this practice has never been examined, and that the examination is cheap now that the tape is identified and the cut grid is known.

4. Which mic this tape is

Raw-waveform correlation on a 60 s probe inside take 13, against each of that take's mics:

One mic correlates and three do not, so this tape is the mic-3 channel, not a four-mic sum. It is not bit-identical to gtr1_mic3, so gain or EQ sits between them. The practical consequence: this file alone cannot rebuild the other three lanes. Slicing new takes from it yields mic 3 only, and the multitrack for anything new has to come from wherever the other three channels were captured.

5. How this was established, and what I got wrong first

Two attempts failed before one worked, and both failures are worth keeping because each would have shipped a confident wrong answer.

Attempt 1, RMS envelope — failed its own control

Correlating 100 ms loudness envelopes put the takes at 0.20 to 0.46 against the tape, which read as a clean negative. It was not. The positive control, two different mics on the same performance, only reached 0.465. A method whose known-true case scores 0.465 cannot call 0.34 a negative. Loudness was the wrong feature.

Attempt 2, onset strength — correct feature, broken bookkeeping

Onset strength separated the controls properly (ceiling 0.364 floor, floor 0.095 ceiling). But the streamed envelope discarded overlap frames at every chunk seam, so the tape measured 18,428.5 s against a true 18,745.4 s. Rankings survived that; every timestamp was compressed by 1.7%, which is exactly the number that mattered. Caught by checking the envelope length against the file duration, a check worth doing every time.

Attempt 3, exact framing — stands

With framing pinned so frame i covers samples [i·512, i·512+2048), the frame deficit fell to 1 on every file and peaks rose from 0.11–0.86 to 0.984–1.000.

What the gate required

• N5, unnamed alignment. Wants offset and scale and tolerance and match rate. Scale was measured, not assumed, by aligning each take's two halves independently: 1.000000, sd 2.7e−15. Tolerance 50 ms.
• N3, no baseline. A z-score against a lag surface is not the null the gate specifies. verdict_gate.py supplied the admissible one, block rotation for local exchangeability. All six takes returned CONFIRMED, exit 0.
• N4, weak ratio. Two mic rows in the earlier pass scored 1.41× and 1.43×, under the 1.5× floor. They are excluded from support rather than averaged in.
• N8, one continuous take. Here that assumption is the claim, so it was made falsifiable: literal slices predict scale exactly 1.0 and two halves agreeing. Both held.

Final independent check, the one that is hardest to fake: the six offsets come out in ascending order matching the slice numbering, with zero overlaps, and the gaps between them reconcile with the take lengths to the tape's full 18,745.374 s exactly.

6. Screening the unsliced blocks — and why it does not answer the question

With the tape identified, the obvious next move is to screen those four hours for take-shaped activity. It runs off the cached onset envelope, so it costs nothing. The threshold was calibrated on the six known takes rather than picked by eye, set at their interior 10th percentile of onset density.

It recovers 6 of 6 known takes. That is the recall half, and it works.

Reported as a listening worklist, ranked longest first, never as takes. Thirty regions of 60 s or more, 3h 14m 53s in total across both blocks. The longest six:

For scale, the six known takes run 120, 124, 164, 484, 534 and 636 s. Several candidates are far longer than any real take, which is another sign they are runs of continuous activity rather than song boundaries.

Second attempt: pulse clarity, and it fails too

Density measures whether sound is happening, which is the wrong question. The better one is whether a steady pulse is present, since a take is a song held at a tempo and noodling is not. That is the tempogram family, FMP 6.2–6.3. Measured as the strongest normalised autocorrelation peak of the onset envelope in a 50–210 BPM band, 20 s windows.

The per-take medians are worth seeing, because they show why. Take 14 scores 0.148 and take 11 scores 0.401. The known takes are not internally consistent on pulse either, so no threshold drawn from them can be sharp.

The conclusion, which is a negative and is the useful part

Two independent signal-level discriminators both fail on the same tape. Loudness gets 1.11×, pulse gets 1.18×, and the floor is 1.5×. Take boundaries in this recording are not recoverable from signal statistics. Whoever cut song10 through song15 was making a musical judgement about which passes were complete, and neither onset rate nor tempo stability encodes that judgement.

The practical value of a negative result is that it stops you spending effort. Do not build a take detector for this tape. The screen above is still worth having as a listening order, ranked by length of continuous activity, and that is all it is.

7. Takes 17–22 are locatable after all, and the answer was in the filenames

The signal-statistics route failed twice. The answer came from somewhere else entirely. The prior session's audit page carries take ids of the form 10_tape1-59-59, 22_tape4-00-08. Those are not arbitrary labels. They are timecodes into this tape.

Five takes exist both as an id and as audio I measured independently. For all five, id_seconds minus my measured offset is the same constant:

K = 0.5698 s, sd 0.0007 s, total spread 0.002 s across five takes covering 52 minutes of tape. That is the whole proof. If the ids were labels for some other recording, or for four separate tapes, those deltas would scatter. They agree to under a millisecond.

Where 17 through 22 sit

What actually tests this, and what does not

• 🔴 The cut-grid check is circular and I am not counting it. The ids are whole seconds and K = 1 − 0.430, so "the predictions land on the .430 grid" follows automatically from arithmetic. It looked like confirmation and it is not.
• K's stability is the real evidence. sd 0.0007 s over 52 minutes of tape.
• All 6 fall inside the unsliced tail block, past 3:00:03. Not one collides with an already-sliced take, which the scheme did not have to satisfy.
• 5 of 6 carry musical activity in the same band the six known takes occupy (98.5 to 124.2). Take 19 sits at 92.7, modestly under the 98.5 floor, so it is the one to check first.
• 4 of 6 land inside candidate regions the density screen found independently, and that screen never saw these ids.

These are positions, not extractions. Nothing has been cut. And the earlier finding still binds: this tape is mic 3 only, so slicing here yields one lane per take, never the four-mic multitrack the existing six folders hold.

Where they end is a weaker claim than where they start

The ids give six start points and no lengths, so the map was half a map. Estimating the other half from the density curve works, and works unevenly, and the uneven part is the part worth publishing.

Calibrated against the six takes whose lengths are known to 0.1 s, the best setting recovers four of them to within 2.3 s and misses two badly: song12 by +24.0 s and song14 by +65.3 s. The median error of 1.7 s flatters it, so the per-take errors are given instead.

What is firm and what is not. The six start points rest on the constant-K timecode mapping and are good to a millisecond. The end points are estimates from a method that demonstrably fails on 2 of 6 known cases. The hard upper bound column is firm, since a take cannot run past the start of the next one.

8. Why everything failed: this practice barely stops

Both flagged estimates turned out to be the same fact wearing two hats, and chasing it down explains every negative result above.

Measuring the longest quiet stretch between each pair of consecutive take starts, across all twelve located takes:

That single fact accounts for every failure earlier on this page, and they stop looking like separate problems:

• silence detection at −45 dB returned one unbroken 3h 22m segment
• onset density scored 1.11×
• pulse clarity scored 1.18×
• boundary energy showed a step-up for only 2 of 6 known takes
• the length estimator merged 21 into 22, where the longest silence is 2.0 s
• it ran take 17 onward toward take 18, whose span holds nothing quieter than 19 s

Six results, one cause. There is nothing at the signal level to find, so no detector tuned on this material can work, and the two flagged end points are not going to be fixed by a better algorithm.

The practical consequence for cutting: use the next take's start as each take's end. That is what the recording supports. Take 21 runs to 4:00:07.430 and take 22 begins there with no pause, so a cut at that instant splits continuous playing, which is what the original six folders did too.

9. What to do with it

• Do not re-slice from this file expecting four lanes. It is mic 3. Multitrack work needs the original four-channel capture.
• Fold to mono before archiving. 2.48 GB is a duplicate channel.
• Survey the two unsliced blocks before assuming takes are missing. 4h 38m 02s of this practice has never been looked at, and the tape and grid are now known.
• Resolve the 430 ms constant against the copy the slicing was done from, so new cuts land on the same grid as the existing six.

Source: 8.28.26 - 9_1_26, 4.53 PM.wav, 4,960,025,948 bytes, on /Volumes/Black. Takes: /Volumes/T7 Shield/untitled folder/song10..song15. Measured on the Dr Wu iMac, whose OS hostname string is still Jacks-iMac (ComputerName "Jack’s iMac", user drwu); Brandon corrected the machine name on 2026-09-06, so both are recorded here rather than one. Gate: notation-evidence-gate/verdict_gate.py. Every figure on this page is emitted by build.py from the measurement JSONs, not typed.