The report was that the background music was too quiet in the deployed build. Barely audible. That turned out to be true, and turning it up would have fixed almost none of it.
The theme is meant to score the loading screen and then step back once the place appears, so the engine and the street have the room. What actually happened was the opposite. There was silence over the wait and then a few seconds of music after it, which reads as a fault, because it is one.
The music could not start until a request for optional recordings came back. On an idle connection that is instant and nobody would ever see it. On a loading screen it is queued behind the place itself, which is the whole point of a loading screen, so the answer arrived about when the town did. The theme faded in exactly as the arrival faded it out. It builds the music first now and asks about recordings underneath it, which is what the title screen had always done and why the title screen never had this bug.
Then the volume, which was real. The theme was rewritten for solo piano some weeks ago and lost about nine decibels doing it. Nobody heard that happen, and there is a reason nobody heard it: the tool used to audition arrangements matches their loudness before playing them, so you can judge the notes without the louder one winning. Matching loudness is the correct thing for that job and it is also an excellent way to never notice that something has got quiet. The notes were being judged, approved and shipped, and the level fell out from under them the whole time.
The third one was the worst, because nothing about it was audible at all. Recorded audio is kept out of the repository for licensing reasons and served from storage instead. There is an index of which recordings exist, and it is built by looking at the folder they are kept in. Build the deployment, which is the one place that folder is deliberately empty, and you get an index that says there is no recorded audio anywhere. An empty list is not the same as no list, and the code treated it as authoritative. Every recorded sound in the deployed build was being refused on the strength of it.
That one had been silent in both senses for a while, because a recording being blocked and a recording not existing sound identical from a chair. The fix is that the index only gets a vote when it is describing the place the files are actually served from.
The thread running through all three is not about audio. Each was correct in the environment it was written in and wrong in the one it ran in. A fetch that is instant on a fast connection. A comparison that is fair when you are comparing. A file listing that is accurate where the files are. None of them look like bugs when you read them.
There are checks for all three now, and the useful part is that they measure rather than assert. One renders the real audio path and reports how loud it is. One hangs every network request forever and listens, which on the old code is exact silence.
Two things are being tested alongside the demo at the moment. Neither has shipped and neither is close to it.
The first is phones. Right now a phone gets a wall rather than a place, which is honest but is not where this should end up. The hard part is not getting something to appear on a small screen. It is holding a frame rate worth having without trimming the capture down until it stops being the place you came to see. So what is actually happening is measurement, across a spread of devices rather than one good one. A recent phone and a two-year-old phone give different answers and the second is the one that decides whether this works.
The second is captures that move. Everything drivable today is one frozen moment. Still air, fixed light, and anything that was moving during the capture is either smeared into the scene or gone. 4D Gaussian splatting, capture that carries time rather than a single instant, is being tried separately from the demo. It is the thing standing between this and weather, traffic, and a day that turns.