Blue or red pill?

[Ralf11]

35 dB is a lot of Bells...  but can -85 dB level be heard?

[esldude]

43 minutes ago, Ralf11 said:

35 dB is a lot of Bells...  but can -85 dB level be heard?

If people took part in online listening, I'd let everyone hear examples both ways.  My experience with that is nearly no one will bother as they are afraid of being wrong. 

 

Whether it is heard is not something I have good info on.  There is a little bit of semi-rigorous testing that was done with different dither types to indicate modulated noise floors will sometimes be audible lower than you might think.  As for trying it myself I have not tested myself carefully. 

 

I use the poor device as part of sound for a video system, and don't notice it while viewing movies.  I've listened to music before I measured this device and my opinion would have been it was murky, soft-edged, and not quite see thru clean or true to source on good recordings.  There was no sense of it being nasty or etched sounding.  Just not transparent.  Some might even have liked it being soft focused.  Of course all sighted anecdotal information from long term listening like a true audiophile.  YMMV, but only if you're not a REAL AUDIOPHILE like myself. 

[Audiophile Neuroscience]

On 3/27/2018 at 7:20 AM, manisandher said:

During the 3rd test, I was noting my results in a notebook. Meanwhile, Mans was using a random generator on his phone, and also noting the order of playback on his phone. Once we had done 10 A/B/Xs, we compared the two lists. I ticked all those correct. Here's the page from my notebook:

 

 

Yep, that's 9/10!

 

Mani.

 

Big Congrats Mani !!

 

I haven't been following all of this thread but gather you scored 9/10 on the ABX and 4/10 on the ABXXXXXXXXX.....

 

Fully agree that A then B then random X (A or B), rinse and repeat 10 times, is a fairer test procedure than ABXXXXXXX... for obvious reasons.

 

Mathematicians please correct me but is that a p-value of roughly 0.01 or 1%. If so, enough to impress most statisticians idea of "significance level". You may recall that I suggested you pre-decide what your significance level would be (< .05, less than .01 etc *before* you started the test). If accepted as significant meaning your observed result unlikely occurred by just chance and the null hypothesis (no audible difference between bit identical files) is therefore rejected. Possibly you may need to repeat the exercise a few times or increase the number of trials to be more confident of the result but as it stands, mission succeeded.You've provided enough evidence to make people curious and as I understand it, that was your aim

 

Cheers

David

[manisandher]

25 minutes ago, Audiophile Neuroscience said:

Big Congrats Mani !!

 

Thanks David.

 

It was a relief that Mans's visit wasn't a total washout.

 

25 minutes ago, Audiophile Neuroscience said:

Mathematicians please correct me but is that a p-value of roughly 0.01 or 1%. If so, enough to impress most statisticians idea of "significance level".

 

That's my understanding.

 

25 minutes ago, Audiophile Neuroscience said:

You've provided enough evidence to make people curious and as I understand it, that was your aim

 

Yes, exactly.

 

If I've managed to make some of the more 'objectivist-leaning' people here curious, I think it's 'job done' as far as the invitation/visit was concerned. Hopefully, that curiosity will now fuel some further thinking on the subject.

 

What I'm particularly interested in is how a [not particularly good] human ear can detect differences between bit-identical playback reasonably easily (in the A/B/X, at least) , and yet the differences seem difficult to identify when analysing the DAC's captured outputs. And it can't be a matter of resolution - the ADC was 24-bit, the DAC only 16-bit.

 

I'm hoping Mans will come up with something, but fear that the analogue captures he has simply aren't up to the job, for whatever reason. No doubt we'll know soon enough.

 

There's a mystery to be solved here.

 

Mani.

[Audiophile Neuroscience]

32 minutes ago, manisandher said:

yet the differences seem difficult to identify when analysing the DAC's captured outputs. And it can't be a matter of resolution - the ADC was 24-bit, the DAC only 16-bit.

 

I'm hoping Mans will come up with something, but fear that the analogue captures he has simply aren't up to the job, for whatever reason. No doubt we'll know soon enough. There's a mystery to be solved here.

 

Yes, I also hope Mans finds the measurable correlate. Perhaps because I rely on tests for a living I have become a 'test skeptic'. I don't share the view that if there is a difference it will be necessarily measurable. You know, you measure the wrong thing, wrong tool, wrong method and not the least, "Not everything that can be counted counts and not everything that counts can be counted."
-William Bruce Cameron

[mansr]

I've been away for the past week, but now I'm back home and can resume the analysis of this.

[manisandher]

Great. Look forward to hearing about your findings.

 

Mani.

[Miska]

On 4/3/2018 at 5:00 AM, pkane2001 said:

SPDIF is a very different protocol. The timing is controlled entirely by the PC. The data is sent continuously and the clock is embedded in the  data signal. This means the timing of the data must be very well controlled by the PC. There is simple parity check, but that does not help with timing errors. If the source clock is poor or noisy, the output of the dac will be jittery. 

 

The "controlled by the PC" is a bit vague. If you use USB-to-SPDIF converter for example, most of those use asynchronous USB transfer and the timing is driven by the clock in the converter. I have bunch of such devices, including bare ones like the first generation M2Tech hiFace and newer Musical Fidelity V-Link192. These are pretty good sources, although with V-Link I needed to cut the ground connection of AES cable at receiver end to make it actually floating (otherwise the DAC output easily had ground noise issues).

 

If you use something like Lynx AES cards, those have their own clocks too and are not as such timed by the PC.

 

But in the end it depends on definition of "by the PC", if anything connected to the computer is counted in, then yes. But, yes of course S/PDIF and AES/EBU transfer clock with the data, so the timing ultimately relies on the source and is just massaged by PLL's at the receiver end. Same goes also for Bluetooth, AirPlay and such. At best, digital PLL's can do pretty good job at recovering clocks. End result naturally depends on combination of transmitter and receiver quality/capabilities in this case. At best, it can be really good, better than poor asynchronous USB implementations.

 

[Miska]

On 4/3/2018 at 4:25 AM, STC said:

Now going back to the data coming from XXHE, can the SFS influence how much data reaches the DAC's sample buffer. Whether the smaller SFS creates more errors or delays in the sample buffer which translates to different latency and becomes audible?

 

That is determined by the USB protocol and the audio device driver. Player software cannot really influence that.

 

[pkane2001]

3 minutes ago, Miska said:

 

The "controlled by the PC" is a bit vague. If you use USB-to-SPDIF converter for example, most of those use asynchronous USB transfer and the timing is driven by the clock in the converter. I have bunch of such devices, including bare ones like the first generation M2Tech hiFace and newer Musical Fidelity V-Link192. These are pretty good sources, although with V-Link I needed to cut the ground connection of AES cable at receiver end to make it actually floating (otherwise the DAC output easily had ground noise issues).

 

If you use something like Lynx AES cards, those have their own clocks too and are not as such timed by the PC.

 

But in the end it depends on definition of "by the PC", if anything connected to the computer is counted in, then yes. But, yes of course S/PDIF and AES/EBU transfer clock with the data, so the timing ultimately relies on the source and is just massaged by PLL's at the receiver end. Same goes also for Bluetooth, AirPlay and such. At best, digital PLL's can do pretty good job at recovering clocks. End result naturally depends on combination of transmitter and receiver quality/capabilities in this case. At best, it can be really good, better than poor asynchronous USB implementations.

 

 

A USB-to-SPDIF box simply moves the source of the clock to outside the PC to the converter, it doesn't change the fact that the clock is still outside the DAC. The SPDIF part carries the embedded clock, but this time it's coming from the converter and not from the PC. I have a few of these as well, and some have 10x worse jitter than feeding the DAC directly from SPDIF output on my motherboard  while others are much better (such as an SU-1, f.i.)

 

[STC]

20 minutes ago, Miska said:

 

That is determined by the USB protocol and the audio device driver. Player software cannot really influence that.

 

 

Long ago there used to be a tweak to improve the SQ by removing the clock of the transport and to use only one clock; that is the clock DAC. If I remember correctly it was early modification offered by Lampizator. In those days all connection from transport used to be via SPDIF. 

 

In the above experiment, the sample buffer sends the data according to the timing of DAC’s clock. I was just wondering the difference due to SFS could somehow influence the DAC process even though it was receiving identical data on both occasions. 

 

 

 

 

[semente]

2 hours ago, STC said:

 

Long ago there used to be a tweak to improve the SQ by removing the clock of the transport and to use only one clock; that is the clock DAC. If I remember correctly it was early modification offered by Lampizator. In those days all connection from transport used to be via SPDIF. 

 

In the above experiment, the sample buffer sends the data according to the timing of DAC’s clock. I was just wondering the difference due to SFS could somehow influence the DAC process even though it was receiving identical data on both occasions. 

 

 

 

 

 

If I remember correctly Lessloss used to clock-slave a CEC transport to their DAC.

[austinpop]

I just tuned into this thread. Very interesting!

 

Most heartening of all is the (mostly) civil and open dialog between the subjectivist and objectivst diasporas.

 

If only we could apply this to other red/blue areas of our society.

[STC]

5 hours ago, semente said:

 

If I remember correctly Lessloss used to clock-slave a CEC transport to their DAC.

 

I think you are right. Thanx. 

[Audiophile Neuroscience]

 

Posted 38 minutes ago

6 hours ago, semente said:

 

If I remember correctly Lessloss used to clock-slave a CEC transport to their DAC.

 

 

I recall reading this against asynchronous reclocking https://www.lessloss.com/faq.html?q=asynchronous-reclocking

[fas42]

In all this processing, the "jewel" is the circuitry which is doing the actual job of converting the waveform which has digital meaning, into an analogue relevant form - the tight group of electronics which is doing this has to be as pristine as possible ... all the digital side can be as dirty, as jittery as one can get away - on the scope it can look a complete mess, so long as the digital data content is never lost or corrupted. But the core conversion area has to be like the clean room in an integrated circuit fab shop - scrupulously bereft of any unwanted "stuff"; outside can be as noisy as you like, so long as nothing can worm its way into the clean area, via any gaps in the "shielding".

 

