Watermelon: the drift, the missing crashes, the missing intro

Withdrawn: "Songsterr fires 12.50 s early at bar 1"

This page published that figure, plus a claim that bars 104 and 105 drift and that seven of 105 bars miss by more than a second. All of it is withdrawn. A gate demanded that two disagreeing methods be reconciled, and reconciling them killed my number.

The cause, traced rather than muted. Songsterr returns twelve video-sync entries for this tab. The primary is the one whose feature field is null. I loaded the list and took [0], which is VZS-QuMBZdk, one of seven alternative uploads. Their first sync points spread across 28.02 s, from 21.42 to 49.44, because each YouTube upload carries its own lead-in. Measuring one of those against my stem clock produces a large head difference by construction, and it says nothing about the tab.

The primary video, measured properly. XACocSRTFJY, 105 points, constant offset −23.360 s, which is the 8:42 versus 9:05 master gap the sibling session had already pinned at 23.342 s.

And the one residual left is already dead. Bar 1 reads 0.800 s on the primary, which matches the 0.818 s the sibling session measured independently. That session then rendered the 8:42 master, read the bar by eye, and withdrew it as unsupportable. The Songsterr sync is clean.

There is no missing intro

This page said the tab has no bars for the first 36.87 s of the record, that 6.8 percent of the song is unwritten, and that real music sits in that gap. Withdrawn on all three counts.

The masters differ, and that explains the gap entirely. Songsterr syncs to the 8:42 edit at 522.436 s. The stems are the 9:05 Joe's Garage master at 545.267 s. Same performance, 23.34 s cut from the head. The primary video's offset measured here is −23.360 s, which agrees to 18 ms. The tab is not missing a head. The stems simply carry one that the tab's own master does not have.

The head is near-silence anyway. Reading the render below: the other stem's 45.1 percent is one transient at 17.71 s, and across the whole 36.87 s that stem sits above 5 percent of its in-song peak for 0.12 seconds in total. There was never a body of unwritten music there.

What survives from this section. The drums enter on bar 2 rather than bar 1. Kick first crosses 10 percent at 41.21 s and cymbals at 41.24 s, and bar 2 starts at 41.25 s, so both are that downbeat landing 40 ms inside bar 1's window. Trim 0.30 s off bar 1's end and the kick reading falls from 48.62 percent to 0.04 percent. Bar 1 is silent, and the tab writes a crash into it that measures 8.27 percent against the 33 percent floor.

The red dashed line in that render is labelled from the alternative video and is therefore the withdrawn figure. The black lines, the stem traces and the bar-1 reading are unaffected.

The pass ran, and its result is not in the upload

Session c6454a97 ran a crash detector at 17:43 and wrote crash_find.json: 132 new crash candidates across 74 bars, bar 2 through bar 98, against a circular-shift null of 82, so 1.61x chance. Thirty-seven of those bars have no written crash at all.

I censused the drum track of the file that session is uploading and compared it to the live head:

The entire drum-track note histogram matches the live head, note for note. The upload carries tempo and nothing else. That is a clean single-variable change and it is the right way to ship a timing fix. The 132 crashes remain unshipped, and the coda still has none.

What stopped me short of a verdict

Deciding which lane scheme the clusters back needs each measured stroke joined to the note written at that instant. The join fails. tom_f0.json is a proposal grid rather than a read of the written file: its rows already carry their own midi and a brandon flag, its bars are zero-based against the files' one-based, and its positions sit on a different subdivision. Sample rows read bar 24 at 3.00, 3.25 and 3.50 quarters while the files hold bar 11 at 4.50 and 4.75, and bar 14 at 1.0625.

After correcting the bar base, 12 of 185 strokes match HANDS and 11 of 185 match the live head. A 6 percent join is not a basis for reassigning 150 notes. Settling it means re-extracting f0 at the written note positions rather than at the proposal's, which is a fresh measurement pass on the toms stem.

A note's beat-references and its instances are different units

Comparing 13 rows against 13 beat-references reads note 419 as exclusive. It is not. Both notes in the 15-row plan are shared definitions, where the ledger named only one.

The hole. Our rule says a plan whose rows repeat one id is editing a shared definition. Note 419 repeats thirteen times, so the rule catches it. Note 425 appears twice and carries 46 instances, so the rule misses it. Repetition inside a plan is a symptom of sharing rather than a test for it.

The corrected pre-flight. Compare each plan note's row count against its instance count across the whole file, both in the same unit, and check the instance total against a figure known independently. Here that figure is 2,784 drum instances.