Watermelon In Easter Hay: the drift, settled
Brandon heard the tab pull away from the audio as the song went on and suspected the YouTube was a different version. The recording turned out to be the same performance. The drift was the tab's own tempo map, and a second defect inside Songsterr's storage swallowed the first attempt at fixing it.
Songsterr s6857183, Vinnie Colaiuta drum staff. Measured 2026-09-08 on MacBookPro against the Moises stem set and a fresh YouTube pull.
1The YouTube is the same performance
The hypothesis was worth testing and it does not survive measurement. Onset envelopes from the fresh YouTube pull were cross-correlated against the Moises source mix in seventeen twenty-second probes spread across the whole song. Sixteen of the seventeen lock onto one offset.
| File | Duration | Reads as | Release |
|---|---|---|---|
| Moises source mix | 545.27 s | 9:05 | Joe's Garage, with the Central Scrutinizer megaphone intro |
| YouTube pull | 522.44 s | 8:42 | Plays the Music of Frank Zappa, intro snipped |
The measured offset is −23.34 s, with a standard deviation of 3.9 milliseconds over a 450-second span. A speed difference of even one part in ten thousand would show up as 45 ms of walk across that span. Nothing walks. The two files carry one performance with a different head trim, and the 8:42 figure matches the cited runtime exactly.
Why this matters more than it sounds
Nine days of stem measurement were made against the 9:05 master while the tab is synced to the 8:42 edit. Had the two been different takes, every one of those measurements would be void. They are the same audio, so the stem evidence stands, and the only correction needed is a constant on the time origin.
2The drift was the tab's tempo map
The tab carried one tempo automation, 56.000 bpm, covering all 105 bars. The take does not hold still. Placing the tab's own kick and snare notes on that grid and scoring them against the isolated stems gives the picture below. The lead guitar stem is the control, since a grid that is merely finding loud moments will score about as well on it.
| Grid | Kick + snare match | Guitar control | Discrimination |
|---|---|---|---|
| Flat 56.000 bpm, the old tab | 0.445 | 0.283 | 1.57x |
| r8973389 as Songsterr actually served it | 0.492 | 0.285 | 1.73x |
| r8973454, live now | 0.776 | 0.317 | 2.45x |
| Two-decimal ideal, unreachable on this platform | 0.782 | 0.317 | 2.47x |
What the drift looked like
Each curve is the barline error against the performance after the player picks its best single sync offset. The red curve runs ahead early, falls about 1.65 s behind by bar 65, and swings forward again through the guitar climax. That shape is what Brandon heard. It is a curve rather than a constant lag, so no single offset can remove it.
The 4.25 s headline, re-read by eye
The worst flat-grid error also sits at bar 1, and two bar-1 claims on this page were withdrawn, so this one was checked the same way before being kept.
Bar 1 is not detached here. Across bars 1 to 15 the flat error reads 2.60, 2.51, 2.31, 2.15, 2.01, monotonic with no step, and the whole 105-bar curve is a smooth S through zero near bar 33 to its low at bar 65.
| Population | Worst error | Peak-to-peak | RMS |
|---|---|---|---|
| flat 56.000, all 105 bars | 2.60 s at bar 1 | 4.25 s | 1.16 s |
| flat 56.000, bar 1 dropped | 2.51 s at bar 2 | 4.16 s | 1.14 s |
| live r8973454, all 105 bars | 0.05 s at bar 56 | 0.09 s | 0.03 s |
Dropping bar 1 moves peak-to-peak by 0.09 s. The headline stands unchanged. The same bar was genuinely detached in the sync-point measurement and is ordinary here, so an eye check belongs to each claim rather than being inherited from one.
3Songsterr floors the tempo, and it cost the first fix
The first revision, r8973389, wrote 105 automations spanning 53.57 to 58.37 bpm with two decimals. Reading the published data back showed integers. The rounding is not to nearest.
Flooring every bar makes every bar a little slow, and the error accumulates in one direction. The notated length grew from 506.68 s to 511.28 s, and the match that should have reached 0.782 came out at 0.492. The revision was honest work and its own description overstated what landed.
Read by eye, and no outlier drives it
This started as a number comparison, so it was rendered and read. The served step function sits at or below the sent value at all 105 bars and never above. Per bar, every difference lands in [0, 1) and every one is positive. Rounding to nearest would put about half of them negative.
| Check | Result |
|---|---|
| Differences inside [0, 1) | 105 of 105 |
| Negative differences, which rounding would produce | 0 |
| Bars already integer, matching floor trivially | 0 |
| Outliers above 1.0 bpm | none |
| Mean difference | 0.500 |
| Control: r8973454 sent minus served | 0.0000 every bar |
A mean of 0.500 is what uniform truncation predicts for a discarded fractional part, and the accumulated lag is a monotonic staircase with no step down, ending at +4.61 s. The population carries no outlier to discount, so unlike the bar-1 claims elsewhere on this page this one rests on all 105 values at once.
The fix that survives flooring
Integers are all the platform keeps, so the integers were chosen by error diffusion. At each bar the integer picked is the one that lands the next barline closest to the fitted metronome time, and whatever error remains carries forward into the next choice. Bar durations then alternate between neighbouring values and average out to the right tempo.
Worst barline error against the fitted grid: 0.049 s for error diffusion, against 4.57 s for choosing each bar's integer on its own.
The published tempo curve, 105 bars
53 to 59 bpm. The shape opens near 54, holds the middle 50s through the first half, pushes into the high 50s across the guitar climax, and relaxes at the close.
4What shipped, and what it did not touch
Two revisions went up, the second correcting the first. Neither moved a single note.
| Check | Result |
|---|---|
| Drum staff note instances | 2,834 before and after, lane for lane identical |
| All nine parts | 1061 / 55 / 334 / 64 / 360 / 459 / 324 / 108 / 2834, byte-identical |
| Track names | 9 of 9 kept, 137 CDATA wrappers preserved |
| Bars and meters | 105 bars, 53 in 4/4 and 52 in 5/4, unchanged |
| Preflight gate | PASS, exit 0, on both uploads |
| Published data verified | 105 automations read back from CloudFront, 0 mismatches against intent |
5The crash cymbals: two detectors, both refused
The tab writes 51 crash notes, one at the top of each phrase from bar 4 to bar 96. Two detectors were built and rendered, and the render is what settled both.
The written crashes are real, and this is the measurement that shows it
A crash should out-peak an ordinary ride stroke in the same stem. The 51 written crash positions were compared against the 1,501 written ride strokes that do not coincide with them.
| Feature | Crash median | Ride median | Ratio | AUC | p |
|---|---|---|---|---|---|
| Peak 3-10 kHz energy | 0.3614 | 0.0908 | 3.98x | 0.894 | 5.2e-22 |
| Decay ratio, 60 to 450 ms | 0.786 | 0.645 | 1.22x | 0.606 | 0.005 |
An AUC of 0.894 says that picking one written crash and one ride stroke at random, the crash is louder 89 times in 100. The original transcriber's crash placement is supported. An earlier version of this page rested that on a weaker claim, 42 of 51 detected, and the render showed the detector was firing on every ride stroke, so hitting a crash position proved only that a cymbal was struck. That claim is withdrawn and replaced by the table above.
Adding crashes fails, on two different detectors
| Detector | New candidates | Null on lead guitar | Ratio | Verdict |
|---|---|---|---|---|
| Flux plus decay | 132 | 82 | 1.61x | fails the null |
| Peak energy, author-calibrated floor | 310 | 89 | 3.48x | passes the null, fails on density |
The second detector clears its control comfortably and still cannot ship. 310 additions across 105 bars is 2.95 crashes per bar, six times the author's own 0.49, sustained for nine minutes. No drummer plays that. The floor sits at only 1.73x the ride median, so roughly a tenth of the 1,501 ride strokes clear it by themselves.
The 310, read by eye
Density was the arithmetic reason. Rendering the 310 marks against the tab's own ride notation gives the cause. 148 of them, 48%, sit within 70 ms of a stroke the tab already notates as ride. They are not missing notes. They are existing notes the detector cannot tell apart from a crash, and the rest land on the same rise-and-decay sawtooth. The written crashes sit on visibly larger events, which is the 0.894 AUC seen rather than computed, and the guitar stem visibly crosses the 0.157 floor around bars 78 to 80.
| Reading | Value |
|---|---|
| Candidates coinciding with a written ride stroke | 148 of 310, 48% |
| Density if all 310 were written | 2.95 per bar against 0.49 |
| Guitar excursions above the floor | visible, bars 78-80 |
Nothing was added. Writing either set would repeat the pass that put 599 toms into this ballad on 2026-09-07. The blocker is the separation: the lead guitar stem, which contains no cymbals at all, still fires 82 and 89 times under these floors, so the Moises cymbal stem carries guitar bleed at crash amplitude.
Queued as q-2026-09-08-f370c3. It could not be done in this session because both available features stop short: decay separates at AUC 0.606, and peak energy separates well enough to confirm known crashes while returning a density no human plays. Unblocking needs a lane that is not in this stem set, meaning the other_kit stem, an inter-channel pan test, or a cleaner separation, held to 2.5x over a guitar control and a per-bar density inside the author's own range.
6The video sync points, and a defect claim I withdrew
Withdrawn: "bar 1 is 0.818 s early"
I measured the sync points two ways and both said bar 1 sat 0.81 s off. A stop gate then demanded that an outlier in a width check be re-read by eye before being called a defect. Rendering the 8:42 master killed the claim.
Neither candidate lands on a musical event. The tab's bar 1 sits in a sparse solo-guitar passage and the band enters about five bars later. My "two independent confirmations" both rested on the same 36.870 s metromap anchor, so they were one measurement stated twice.
| Landmark in the 8:42 master | Time |
|---|---|
| First 5% crossing, 180-1200 Hz | 0.511 s |
| First 5% crossing, 3-10 kHz | 4.493 s |
| First 5% crossing, 40-160 Hz, the band entry | 17.845 s |
| Video's bar-1 sync point | 12.710 s |
| Extrapolated bar 1 | 13.528 s |
Across 12.0 to 14.6 s the traces carry no downbeat sharp enough to adjudicate 0.818 s. The anchor itself does check out independently: the first drum onset in the 9:05 stems is 41.204 s, which maps to 17.862 s in the 8:42 timeline against 17.845 s read directly off this master, agreeing to 17 ms.
What does survive
My first residual figures were also wrong for a second reason. Anchoring each video's points at point[0] put the anchor on the one bar that disagrees, smearing its error across all 105 residuals.
| Primary video XACocSRTFJY | Anchored at point[0] | Body-anchored |
|---|---|---|
| Worst absolute error | 0.94 s | 0.81 s, at bar 1 |
| Root mean square | 0.80 s | 0.09 s |
| Median error after bar 6 | not computed | 0.028 s |
| Bars off by more than 1 s | not computed | 0 of 105 |
So the per-measure points already track the performance to about 30 ms through the body.
The 105-point count, read by eye rather than inferred
That video carries 105 points where all eleven others carry 106. Rendered as inter-point intervals against the tab's own bar durations, a missing interior point would show as one interval about two bars long. No doubled interval exists in either video. Both trace the same 4/4-to-5/4 zigzag, 4.3 s alternating with 5.4 s, the whole way.
| Intervals | Median error vs bar durations | Last interval | Matches | |
|---|---|---|---|---|
| primary, 105 points | 104 | 0.049 s | 4.370 s | bar 104 at 4.286 s |
| alt, 106 points | 105 | 0.065 s | 5.320 s | bar 105 at 5.357 s |
The primary's points are bar starts 1 through 105 with no terminal boundary, and nothing is missing from the interior. Bar 105's end is extrapolated from the tab's own tempo, which r8973454 now makes accurate, so calling it a defect overstated it.
What the eye added that the arithmetic missed
Interval 1 runs long in both videos by nearly the same amount, +0.79 s on the primary and +0.82 s on the alt, while every later residual hugs zero. Two independently synced videos placing bar 1 the same way relative to bar 2 points at the tab's notated bar-1 length rather than at one video's sync being wrong. That strengthens the withdrawal above: 12.710 s is likely what both syncers intended.
What this means for the tempo fix
For video-synced playback the sync points carry the timing, so r8973454 changes little across the body. It fixes Songsterr's own MIDI playback and the within-bar interpolation. A peer session reached the same shape independently, placing the residual error at the opening rather than through the song.
The route exists, and nothing here is blocked by access
Scanning the five page bundles, 2,693,991 characters: videoSync appears 31 times, video/sync twice, plus POST /api/video-points/process taking {autoSyncRequestId}, an event video/syncPointsPublished, and the editor command commands/editor:pointsReplace. OPTIONS on the read endpoint answers 404 and GET answers 200, so the write path is the editor command, the same class of route that carried the Guitar Pro import. Two browser bridges are live on this Mac.
No pointsReplace was fired. The reason is evidence rather than access: after the eye check there is no verified replacement value for bar 1, and writing an unverified number into published sync data is worse than leaving it.
6bA peer session's four claims, re-derived
Session b1d3-427a-96a4-355bdf049d0a sent measurements on this tab. Each was re-derived here rather than accepted.
| Peer claim | My measurement | Verdict |
|---|---|---|
| Tab bar-1-to-bar-105 span is 501.4 s | 501.36 s fitted, 501.35 s live | CONFIRMED |
BASE-r8972739-live-head holds Crash1 50, Crash2 1, 2,834 notes, and the upload matches | identical across base, TEMPOFIX and TEMPOFIX-INT | CONFIRMED exactly |
| The 51 written crashes beat a circular-shift null at 2.83x | 4.87x, 0 of 300 rotations reach it, p = 0.000 | same direction, larger |
| HANDS and the live head disagree on about 150 tom notes | HANDS 41:1 43:44 47:4 48:81 50:30 against live 41:62 43:0 47:111 48:14 50:0 | CONFIRMED lane for lane |
Their 6-12 kHz brightness ratio of 1.59x reads 3.09x here on the same band. We differ on magnitude and agree on direction, so the written crashes now rest on two independent nulls. Their bar-by-bar sync residual could not be reproduced, since it compares a metromap.json that is not on disk in this session. The upload adopted the live head's tom assignment, which is correct for an edit built on the live head.
7Reinstated, with evidence this time
An earlier session recorded a 23.3 second duration gap and explained it with an invented lead-in, and the explanation was withdrawn for being invented. The gap is now measured at 23.34 s with a 3.9 ms standard deviation, and Brandon's own sources name the Central Scrutinizer intro as its content. The finding returns on measurement rather than on the story that first accompanied it.
8Follow-on audit, 2026-09-09
Three queue items that the tempo fix unblocked, worked through the /transcription-repair modules rather than hand-rolled.
Playability: PASS on the live head
| Check | Result |
|---|---|
| Instants examined | 1,767 |
| Needing more than two hands | 0 |
| Needing more than two feet | 0 |
| Unplayable ornaments | 0 |
The sixteen three-surface instants that stood in r8968524 are gone. The gate's grouping logic was itself rewritten on 2026-09-09 to union staff line with instrument identity, after a 262-tab measurement, so this PASS is against the stricter test.
The ride-pause verdict does not survive
Correction, 2026-09-09: the coda half of this section is withdrawn
The table below said bars 99 to 105 are flat and the tab is right there, and it refused an onset detector for disagreeing. The render was the faulty instrument, not the detector. It drew four panels on shared y-axes, so bars peaking near 0.05 were plotted against bars peaking near 0.9 and collapsed onto the baseline.
| Bar | Peak 3-10 kHz | At native scale, one panel per bar |
|---|---|---|
| 17 disputed, tab writes 0 | 0.1708 | 12 to 14 discrete attacks, matching its control |
| 16 control, tab writes 20 | 0.2310 | 10 to 12 attacks after the opening crash |
| 51 disputed, tab writes 0 | 0.1681 | about 12 discrete attacks |
| 99 coda, tab writes 0 | 0.0526 | 10 to 12 discrete attacks. NOT flat. |
| 100 coda, tab writes 0 | 0.0504 | discrete attacks, same shape. NOT flat. |
Bars 17 and 51 hold, since at native scale they carry their controls' stroke pattern. The coda claim falls: those bars carry structured attacks at about a third of bar 17's amplitude, and whether they are ride, resonance or bleed is unresolved. The detector is reinstated as unrefuted; its calibration is still too poor to write notes from.
The rule this teaches: a shared y-axis is an overview. Comparing bars whose amplitudes differ by more than about 5x needs one panel per bar with independent scales, or the quiet one reads as silence.
One of fourteen quiet bars changes verdict on arithmetic alone, bar 17 moving 0.40x to 0.63x. The render overturned more than that.
| Bar | Tab writes | What the render shows |
|---|---|---|
| 17 | 0 ride | a steady stroke train at neighbour amplitude, the ride is playing |
| 51 | 0 ride | visible ongoing strokes, the ride is playing |
| 53 | 2 ride | plays through the first half, flat in the second |
| 87 | 0 ride | plays through the first half, silence extends into bar 88 |
| 99-105 | 0 ride | genuinely flat, the tab is right |
A detector of mine was refuted by the eye and is not published. An onset counter calibrated on the 43 full-ride bars returned 10, 11 and 8 strokes in coda bars 99, 101 and 103, which the render shows flat. Its threshold pinned to the bottom of its search range with a mean error of 4.19 notes per bar, so it was reading ripple. No per-bar ride counts ship from this pass, and the repair that bars 17 and 51 imply is queued behind a detector the eye does not refute.
Settled by eye, in a second representation, against a silent control
The correction above read as a detector overruling the eye. It was not. Re-checked with spectrograms of single bars, all on one dB scale so brightness is comparable, with a genuinely silent stretch included as the control.
| Panel | Tab writes | What the spectrogram shows |
|---|---|---|
| bar 17 | 0 ride | 12 to 14 broadband striations across 2-11 kHz |
| bar 16, control | 20 ride | a bright opening event then about 12 striations, the same character as bar 17 |
| bar 99, coda | 0 | about 12 discrete striations, dimmer and unmistakably present |
| bar 100, coda | 0 | about 10 discrete striations, same shape |
| bar 105, coda end | 0 | near black |
| 5 s after the final barline | n/a | completely black |
The silent control is what makes the coda readable: post-song silence renders black at this scale, so structure in bars 99 and 100 is signal rather than a floor artifact. Nothing here rests on the onset detector. The arbiter in both passes was the eye; the first pass simply read a shared-axis overview, which is not the eye reading the evidence.
Bar 105, and a parser bug of mine
A first pass reported 48 voices not filling their meter. 43 of those were my own bug: grace beats carry a rhythm and no bar time, and my sum counted them. Separation is total, 43 of 43 flagged bars contain grace beats against 0 of 62 filled bars.
The real finding is that bar 105 is short by one quarter in five voices, not one, confirming a concurrent session's correction. Four voices fill the 5/4 correctly, so the meter is right. The same shortfall sits in the export that predates every edit here, making it the original transcriber's notation. Left as it stands, since padding five voices across four non-drum tracks buys nothing on a final bar carrying no drum content.