Practice along to the real recording, not a MIDI backing track

Fretly imports a Guitar Pro or PowerTab score — from a local file or straight out of a Songsterr search — pairs it with backing audio from a file or a YouTube link, and renders the notation and tablature in the browser with track selection, looping, speed control, and separate backing and reference-synth volume.

The part that matters is the cursor. Instead of playing alphaTab's MIDI rendition, the app makes the actual recording the playback clock and warps the score onto it, so you are practicing against the record you know rather than a metronomic approximation of it.

Tab software plays a synthesized version of the score at a tempo you set. Recordings do something else entirely — they push into choruses, drag on turnarounds, and sit a few milliseconds off the grid everywhere in between. A cursor driven by the score's own tempo map is right at bar one and wrong by bar twenty.

A single global offset does not fix that, because the error is not constant. What is needed is a nonlinear, strictly monotonic map from score time to audio time: a curve that can stretch and compress locally while never running backwards.

Building and trusting that curve is the whole project.

Import is deliberately impatient. Songsterr routes resolve metadata and convert revisions into .gp files, YouTube routes shell out to yt-dlp and ffmpeg for search and audio, and the player route opens immediately while alignment is queued in the background. Audio Blobs live in IndexedDB; signed-in users also get their files in private Supabase Storage behind row-level security.

Alignment itself is offline preprocessing, never a request-path job. alphaTab converts the score to MIDI and a bar/beat grid using the same parser playback uses; fluidsynth renders a reference track; librosa and SyncToolbox MrMsDTW compare quantized chroma and DLNCO onsets to produce a monotonic warp path. The client resamples that path into alphaTab sync points and stores it per song.

At playback, alphaTab runs in external-media mode and a ~60 Hz loop pumps the audio element's current time into it. The SyncMap translates between the two timelines in both directions, so a new DTW result can replace the map in place without reloading the player.

On a 170 BPM song the cursor started clean, was visibly out a few measures in, and got worse from there. The on-screen error readout could not localize it — it compares two moving clocks and only ever says that something disagrees.

So I measured four layers separately: the score's own timing model, the raw DTW path, the simplified sync map, and what playback actually implements. The first three came back at 0.000 ms against the score across all 144 bars, and the DTW path sat at a 7.3 ms median residual against 474 detected note attacks. Only the last layer was wrong — and its error was a straight line at −2.6666 ms per second.

A per-second constant points at something counted per event, not per song. alphaTab keeps two clocks for the same score: the cursor accumulates in floating point, while the sync-point path runs through a helper that truncates to whole milliseconds with | 0. At 170 BPM a beat is 352.941 ms and gets banked as 352 — and since audit #2 had moved sampling from bars to beats, that helper ran 576 times a song. 0.941 ms × 2.833 beats/s is 2.667 ms/s; × 576 beats is 542 ms. Measured: 541.

The fix reads alphaTab's own belief back out. Sync points are applied once, the generator is asked where it thinks each point sits, and every offset is re-derived against that time before a second and final apply. One pass is exact, and the two clocks are forced to agree at every beat, so nothing is left to accumulate in between.

The lesson I keep from it: the beat-level sampling that fixed intra-bar drift in the previous audit is exactly what multiplied this one by five. Nothing in the system was measuring the layer where it landed — so I built the tooling that could.