Will SQ between HDD VS SSD VS RAM be measurable for digital audio?

[PeterSt]

This was my first thinking too. But there is no error there. Look at the right side of that spread sheet, notice the offset mentioned, and then look at the error. There is none ...

Ok, so this was totally wrong from me. I compared that right side with the RAM column. But the right side *is* the RAM column.

PS: You can check my comparison with the files you have, I didn't edit them.

You guys (Window X and ipats) have easy talk here. But I guess someone wanted to tell (at least to me) that you (ipats) and me are doing the same thing on the same files ? Language stuff I gues. Well, then it is good we have the same results (or the same conclusion) ...

Window X, I think I may know of an easy way to check whether your recording dithers, or whether the playback is not bit perfect for whatever reaons; it only will not exclude the both being wrong :
Record silence.
So remove that treshhold I was talking about, and just press "record". A few seconds will be enough. Now the file should contain all the same data ... If not, something is going on on that part of the process.

[Flecko]

rounding is strange. 0.000024->0.000028?
It's binary rounding, not decimal. I guess that the audio softwares work in floating-point, and may also the sound hardware. So, when it convert sample to PCM integer, it need rounding and also dithering. I didn't round any sample, I used the original sample value from files I got. So, I have no clue which process the rounding take place. All I did is find the offset and compare those files.

I think this is most interesting. So if the binary to floating point conversion could be avoided, then we could translate the binary data to PCM without loss of information.

[PeterSt]

Very far (sought) you are correct. One problem : when there is no reason to convert to float a player should not. Now, if *this* suddenly starts to be a reason players are not "bit perfect", well ... that would be new. Or at least to me it would be. So, now it's not the OS doing anything, but a stupid player is ? it very well could be. Also, don't ask me to what degree this may influence the HDCD light; it just might stay on ... I don't know. I don't think the DTS test will pass though.
I don't have the experience on this really, because I always check the files themselves (like I did it here). ipats is actually the first one I run into who does this too. Maybe because he was asked to (by Window X), I don't know. So, all I know is that everybody always comes up with that HDCD light (DTS is more old fashioned).

But why not ? If some player feels that it's a good think to start to convert to float first because of *possible* volume or other DSP stuff, I guess it will come down to this, yes. If this really happens ? Maybe JR does it like that.

One thing : XXHighEnd most certainly does not, and it is therefore bit perfect (but don't use upsampling of course). I always checked it myself too, although it is somewhat longer ago by now. In the very old days I used Foobar to check for bit perfectness - not to check Foobar, but to check the OS. At least back then all was OK on the Foobar side.

So, I don't think the chance is very high that players make this fault, already because people would still use the DTS test here and there. Otoh, JR-Event etc. is rather new, so, who knows ...