Then, in the following circuitry which conditions and carries the analogue representation to the amplifier, etc, all care must be taken.

 

Worrying about everything in a sloppy way will probably still contaminate the waveform; concerning oneself with precisely what matters and getting this right, is the optimum strategy.

 

 

[Ralf11]

that is inside of an IC ...

[fas42]

36 minutes ago, Ralf11 said:

that is inside of an IC ...

 

In some cases, not in others - say, dCS, or MSB. If there is only a single chip doing the job then that single part can be screened as necessary - this sort of engineering is trivially applied in RF circuits. Also, every single pin going into the chip could a carrier of unwanted noise, etc - this needs to be carefully scrutinised, thought through, dealt with appropriately.

[adamdea]

14 hours ago, STC said:

 

I think you are right. Thanx. 

You can do this with an audio lab m-dac, which has a clock output, and various transports with clock inputs eg arcam delta 170.3 and others. 

I bought one of these a while ago out of curiosity. 

[STC]

16 hours ago, adamdea said:

You can do this with an audio lab m-dac, which has a clock output, and various transports with clock inputs eg arcam delta 170.3 and others. 

I bought one of these a while ago out of curiosity. 

 

Thanx for confirming. So it looks like clock from source is not needed. Just by slaving the clock to DAC the sound could be altered to what appears to be bit identical data. 

[Confused]

I have been a long time follower of this thread, but I have been more reading and observing than posting.  

 

First to say, much respect to Mani and his ability to get the 9 out of 10 result.  I have tried a bit of A/B and ABX type testing myself, and I know just how mentally draining and mesmerising it can be, so as I say, much respect from me.

 

In amongst the many posts though, I come to a basic conclusion.  Mani's results are convincing enough to indicate something has changed.  When using an S/PDIF feed, the DAC needs to extract the clock from the source.  In addition, the DAC may be subject to influence from any noise in the source.

 

In this test, a minor change is made in terms of how the source accesses and delivers the music file.  So in simple terms, I would have to conclude this has made a minor change to the performance of the clock in the source, or alternatively the noise from the source to the DAC.  I do not know the exact reason for this change, but clearly there is some change or Mani would not hear it.

 

Plus, unless I have missed a key post somewhere, whatever this change is it cannot be measured.  Or maybe it can, but not with the measurement apparatus available.  Maybe it cannot be measured with any apparatus currently available or that has been applied to audio?

 

So what we have here is a minor change that is audible (or at least by Mani) but is not easily measured.

 

Have I missed the point somewhere?

[manisandher]

53 minutes ago, Confused said:

First to say, much respect to Mani and his ability to get the 9 out of 10 result.  I have tried a bit of A/B and ABX type testing myself, and I know just how mentally draining and mesmerising it can be, so as I say, much respect from me.

 

Thanks. Yeah, until someone gives this a go (it was a first for me), it's hard to appreciate how strange it can feel.

 

53 minutes ago, Confused said:

So what we have here is a minor change that is audible (or at least by Mani) but is not easily measured.

 

Have I missed the point somewhere?

 

I'd say that everything you've written is bang on.

 

I'll just add that it's reasonable to assume that different DACs would react differently to the bit-identical changes we made during the A/B/X. However, I've had a whole bunch of DACs (USB, AES, S/PDIF, PCI(e), and firewire) here over the years, and without exception, all of them were influenced in the same sort of way by the exact same change we made in the A/B/X.

 

Perhaps the only way to make a DAC truly immune to these sorts of influences is to block the digital signal altogether - if the digital signal can get through, so can noise at the same sort of frequency. In which case, we'd better learn to live with, and perhaps start manipulating to our own advantage, the noise entering the DAC... which I think has been @PeterSt's quest for the last 10 years or so.

 

Mani.

[beerandmusic]

31 minutes ago, manisandher said:

Perhaps the only way to make a DAC truly immune to these sorts of influences is to block the digital signal altogether - @PeterSt's quest for the last 10 years or so.

 

Mani.

 

huh?

if you block the digital signal to a dac you won't have any output?  I am confused?

[pkane2001]

1 hour ago, Confused said:

Plus, unless I have missed a key post somewhere, whatever this change is it cannot be measured.  Or maybe it can, but not with the measurement apparatus available.  Maybe it cannot be measured with any apparatus currently available or that has been applied to audio?

 

What you’ve missed is that no analysis or review of the data has been published yet, so any conclusions about immesurability are premature. The rest of what you’ve posted is correct.

[manisandher]

6 minutes ago, beerandmusic said:

I am confused?

 

38 minutes ago, manisandher said:

Perhaps the only way to make a DAC truly immune to these sorts of influences is to block the digital signal altogether - if the digital signal can get through, so can noise at the same sort of frequency. In which case, we'd better learn to live with, and perhaps start manipulating to our own advantage, the noise entering the DAC... which I think has been @PeterSt's quest for the last 10 years or so.

 

I was suggesting that it might be impossible to block certain noise getting into the DAC, without blocking the signal itself. In which case, the only choice is to manipulate the noise getting through to the DAC, in a sonically advantageous manner.

 

Hope that's clearer now.

 

Mani.