The browser-sized tracker export is fixed, reproduces the measured system exactly, and runs fast enough for the browser

Listening

Study Overview

The Cause

The Beat This model positions its attention with rotary embeddings from a library that caches the position frequencies in a buffer and slices the first n rows on every call. When an exporter traces the model at some input length, that slice becomes a constant of that length, so any longer input is rotated with the wrong frequencies and the attention degrades. The export the bench inherited had been traced short, which is why Study 10 could only run it in 5-second chunks and why Study 41 found it tracking differently from the 30-second model. The fix is to trace at the inference length, or to turn the cache off and export with a dynamic length. The bench did both.

Verified to the Package

Frame logits from the two exports against the torch package differ by at most seven hundred-thousandths on three songs, the dynamic export at 750, 1500 and 3000 frames alike. The static export was then run through the reference inference in numpy, 1500-frame chunks stitched with a six-frame border and the minimal peak-picking postprocessor, and compared with the package's own beats and downbeats on the ten modern songs: F 1.000 on both, with identical counts on all ten. Where the old export had read 87 downbeats on Cherubs, this one reads 169, the same as the package. This export is the system of Studies 36 to 41.

Timed, and Placed

On a 30-second chunk the torch package takes 0.56 seconds on the bench VM's sixteen cores and ONNX Runtime on CPU 0.54 at four threads, 1.3 on one. ONNX Runtime Web's WebAssembly backend, the app's browser runtime at its pinned version, takes 4.5 seconds on one thread; requesting four threads changed nothing in Node, so that figure is the single-thread floor and a browser with SIMD and threads should improve on it. That is about nine seconds of model time per minute of audio, a four-minute song in roughly 36 seconds, under the registered threshold of fifteen seconds per minute, so the bench recommends the browser behind the lazy load the transcriber already uses, with ONNX Runtime on the server at about one second per minute as the fallback.

Predictions and Hand-over

Right: the static export matches the package at 1500 frames, reproduces its beats on the ten songs, the dynamic export matches at other lengths, and WebAssembly comes in under the thresholds. Wrong: ONNX Runtime at its default thread count is one and a half times slower than torch, reaching parity only at four threads. The export is handed to the app with its hash and a reproduction script, together with the four parts of the port: the log mel front end already verified in numpy, the chunking, the postprocessor, and the tempo and meter derivations from Study 41. The exports are not committed, being binaries reproducible from the checkpoint; their hashes are.