A race heard
2026-10-24, the pod-sound session, later still.
About 35 seconds of a Beltane start, as band spectra from 50 Hz (bottom) to 8 kHz (top). Top: the recording from the emulated PC, with the countdown voices taken out. Bottom: pod-sound's replay of the same race from its step log. The hum of eight idling engines through the countdown, then the change after GO, are in both.
The menu sound checked the levels. A race checks the rest: the 3D model, eight engines whose pitch follows each car, and the countdown. For that the port needs to know where everything was. pod-physics had just patched the VM's copy of the game to write every simulation step to a file: every car's record, and the chase camera too. So the race was recorded twice at once, its sound through PulseAudio and its steps through the log.
measure/sound_race.py turns the log into what the sound code reads: the camera as the listener, and each car's position, velocity and engine value. examples/race.rs replays it through pod-sound. It fires each car's engine event before the first step, a countdown voice each time the number on screen changes, and runs the frame update after every step.
The first take was full of holes. Up to half of each second was missing: under emulation the game does not keep Wine's default sound buffer filled. With a second of buffer in PulseAudio (PULSE_LATENCY_MSEC=1000) the second take had none. The VM's script now sets it.
What agrees
The six countdown voices ("5" … "1", "GO") are found in the recording by correlation, all at one delay from the replay (1,436 to 1,482 ms; the difference is the game's frame timing). Five of them come out at 0.96 to 1.00 of the replay's level. The first is weaker, because the engines start under it. For the engines, the replay's spectrum matches the recording's better at the same moment than five seconds later, and the way it changes over the twenty seconds after the start lines up at zero delay and nowhere else.
What does not
No stretch matches sample for sample. The game updates its sounds once a frame, after several simulation steps; the replay does it after every step, because the log does not mark the frames. So eight moving sound sources step their positions and pitches a little differently. The track's own sounds and the brakes and scrapes the car code fires are not in the log either.
Next: frame boundaries in the step log, so the replay can call the frame update exactly when the game does, and the car code's sound events as pod-physics ports them.