There's other possibilities. Are the bits being delivered to the DAC at the same time (for example)?
... or Charles is a reasonable normal person like you and me, and all what that entails.
jan didden
Wow! You are the first to apply that term to me! (The report is that he did correctly distinguish the data, not imagined he did. The probability is tilted in his favor, so lacking details the most likely answer is that there was a difference. For his needs there was little to be gained by additional testing. Since the premise is not solidly defined added tests yield others little additional information.)
He got a bit irate at the suggestion that bit timing might be the explanation. I think the compound word "know-nothing" was used to describe people who said this.
Well, if it means that I can unravel a mystery, anyone can hurl any imprecation that they desire in my direction.
Of course it is 🙂
CH says he can hear an audible difference between playback software. You surmise that there might be differences in timing of the delivery of the bits to the DAC. So what are you suggesting that you will test?
CH says he can hear an audible difference between playback software. You surmise that there might be differences in timing of the delivery of the bits to the DAC. So what are you suggesting that you will test?
A software coder asserts: his code to convert to 64bit float and back is bit-identical. If a claim is to be tested first, it is this. I didn't read Charles Hansen's post to claim he heard a difference in bit-identical audio streams, only that he heard a difference in audio streams a software coder claimed were identical.
To me, this is a claim that the same bits were sent and with no timing problems which could be called jitter. YetCharles Hansen said:
But how is the DAC (which is buffered) aware of software bit delivery? There seems to be a handshake between the DAC buffer and the data source. If the software is slow to respond to a request for more data then there would be a timing problem. This is not necessarily the same as jitter, so timing could be the explanation. The data could be jitter-free (in the normal sense of the word) yet with small gaps. The programmer may deny this, but in my years in IT I learnt to ignore what programmers told me about their code. They, wisely, often ignored what I told them about my code!
Galvanic isolation refers to isolation of grounds at DC. So Charles do you think that only DC ground contamination matters in regards to sound quality?
<edit>
There's actually a fourth group of 'know-nothings' - those who claim that blind tests prove something.
Last edited:
Optoisolation is a fairly good way of isolating problems, so it does avoid a whole class of potential complications. It doesn't just isolate grounds, but could reduce stray capacitive coupling too.
I've used optos myself before, but never to isolate a problem. Usually to isolate grounds at low frequency.
That is rather meaningless!
Not to isolate a problem? So if you didn't isolate grounds at low frequency (and I don't know where you get that qualifier from *) it wouldn't be a problem?
* galvanic in this context is NOT just DC.
You guys are wasting your time. A 16 bit number "remembers" that an MPU converted it to a 64 bit float and back again. Such abuse.
- Status
- Not open for further replies.