As I pointed out before, your problem with DiffMaker is in the very fact that your loopback process is not bit-perfect, not that your computer is introducing random errors into the result that can be mitigated with Fidelizer.
There are several possibilities for this happening, but the two main factors are:
1. The bits being played out are being mapped to a smaller range of bits on the recording side. This could be due to a desire to prevent clipping, or a simple programming error.
2. The bits are being dithered. This often happens due to assumptions about the nature of the recording made by the software that cannot be overriden.
As I point out, others have gotten a bit-perfect recording
https://www.gearslutz.com/board/so-much-gear-so-little-time/471239-getting-bit-perfect-recording.html
And now so have I.
https://www.dropbox.com/s/cxllwudpsqb64p2/input.wav?dl=0
https://www.dropbox.com/s/7lsijcomhzgaxnn/output.wav?dl=0
input.wav was played through foobar in WASAPI mode at 24-bit to a S/PDIF output on my computer and recorded at the corresponding S/PDIF input using VSTHost and the MRecorder VST plugin at 24-bits as output.wav
https://www.meldaproduction.com/plugins/product.php?id=MRecorder
You may check for yourself that input.wav and output.wav only differ in the amount of silence before and after the test signals.
Aligning the starts of the tracks and inverting one then adding to the other yields digital silence:
Cropping the silence before and after the tracks and running through DiffMaker yields -300dB correlation depth, which is the same result you get by feeding it the same file for reference and comparison:
https://www.dropbox.com/s/7c3noeub0vl8qji/input-crop.wav?dl=0
https://www.dropbox.com/s/1xbrjyb0nkcsd8z/output-crop.wav?dl=0
At no point was Fidelizer running on my computer, nor did I attempt to lessen the load on my computer in any way.
Moral of the story: if you aren't getting a bit-perfect recording, you fix it by fixing your recording chain.