Blue or red pill?

[STC]

21 minutes ago, pkane2001 said:

 

Why the insistence that only bits are significant? It is a well-known fact that poor timing of samples can cause jitter, and that large jitter can be audible. Before postulating noise or other less likely (and less measurable) causes of audible differences, can we please eliminate the well-known and obvious ones, first?

 

+1. I don't know why one need to be so defensive. There is a difference (albeit a very small one and cannot be distinguished reliably under all circumstances)  let's find out why.

[manisandher]

6 hours ago, mansr said:

... but I still trust that Mani didn't consciously cheat.

 

Thanks.

 

I based my responses purely on what I was hearing in the music. Did X sound more similar to A or to B, both played in that order just before X.

 

Mani.

[manisandher]

4 hours ago, acg said:

I dunno that it did morph into something very different.

 

I don't think it did either.

 

On 2/9/2018 at 10:31 PM, manisandher said:

I'd start by simply copying a track from my NAS to a local folder in the audio PC and playing the identical files back from their respective locations. That'll break his belief system right there. We can then explore other areas if he's interested.

 

I posted this very early in this thread, in a fairly cocky sort of way, before Mans had accepted the invitation. I really didn't think that he was going to accept. But he did! I then needed to drop the cocky attitude and get serious.

 

Once it became clear that Mans wanted to capture digital and analogue outputs, I started thinking more deeply about the A/B/X and how most easily to perform it.

 

What we needed was a change that would keep bits identical, but that would sound different enough for me to identify. The options were:

 

- different storage media & locations

- different digital cables (spdif, USB, etc)

- different software player configurations (buffers, etc)

 

