John Curl's Blowtorch preamplifier part II

Status
Not open for further replies.
Jump to Latest
S

simon7000

Member
Joined 2008
janneman said:
... or Charles is a reasonable normal person like you and me, and all what that entails.

jan didden
Click to expand...

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.)
 
J

jkeny

Banned
Joined 2007
SY said:
There's other possibilities. Are the bits being delivered to the DAC at the same time (for example)?
Click to expand...

Why would you care what's delivered to the DAC - you haven't shown any concern about this in the past! just do your usual FFT analysis on the DAC analogue out - isn't this what is audible, not what goes into the DAC? Why the pretense at caring about bit timing?
 
T

thune

Member
Joined 2010
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.
 
D

DF96

R.I.P.
Joined 2007
myweb.tiscali.co.uk/g8hqp/
Charles Hansen said:
Well, the bits were the same. That is why I performed the test -- to convince the programmer that the way his program delivered the bits could make an audible difference. . . . because the two programs had different amounts of jitter in the output data stream. Wrong.
Click to expand...
To me, this is a claim that the same bits were sent and with no timing problems which could be called jitter. Yet
the way his program delivered the bits could make an audible difference.
Click to expand...
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!
 
abraxalito

abraxalito

Member
Joined 2007
Charles Hansen said:
.
There is no contamination from the computer or ground loops because the DAC has total galvanic isolation from the computer via opto-isolators.
Click to expand...

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:
Status
Not open for further replies.
Top Bottom