While testing the new audio and timing work, normal gameplay was behaving well. SereneAudio and the gameplay position remained closely aligned, with no sign of the timing drifting during a song.

SyncMachine was less convincing.

After restarting its test, it would show a small but repeatable offset. Because the value stayed fixed rather than growing over time, we knew this was unlikely to be the audio path wandering out of sync.

The problem was in how timing information was being passed between systems.

One part of the engine recorded the song position at a particular moment. Another part received that value slightly later and treated it as though it described the current moment. The delay was small, but large enough for a calibration tool to notice.

We corrected that handoff so the timing value remains tied to the moment it was measured and is interpreted correctly when another part of the engine uses it.

That removed the fixed offset without adding another compensation value or changing normal gameplay timing to cover the problem.

This distinction matters because calibration tools should measure the player and the hardware, not compensate for an internal disagreement inside the engine.

The work also confirmed that the new gameplay timing path was stable. The problem was not SereneAudio drifting or the song position gradually separating during play. It was a specific transition between two older parts of the calibration flow.

SyncMachine now receives timing information that represents the correct point in gameplay, rather than mixing values captured at slightly different moments.

For players, that means calibration results should be more dependable, without asking them to correct an offset created by the engine itself.

It was a small fault, but exactly the sort of thing that needs fixing before the newer timing systems can fully replace the older paths.