Nanook Rubs It: Drum Tab Sync Forensics

Verdict

The file on the drive and the published tab are the same transcription

Before blaming either side I compared them note by note. The Guitar Pro file on the drive and the drum staff currently published on Songsterr carry identical content in every one of the 109 bars, comparing each note by its position in the bar and its drum MIDI number.

Error 1. The tempo is 69, the record is about 70.2

The tab carries exactly one tempo event: 69 quarter notes per minute at bar 0, marked invisible, holding for all 109 bars. I measured the record four independent ways and none of them returned 69.

The record holds that tempo steadily. Measured in twenty-second windows across the track, the bar period stays between 2.543 s and 2.601 s, which is 69.2 to 70.8 quarter BPM. There is no tempo map to reconstruct here, one steady value covers the whole song, and the value in the tab is simply about 1.2 BPM under it.

Error 2. Bar 1 and bar 109 carry padding

Nanook Rubs It also exists inside the Nanook Suite, tab s35878, as bars 38 to 146. I aligned the two by drum content rather than by trusting the tempo marks, sliding the 109-bar staff across all 292 bars of the suite and scoring each position.

So the same drummer's part is written twice, and the two writings disagree on exactly two bars.

The mechanism: the bars are under-filled

Neither bar holds extra notes. Both declare more time than they contain, and Guitar Pro plays an incomplete bar for its full declared length with the remainder as implied rest. Bar 1 declares 3/4 and every one of the nine staves fills only a quarter note. Bar 109 declares 4/4 and every stave fills only an eighth. The written content already matches the suite exactly, so correcting the two time signature fields moves no notes at all.

Where it entered the tab

Songsterr keeps the revision history, so I read the grid out of each historical revision rather than guessing.

What the padding looks like against the record

The arithmetic closes

Two independent errors, multiplied, should reproduce the measured overrun. They do.

The fix, and what it buys

I tested candidate grids by matching the tab's kick and snare positions against onsets detected in the Demucs drum stem, with the offset swept freely so each grid got its best possible showing.

The corrected file, built and checked

I wrote a corrected copy rather than touching the original. Three fields changed and nothing else in the archive moved.

Run through the project's own import gate, the grid check clears: grid 277.4s notated vs 277.2s record, 0.04% off. The gate still refuses the upload on two unrelated policy faults.

Both are upload-workflow faults rather than problems with the correction. Publishing to Songsterr is outward facing, so the corrected file is built and verified on disk and nothing has been sent.

Method, and what I could not settle

The record used as the ruler is the video Songsterr syncs this tab to, YouTube 8bXSsh3Z-xE, the official FrankZappaVEVO visualizer, running 277.235 seconds. Drums were isolated with Demucs htdemucs ahead of onset detection, since the full mix has vocals, keyboard, marimba and horns firing into the same onset envelope and it made the pattern matching much noisier.

The onset detector also over-triggers on the drum stem, returning 551 kick-band onsets where the tab writes 333 kicks. Over-detection makes matching easier, never harder, so the 26.1% figure for the tab as published is a ceiling and the true match rate is lower.

Files and evidence