Since the error rate needs to be fairly low in order to make it worth decoding EFM at all, the most likely type of error here is a single bit being flipped. So when a CRC error is detected, try flipping each bit in turn and checking the CRC again.
The improvement from this is very small because ld-process-efm already guesses the timestamp when the CRC fails based on the previous frame (so it's only improving the cases where the guessed timestamp is wrong, which I guess might happen after a long dropout?). It'll still fall back to this behaviour if correction doesn't work.
Without this (slightly rotten EE 1035 side 4 with EFM capture):
Since the error rate needs to be fairly low in order to make it worth decoding EFM at all, the most likely type of error here is a single bit being flipped. So when a CRC error is detected, try flipping each bit in turn and checking the CRC again.
The improvement from this is very small because ld-process-efm already guesses the timestamp when the CRC fails based on the previous frame (so it's only improving the cases where the guessed timestamp is wrong, which I guess might happen after a long dropout?). It'll still fall back to this behaviour if correction doesn't work.
Without this (slightly rotten EE 1035 side 4 with EFM capture):
With this, 95% of the Q-channel CRC errors are corrected, and we get a little more valid audio out: