Blue or red pill?

[pkane2001]

4 minutes ago, mansr said:

The 10 kHz digital captures differ all the way through.

All of them are different from each other, or just the captures with different  SFS settings?

[mansr]

1 minute ago, pkane2001 said:

All of them are different from each other, or just the captures with different  SFS settings?

There are only two, one with each setting. Mani can of course make more if we deem it necessary.

[pkane2001]

18 minutes ago, mansr said:

There are only two, one with each setting. Mani can of course make more if we deem it necessary.

 

Strange. A few more recordings at each setting may help show if this was an isolated incident or something more significant.

 

[STC]

1 hour ago, manisandher said:

We can only conclude that playback was not bit-identical if:

 

1. the 14 digital captures denoted '1' (with SFS=0.1 in XXHighEnd) are all bit-identical to each other

2. the 16 digital captures denoted '2' (with SFS=200 in XXHighEnd) are all bit-identical to each other

3. the digital captures denoted '1' are consistently different to those denoted '2'.

 

I very much doubt that this will be the case.

 

Mani.

 

First, congrats to @mansr and Mani for going through this experiment for the benefit of all.

 

I am not familiar with XXhighender and therefore could you guys explain in plain english how by changing the SFS values the file remains bit -identical. My understanding is SFS tells how much of a track must be read into memory per chunk (quoting from phasure.com). The file size in SFS= 0.2 and SFS=200 cannot be identical despite the source file was identical but what actually processed after the changes in the SFS were not identical size and therefore they are no longer identical after reaching the memory.

 

If at all readily audible difference could be heard by the changes in SFS then the question should be asked how the sound is processed with different chuck size. 

 

[manisandher]

7 hours ago, mansr said:

The differences are only in the first ~8000 samples of each capture. Some captures are identical.

 

I realise this is anything but trivial, but have you managed verify that, discarding the first 45ms or so (due to the recorder's 'auto-record' function), all the captures taken during the A/B/X are indeed bit-identical?

 

Mani.

[manisandher]

6 hours ago, mansr said:

The 10 kHz digital captures differ all the way through.

 

I suspect I know what might be happening here.

 

The test file we were using was 24/176.4. I suspect one or more samples are being skipped at the beginning of replay with setting '1' (SFS=0.1). This would then mess up everything that follows.

 

I have a 16/44.1 10kHz test tone here. I'll redo the digital captures with this. (I'll use 'auto-record', so the first 45ms of each will have to be discarded.)

 

Mani.

[sandyk]

14 minutes ago, manisandher said:

 

I realise this is anything but trivial, but have you managed verify that, discarding the first 45ms or so (due to the recorder's 'auto-record' function), all the captures taken during the A/B/X are indeed bit-identical?

 

Mani.

 

 A very good point ! This MAY also apply to the end of the track ?

[manisandher]

8 hours ago, pkane2001 said:

 

I know it's early in the process, but could you and/or Mani, at some point, document what equipment  and software was actually used for playback and recording, and how everything was inter-connected? Software settings, file formats (source and recording), protocol conversions, etc. would all be useful to describe. This may aid in understanding, but also if anyone may want to reproduce the test in the future.

 

Hardware

 

The A/B/X setup was as follows:

 

 

The digital recorder was set to 'auto-record' and captured the whole of the A/B/X in real time.

 

Music Server

- bog-standard PC with lots of HDD storage

- used for nothing more than serving the file to the audio PC for replay

- controlled via RDC

 

Audio PC

- 16GB RAM

- Win10 OS loaded completely into RAM

- no SSD or HDD present in PC

- OS stripped right down using XXHighEnd's 'MinOS' mode

- mobo with PCI slot

- Musiland digital PCI card (dual BNC spdif outputs)

- i7 CPU

- Teradak linear PSU

- water-cooled (no fans in case)

- controlled via RDC

 

DAC

- Altmann Attraction

- RCA spdif input (BNC-to-RCA adaptor used)

 

Recorder

- Tascam DA-3000

- BNC spdif input

- set to 24/176.4

- 'auto-record' set to start/end at -54dB

 

Amps

- FIrst Watt F5-cloned monos

 

Speakers

- Tune Audio Anima full-range horns

 

Software

 

Player

- XXHighEnd (v2.09)

- 'Attended' mode (no extra 'throttling-down' during playback)

- way too many playback parameters to list here

- only one bit-identical parameter ('SFS') changed during A/B/X

- 4x upsampling using XXHighEnd's 'Custom' filter

- digital attenuation set to -18dB

 

File

- 16/44.1 'Persephone' - Patricia Barber 'Mythologies' 

 

Mani

[manisandher]

35 minutes ago, sandyk said:

 

 This MAY also apply to the end of the track ?

 

I think you're right.

 

Mani.

[mansr]

2 hours ago, manisandher said:

I realise this is anything but trivial, but have you managed verify that, discarding the first 45ms or so (due to the recorder's 'auto-record' function), all the captures taken during the A/B/X are indeed bit-identical?

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

[sandyk]

3 minutes ago, mansr said:

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

 

That's good news, as you now definitely have something worthy of further investigation.

 Well done, both of you !

[mansr]

2 hours ago, manisandher said:

I suspect I know what might be happening here.

 

The test file we were using was 24/176.4. I suspect one or more samples are being skipped at the beginning of replay with setting '1' (SFS=0.1). This would then mess up everything that follows.

 

I have a 16/44.1 10kHz test tone here. I'll redo the digital captures with this. (I'll use 'auto-record', so the first 45ms of each will have to be discarded.)

There's more going on. Audacity added some dither to the generated file, and finding the right alignment when the signal is periodic is tricky. I think we should redo the captures of this with an undithered 24/44.1 file instead. I'll prepare one.

[manisandher]

14 minutes ago, mansr said:

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

 

Excellent! Thanks for working this out.

 

Sooooooo...

 

Bit-identical playback can indeed sound different!

 

9 minutes ago, sandyk said:

... you now definitely have something worthy of further investigation.

 

Yep.

 

Mani.

[manisandher]

5 minutes ago, mansr said:

There's more going on. Audacity added some dither to the generated file, and finding the right alignment when the signal is periodic is tricky. I think we should redo the captures of this with an undithered 24/44.1 file instead. I'll prepare one.

 

Just let me know what you'd like me to do with it - something like 5x at '1' and 5x at '2'?

 

Mani.

[PeterSt]

30 minutes ago, sandyk said:

36 minutes ago, mansr said:

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

 

That's good news, as you now definitely have something worthy of further investigation.

 

Why ?

[manisandher]

9 minutes ago, PeterSt said:

Why ?

 

Peter, I would have thought that you would have welcomed this outcome. But perhaps not? In which case, what did you mean by this (earlier on in the thread)?:

 

On 2/10/2018 at 9:51 AM, PeterSt said:

Should be game changing.

 

Mani.

[STC]

4 hours ago, manisandher said:

 

Hardware

 

The A/B/X setup was as follows:

 

 

 

 

One last try....Is it possible that DAC treats different size chunks differently that causes the difference?

 

 

[pkane2001]

4 hours ago, manisandher said:

Recorder

- Tascam DA-3000

- BNC spdif input

- set to 24/176.4

- 'auto-record' set to start/end at -54dB

 

Mani, when you said earlier that you think the Tascam auto-start was responsible for some differences at the beginning of the captures, did you mean that the auto-record and the level of -54dB was responsible? Do you think that it didn't start capturing at the same point in time?

[PeterSt]

1 hour ago, manisandher said:

Peter, I would have thought that you would have welcomed this outcome. But perhaps not?

 

Without it being easy to see, I am responding to Alex's implied "see, I was right !". This, while what you (both) have been doing there isn't the slightest related to that. Of course I asked Alex without him answering (yet) so now it is too late for his objective answer.

If you like to see or sense it, my one-word-question ("Why ?") also implies that there's nothing much to investigate once one understands the mechanisms at play. Say how they were explained to some degree in The Lush thread. Anyway, a literal "could be worthy to investigate further" does not make sense in the context of this thread, unless it is about once again explaining to someone who -no doubt- does not require the explanation any more. So :

 

1 hour ago, manisandher said:

Should be game changing.

 

The sole fact that Mans would be convinced. Thus really, the only one really benefiting from "further investigation" would be Alex (at least that is how it is in my head). But maybe I am wrong.

 

I think you guys had a great time but also had a fruitful time + experience. Say towards the community. Right ? That is, this wasn't about you (or me for that matter). So IMO the game changing goes beyond Mans and if I may say so : he is a great sport to take up the challenge, and you are great that you managed to arrange it, Mani.

 

Let me add that when I read about the outcome last night, for me there was quite some suspense in it. So I can tell you that the SFS of 0.1 was not by idea about it, and when you asked I recall I suggested 1.00 (maybe I made a typo and said 0.1 indeed). So 0.1 can be too low and then can incur for skipped samples (as I explained earlier on in the thread), while thus 

a. you used 0.1

b. Mans mentioned "It is not bit perfect"

... which I was waiting for.

Meanwhile I was envisioning Mans having his ride back, coming home and ...

 

But it was OK after all.

 

That I could also envision the whole happening literally (having been at your place) is something else. It really read as a small thriller.

Thank you guys.

Peter

[PeterSt]

5 minutes ago, pkane2001 said:

Do you think that it didn't start capturing at the same point in time?

 

The thing it may do "at least" is swap the channels temporarily. Mani reported this earlier on on the Phasure forum (2016).

[pkane2001]

16 minutes ago, STC said:

 

One last try....Is it possible that DAC treats different size chunks differently that causes the difference?

 

 

 

Since the connection to the DAC is over SPDIF, timing of samples can easily drive the jitter characteristics of playback.

 

For some reason I had assumed that the test would involve a USB connection, but apparently not. Now, Mans may need to do some analysis in the analog captures of the test signals, as that’s where jitter will be visible.

[PeterSt]

20 minutes ago, STC said:

One last try....Is it possible that DAC treats different size chunks differently that causes the difference?

 

The easy explanation : Yes, because the current draw is different (also easy explanation : because the one is infinitely more spiky than the other).

[PeterSt]

2 minutes ago, pkane2001 said:

Now, Mans may need to do some analysis in the analog captures of the test signals, as that’s where jitter will be visible.

 

I don't think that will be possible. It is jitter which is the causing factor alright, but you can't measure that like this (if at all). And most certainly not with an ADC in between.

But if Mans thinks he can, we will (happily !) learn about it. I'm also not sure whether this was even the intention.

[manisandher]

13 minutes ago, STC said:

One last try....Is it possible that DAC treats different size chunks differently that causes the difference?

 

The DAC wasn't presented with "different size chunks" - it received exactly 176400 samples every second as a constant stream. The DAC had no idea how data was being handled in the audio PC, and neither did the digital recorder.

 

To my mind, the only mechanism that could account for bit identical replay sounding different is: different noise profiles entering the DAC by 'riding on' the digital signal from the audio PC, and interfering with the DAC chip as it's doing its job. Should these things be detectable in the analogue captures? Maybe. We'll soon find out once Mans has had a chance to do more analysis (I need to send him more captures).

 

If I were a betting man, I'd say that nothing untoward will be detectable in the analogue captures either 

 

Mani.

[pkane2001]

Just now, PeterSt said:

 

I don't think that will be possible. It is jitter which is the causing factor alright, but you can't measure that like this (if at all). And most certainly not with an ADC in between.

But if Mans thinks he can, we will (happily !) learn about it. I'm also not sure whether this was even the intention.

 

That was my other question: how was the analog output captured? I didn't see that on the diagram.

 

It's certainly possible to capture jitter in an ADC conversion from the output of the DAC. That's how jitter is normally measured, and I've done this with my DACs plenty of times. Whether the ADC was good enough to detect low levels of jitter, that's another question.