LW is correct that the acoustics engine draws a lot of cpu, but I think he overestimates its role in causing problems for the replay.
Replays have problems, that's for sure. But what causes these problems? Lack of cpu time? Hardly. Ergo: the acoustics engine doesn't affect it; at least not the part of it draining cpu time.
I think it's a coding problem more than anything else. Without looking at the code, I can only guess; but at least I can evaluate a probability for a guess. Here's my guesses for culprits.
#1: Storing only deltas, instead of the positions themselves. I remember there were statements that *could* mean this.
This means that if there is an incorrect update, the rest of the replay is pretty much bogus.
It also means that fast-forward and fast-backward is slow, and jumping to a very different time is very slow. We know that is the case from observation. ("keyframes" could mitigate this; as discussed in another thread - "third-party replayer")
#2: Insufficient accuracy in the deltas
The replay saying course and speed, but without accounting for wind and currents.
If true, this will really only have them "slide" from their original position. I've seen platforms "jump around". Still, it could be a factor.
#3: Race conditions, partial updates of values before they were recorded
Could probably explain at least some jumping around. These are usually quite hard to debug. Esp since there may be some safeguards against it, that the compiler just happens to optimize away
If this is part of the problem, then it's no wonder if SCS let dead beast lie
Those are
my guesses.