I needed to choose something that I would be confident using in an A/B/X (which I'd never done before). I decided on different software configurations.

 

Mani.

[manisandher]

7 hours ago, pkane2001 said:

... the simplest explanation of the differences you heard is just poor timing or even missing samples due to SFS=0.1 in XXHighEnd. Peter does not deny this possibility.

 

There were no missed samples. Peter may have thought it a possibility at one point, but it was put to rest by Mans' verification that the digital captures were identical.

 

7 hours ago, pkane2001 said:

I still hold out the hope that analog captures will show some differences in jitter pattern between the two settings.

 

And if they don't? Surely things get kind of interesting then, no?

 

Mani.

[manisandher]

11 hours ago, manisandher said:

Understanding the exact mechanism at play in this instance is of interest more generally too, because it'll be the same mechanism that causes playback from two different locations to potentially sound different.

 

7 hours ago, phosphorein said:

Why would this be true?

 

Whether you're changing the location of a file, changing some digital hardware (USB cable, or whatever) or changing a player setting, if things remain totally bit-identical and the sound changes, then there must have been a change in the jitter signature reaching the DAC. To my mind, the only mechanism that could be causing different jitter signatures are different noise profiles generated in the audio PC, somehow finding their way to the DAC.

 

You think there may be other mechanisms at play?

 

Mani.

[manisandher]

6 hours ago, esldude said:

Was the digital feed bit identical or not?

 

Bit identical.

 

6 hours ago, esldude said:

Was there just a glitch in recording that gave some differences in the bits?

 

The Tascam did something weird during the first 50ms or so when set to 'auto-sync' mode.

 

6 hours ago, esldude said:

Is it determined that the recordings were in error, but actual bits listened to by Mani were the same?

 

22 hours ago, mansr said:

Skipping the first 10k samples, they are all identical.

 

~14,950ms of all the recordings are perfect. The first ~50ms of some of the recordings are in error. I didn't base my responses on the first ~50ms of listening, I can assure you.

 

6 hours ago, esldude said:

Is anything learned from the analog captures?

 

I'm keen on seeing what Mans comes up with.

 

Mani.

[PeterSt]

19 minutes ago, manisandher said:

7 hours ago, pkane2001 said:

I still hold out the hope that analog captures will show some differences in jitter pattern between the two settings.

 

 

18 minutes ago, manisandher said:

And if they don't? Surely things get kind of interesting then, no?

 

Mani, ehm ... No.

It only will testify that what you perceive for difference can not be measured.

It would be a good idea if someone write out a course (we call that a webinar these days)  showing how jitter measurement goes, what it takes to really show differences, and what gear it takes to capture for real what we're hunting for.

Line one would show : what you want is impossible, forget it.

And the webinar would be over.

 

That a few people think that two analogue takes ever can be the same, is an other huge misconception.

Of course it gets rather "complex" (ahum) to draw the conclusion from the fact that no two analogue takes can be the same, you thus also can't ever prove from such situation that two different takes deviate.

They all deviate in the first place, right ?

 

I politely await Mans's results. But don't blame him if he can't show it and also don't draw wrong conclusions from his finding that all differs everywhere (thus also two takes from the same SFS etc.).

 

 

 

[manisandher]

5 minutes ago, PeterSt said:

It only will testify that what you perceive for difference can not be measured.

 

And that's exactly my point. This is perhaps the biggest 'red pill' in all of this.

 

Mani.

[manisandher]

19 minutes ago, PeterSt said:

... and also don't draw wrong conclusions from his finding that all differs everywhere (thus also two takes from the same SFS etc.).

 

No, the only conclusion to be drawn is that although the effects of jitter can be heard (I hope I've convinced people that this is the case), they can't be easily measured... even with a modern ADC* set to 24/176.4.

 

* Tascam DA-3000 specifications:

- THD+N, 1kHz = 0.005% or less

- S/N = 111dB or higher

 

Mani.

[esldude]

18 minutes ago, PeterSt said:

 

 

 

 

What is the vertical scale on this graph?

 

What is the horizontal scale?  Is it samples or something else?

[esldude]

8 minutes ago, manisandher said:

 

No, the only conclusion to be drawn is that although the effects of jitter can be heard (I hope I've convinced people that this is the case), they can't be easily measured... even with a modern ADC set to 24/176.4.

 

Mani.

That is going much too far.  We don't yet know what you heard.  We don't know that it was jitter.  To convince of that you need to know the jitter differed and you heard it.  Hearing "something" and assuming it is jitter while saying such jitter can't be measured is not at all convincing.  

[manisandher]

16 minutes ago, esldude said:

That is going much too far.  We don't yet know what you heard.  We don't know that it was jitter.  To convince of that you need to know the jitter differed and you heard it.  Hearing "something" and assuming it is jitter while saying such jitter can't be measured is not at all convincing.  

 

OK, let's wait and see what Mans comes up with. I'll be interested in hearing your thoughts if/when the analogue captures show no consistent differences between the two playback settings. (There will obviously be small differences between all the analogue captures.) And yet I heard consistent differences in the A/B/X.

 

In which case you'll have to come up with something that can be heard, but is not easily measured, even with a modern ADC.

 

BTW, the ADC has far better specs than the DAC.

 

Mani.

[fas42]

44 minutes ago, PeterSt said:

 

 

Mani, ehm ... No.

It only will testify that what you perceive for difference can not be measured.

It would be a good idea if someone write out a course (we call that a webinar these days)  showing how jitter measurement goes, what it takes to really show differences, and what gear it takes to capture for real what we're hunting for.

Line one would show : what you want is impossible, forget it.

 

 

I wouldn't say impossible, just very, very difficult - I've had a go a couple of times, but ran out of puff and motivation to follow through - the software to do the job has to be exquisitely crafted, to ensure that you are really measuring what you think you are; all the slippery but benign behaviours of analogue waveforms have to be accounted for, and nulled, to expose the precious lode of significant differences, in the context of subjective SQ.

[PeterSt]

 

58 minutes ago, esldude said:

What is the vertical scale on this graph?

 

Max granularity of the level. This was tuned such that one dot vertically would be able to be visualized on(to) the resolution of the computer's monitor (monitor's pixels couldn't round or cut).

If this was 16 bits (but I forgot as this was from 2009) then vertical granularity is thus 1/65536 on a vertical scale of 65536 (this is both negative and positive signal).

 

Quote

What is the horizontal scale?  Is it samples or something else?

 

Time Seconds. Thus 16.900000 is 16.9 seconds and the 900 under it represents 16.900.  the 910 mark implies 16.910.

Total span on this screen is thus ~0.1 second.

 

To the left of the .920 mark we see the ADC's noise combined with the DAC's noise. In the end this is the noise of both "systems" (recording and playback).

This noise is not related to misalignment as I took care of both systems using the same clock source.

 

Red line is the reference (which is another recording). The plotted dots are the deviation. Both recordings are from real (the same) music. Only the "environment" was made to be different. Say very similar to what Mans and Mani applied.

Digital output of these both is as bit perfect as can be.

 

[mansr]

9 hours ago, pkane2001 said:

There are two main factors that can alter audible playback of recorded (PCM) audio. Actual sample values (bits), and sample timing. Just because bits were (mostly) the same says nothing about timing. Since in a standard SPDIF transmission the clock is derived from the timing of samples, and thus fully controlled by XXHighEnd, then it's possible that XXHighEnd is changing this timing enough to make the differences audible.

Is it fully controlled though? The S/PDIF output is clocked by a crystal oscillator on the sound card. There is nothing software can do to influence this.

[manisandher]

8 minutes ago, mansr said:

The S/PDIF output is clocked by a crystal oscillator on the sound card.

 

The DAC reclocks the data synchronously too.

 

Mani.

[mansr]

3 minutes ago, manisandher said:

The DAC reclocks the data synchronously too.

The DAC uses a PLL (or similar device) to recover the S/PDIF clock. Some are better than others at suppressing jitter.

[pkane2001]

49 minutes ago, mansr said:

Is it fully controlled though? The S/PDIF output is clocked by a crystal oscillator on the sound card. There is nothing software can do to influence this.

 

The source controls the timing with SPDIF. Any errors at the source, including poor oscillator, poor or noisy power environment, as well as sample starvation due to slow processing or due to software buffer being too small will result in changes at the output of the DAC. 

 

[pkane2001]

3 hours ago, esldude said:

That is going much too far.  We don't yet know what you heard.  We don't know that it was jitter.  To convince of that you need to know the jitter differed and you heard it.  Hearing "something" and assuming it is jitter while saying such jitter can't be measured is not at all convincing.  

 

Right. The reason I suggested checking for jitter is that it is a possible (and a known, well-studied) source of audible differences, and if present, can point to a possible reason Mani heard differences. From Peter's description, SFS setting might also cause timing issues. But, just because I mentioned jitter doesn't mean that was it!  That part still remains to be tested and proven.

[manisandher]

39 minutes ago, pkane2001 said:

Any errors at the source, including poor oscillator, poor or noisy power environment, as well as sample starvation due to slow processing or due to software buffer being too small will result in changes at the output of the DAC. 

 

Such changes at the output of the DAC will be easily detectable in the analogue captures of the 10kHz sine tones we took for each of the two software player settings.

 

My analysis has already given me the answer, but I'll wait for Mans to report back.

 

Mani.

[PeterSt]

41 minutes ago, pkane2001 said:

The source controls the timing with SPDIF. Any errors at the source, including poor oscillator, poor or noisy power environment, as well as sample starvation due to slow processing or due to software buffer being too small will result in changes at the output of the DAC. 

 

Inherently you are right there. But still it doesn't make sense because the digital output has been tested as bit perfect. But I can rephrase it somewhat :

 

The source controls the timing with SPDIF. So if jitter (signature) is implied in the PC in this case, it will exhibit at the output of the DAC (it's just passed on in direct fashion - no "reclocking" as such anywhere).

So indeed, if we look at this, I suppose the whole test can be re-done including the whiskey. With SPDIF it would be a "too normal" situation to incur for. Not that we really think about that these days, but with SPDIF - AES/EBU it sure is like this. Too bad.

 

All what remains now is : but trust me, with async USB still the very same happens.

Not worth much, right ?

 

Back to the drawing table.

[mansr]

14 minutes ago, pkane2001 said:

The source controls the timing with SPDIF. Any errors at the source, including poor oscillator, poor or noisy power environment, as well as sample starvation due to slow processing or due to software buffer being too small will result in changes at the output of the DAC.

Yes, buffer underruns in the sound card are a possibility. However, this would be visible as glitches in the digital capture since the S/PDIF formatter doesn't stop and wait. Rather, it will (typically) read whatever is in the memory location where the real sample data should have been and send that.

 

Another possibility is extreme contention on some system bus causing the sound card's internal fifo to underflow. In this case, it would likely send zeros or repeat the last sample until the data flow recovers. On any reasonably modern system, you'd have to try really hard to cause this situation. I seriously doubt this is what is happening.

[manisandher]

3 minutes ago, mansr said:

Yes, buffer underruns in the sound card are a possibility. However, this would be visible as glitches in the digital capture since the S/PDIF formatter doesn't stop and wait. Rather, it will (typically) read whatever is in the memory location where the real sample data should have been and send that.

 

Another possibility is extreme contention on some system bus causing the sound card's internal fifo to underflow. In this case, it would likely send zeros or repeat the last sample until the data flow recovers. On any reasonably modern system, you'd have to try really hard to cause this situation. I seriously doubt this is what is happening.

 

In either case, the digital captures would not be bit-identical, right? And they are bit-identical, so neither can be happening.

 

Mani.

[pkane2001]

3 minutes ago, mansr said:

Yes, buffer underruns in the sound card are a possibility. However, this would be visible as glitches in the digital capture since the S/PDIF formatter doesn't stop and wait. Rather, it will (typically) read whatever is in the memory location where the real sample data should have been and send that.

 

Another possibility is extreme contention on some system bus causing the sound card's internal fifo to underflow. In this case, it would likely send zeros or repeat the last sample until the data flow recovers. On any reasonably modern system, you'd have to try really hard to cause this situation. I seriously doubt this is what is happening.

 

Can you please summarize what you've looked at so far, and your findings? Like esldude, I'm a bit confused where captures are bit-perfect and where there are differences that you've found. Do you plan to continue the analysis, and would you be able to share the captures at some point (both analog and digital)?

 

[manisandher]

On 3/26/2018 at 9:23 PM, mansr said:

While 9/10 in one trial wouldn't impress a statistician, it's enough to make me intrigued.

 

Would getting 8 answers correct in a row? The probability of achieving this based on guessing alone is 1/256.

 

Mani.