Blue or red pill?

[manisandher]

13 minutes ago, sandyk said:

If you succeed, the only person that you MAY convince is mansr, in which case I feel sure that he will do further investigations.

I presume that is your main objective ?

 

Bingo.

 

Mani.

[mansr]

15 minutes ago, sandyk said:

If you succeed, the only person that you MAY convince is mansr, in which case I feel sure that he will do further investigations.

If I become convinced there's a difference, I will certainly attempt to figure out why.

[pkane2001]

3 minutes ago, mansr said:

If I become convinced there's a difference, I will certainly attempt to figure out why.

 

And that's why Mans is such a good test subject for this: he'll be curious enough to dig in deeply to find the reason for audible differences (if any), and he'll collect enough data and evidence so that others could help him, right, Mans?

 

[sandyk]

6 minutes ago, pkane2001 said:

 

And that's why Mans is such a good test subject for this: he'll be curious enough to dig in deeply to find the reason for audible differences (if any), and he'll collect enough data and evidence so that others could help him, right, Mans?

 

 

 If mansr does investigate further, I would be more than happy to provide suitable comparison .wav files on USB memory for him.

[mansr]

5 minutes ago, pkane2001 said:

And that's why Mans is such a good test subject for this: he'll be curious enough to dig in deeply to find the reason for audible differences (if any), and he'll collect enough data and evidence so that others could help him, right, Mans?

I'll try. Well, if I hear the difference, that is. If I don't, I still hope to get some recordings of what Mani assures us sounds different.

[beerandmusic]

7 hours ago, PeterSt said:

 

- File is on NAS - Play.

- Copy same File from NAS to local - Play.

 

 

I thought the test was if played from tidal vs nas, not nas vs local hd??

 

If played from nas, then it would use internet interface and if played from local hd it would be played from usb?  So is this a test of usb vs enet or enet vs enet?

If usb vs enet, it will most likely sound different!!

 

[fas42]

2 hours ago, PeterSt said:

 

I agree with Alex. My listening is explicitly unconscious (environmental noise is no issue at all) or otherwise I can't do it. Things must pop out positively, or annoy negatively.

That counts for me and can be different for everybody. It can also take quite some time (because not explicitly watching for).

 

Yes, "things must pop out positively, or annoy negatively" - for me, differences in the digital stream are less relevant, meaningful than the "analogue impact" - variations, because the digital signal is slightly different, in generally unsatisfactory sound are not interesting, and of no value in furthering the listening experience.

 

Differences in the digital feed to the DAC are not the problem - it's whether the audible, distortion spectrum content generated in the analogue areas of the reproduction chain is being altered, via some mechanism.

[PeterSt]

5 hours ago, mansr said:

You don't need high precision timers to play back audio. In fact, you don't need timers at all.

 

Correct. And this is exactly why we can go sub-sample for the let-go of them. I mean :

 

5 hours ago, pkane2001 said:

Of course, high precision timers are available and should be used (for example, the HP counter on my audio PC, built about 4 years ago, has the frequency of 14.3 MHz).

 

Although that is correct too (and XXHighEnd utilizes the mechanism as a settable parameter) it does not mean we can exploit timers of that precision. And if so I don't know how to. But also it is unimportant because no timer is used anywhere in the sound engine.

 

5 hours ago, pkane2001 said:

Probably not, but I'm not the one who brought up timer precision -- Peter did

 

This was meant figurative to explain how the samples can be pushed out "per x amount" (which is what physically happens in the program). Make that per e.g. 100 or so at a rate of 705600 (16x Redbook) and the subsystems are too slow to follow. Thus, if I push out 100 samples each 1/7056th of a second, the overhead for e.g. the driver is too large to arrange for that in this short (round trip) time and the system as a whole drops samples without losing time (this is how the frequency (as in tone) stays the same and it goes unnoticed). The funny (or stupid or nice) thing is that instead of losing samples, the system as a whole when not intelligent should stall the outputting of buffers hence slow down the stream. But *that* now is not allowed because that *will* influence frequency (a one minute song would last 1m10, so to speak).

I have situations that the latter can be done just the same, but that is really the most wrong of all, as we can imagine. So there is no setting which really can imply that.

 

[PeterSt]

4 hours ago, fas42 said:

it's whether the audible, distortion spectrum content generated in the analogue areas of the reproduction chain is being altered, via some mechanism.

 

Yes.

 

4 hours ago, fas42 said:

Differences in the digital feed to the DAC are not the problem

 

And it is incurred for by exactly that. Funny eh ?

 

4 hours ago, fas42 said:

Differences in the digital feed to the DAC are not the problem - it's whether the audible, distortion spectrum content generated in the analogue areas of the reproduction chain is being altered, via some mechanism.

 

So the mechanism starts at mentioned digital feed, all the way up to e.g. Tidal servers, so to speak - if we recognize that streaming as such is a process which influences negatively what happens in the DAC and also that streaming is quite out of control because the processing involved can hardly be under any control as in the "put out per 100 samples" example (previous post). Only when reading (the stream) could be sample per sample, it theoretically can be under control again.

But before we end up with a Lush thread again - better read through that once more.  The basis are in there (about current draw etc.).

[PeterSt]

4 hours ago, beerandmusic said:

I thought the test was if played from tidal vs nas, not nas vs local hd??

 

I saw you writing two times that "since PeterSt explained that this what about Tidal vs local, you understood" ...

But I never said anything. I gave a link to where the subject originates and somewhere there you must have gone off track.

 

Of course it is about streaming over the internet (like from Tidal) vs "local" just the same (but in even more rough fashion), but Mani tears this down to NAS vs Local inside the audio playback PC. Many would call this "streaming" as such, but I don't because it isn't in the sense of what streaming is when done from the Internet (many people call PC Audio "streaming" already). Notice that both streaming and "not streaming" are very close to each other but the technical means to process the samples is not the same. This is also related to the behavior of the playback software and how "memory players" are different from genuine streamers. Compare :

 

- Read into buffers the samples from an audio file (could be internet), play these samples, read into buffers again, play these samples

vs

- Read (chunks of) the audio file into memory, arrange them in an array, and play the audio from there all in one command, or per chunk because too large to fit in memory.

 

For those who like to know : XXHighEnd does the latter but can behave as the former by making the chunks as small as you want, like the "100 samples" example. Now it is a memory player with streaming behavior but it is still a memory player inside. Btw, this is this SFS (Split File Size) mentioned earlier by Mani.

The other end of the spectrum is thus "the whole file" but with proxies (think in terms of caches) because the whole file usually won't fit into memory. But by guarantee :

 

Any file from the NAS or other upstream server, will be copied as a whole to the local Audio PC first because no real means of streaming is present in XXHighEnd (it is just too bad to SQ). So what Mani is unavoidably talking about is :

 

- File on NAS will be copied to the local Audio PC environment;

- Network will be shut down for these kind of services (remote control part stays alive);

- Audio starts playing by said reading of chunks from now local file.

 

What Mani now claims is that this situation :

 

- Mani copies file on NAS manually (over LAN or via USB pen or whatever means) to the local environment;

- Playback is now done of that local file by just selecting that file (instead of selecting the file on a NAS).

 

... sounds different from the former situation. Thus :

File played from NAS vs file played from Local

... while both actually start out as being the same, once the file arrived from the NAS locally.

 

No, I would not bet about this very situation and that I would be able to hear the difference. And *if* there is a difference it is because there's no dying out processes from the copy from LAN/NAS activity when played from the NAS which happens under the hood.

 

To make it more complicated and confusing, mentioned Local environment in the Audio PC is ... Memory.

So the Audio PC does not even contain any storage medium (the OS was booted from RAM and sits in RAM fully). There's a drive C: alright, but it is pure RAM.

So what I just say is that the audio file *does* fit in memory after all. What ? whole albums reside in there. Even Hires. But this is different from a whole album residing in the earlier mentioned arrays (where they are fully expanded to their upsampled size and one 5 minute track will occupy a multitude of Gigabytes).

If now that chunk size (the SFS) is set to ultra large (like 400 would imply 30 seconds or so of 705600 material) it sounds like sh*t. Dull sh*t. And all what happened is that we numbed the system (the file reading part has come to virtually stand still). But is it ? or is it perhaps so that *when* it wakes up, so many hefty system processes require processor and all activity that the whole lot gets out of balance and inconsistent (SQ wise) and needs dying out for 10 seconds.

 

So see ? easy. We just covered 10 or so parameters, some with virtual stepless settings, which all work together (or against each other).

Of course some may think that someone like me is imagining all these audible differences for all the years passed and that he just likes to write odd software. OK, you believe me anyway. But now it really comes down to checking those bits (samples) still being the same when arriving at the DAC. I know, they are. But ...

 

But nothing. 

 

Mani already knows about all of this, as do all XXHighEnd users. But at least Mansr now knows a bit of this too and you guys have a bit of a talking board. So I hope this helps.

 

[manisandher]

2 hours ago, PeterSt said:

Any file from the NAS or other upstream server, will be copied as a whole to the local Audio PC first because no real means of streaming is present in XXHighEnd (it is just too bad to SQ). So what Mani is unavoidably talking about is :

 

- File on NAS will be copied to the local Audio PC environment;

- Network will be shut down for these kind of services (remote control part stays alive);

- Audio starts playing by said reading of chunks from now local file.

 

What Peter is describing here is what is called 'Unattended' playback in XXHighEnd. But there is another mode called 'Attended', where the file from the NAS is not copied to the local audio PC before playback, and the network is not shutdown. The difference between these modes is the '680,000 vs. over 60 million task switches per second' that Peter mentioned earlier.

 

Peter, Attended vs. Unattended is something I'd definitely like to demonstrate to Mans. However, I was intending to do the A/B/X purely in Attended mode, which would make the A/B/X easier to perform. I've checked and I can clearly hear the difference between SFS=20 and SFS=1, which should suffice for the A/B/X.

 

Mani.

 

 

[Audiophile Neuroscience]

On 2/13/2018 at 1:57 AM, Spacehound said:

They are unlikely to spend much time  studying  something they 100% misunderstand from  the moment it's switched on and which they do not wish to understand

 

On 2/12/2018 at 7:03 PM, Spacehound said:

the 'myth and magic' crowd will say the methods are faulty. They always do. Not, of course, that they would have taken the trouble to understand the methods anyway.

 

On 2/13/2018 at 1:08 PM, Spacehound said:

 Much like Doctors, Airline pilots,  Quantum mechanics,  Vets,  etc are in their fields. All are  totally useless of course. 

 

9 hours ago, Spacehound said:

I know it won't prove anything to them, and said so earlier. 

 

It's interesting how these kind of threads bring out some people's biased assumptions.
 

17 hours ago, Spacehound said:

There ya go. You've decided already,  Before it's been done.

....and the kettle calling the pot black

 

 

 

7 hours ago, manisandher said:

 

No, there's too much evidence to the contrary - numerous people all over the world describing the differences they hear in exactly the way I hear them. Should it happen though, I'll concede that I've failed to prove I can hear any difference, and let people conclude what they want; either that I'm deluding myself, or that an A/B/X isn't the right way of testing.

Mani.

 

I believe this is the only scientifically valid conclusion. Trying to put aside agendas one way or another, if Mani is unsuccessful to a certain statistical level of significance it still allows for error. Similarly, unless the null hypothesis is formulated in words such as "never shows a difference" or"impossible to show a difference" even if Mani is successful, again to a certain statistical level of significance, it still allows for error. The error is risk that confirming or dis-confirming the null hypothesis is wrong. Aka Type I and II errors and the whole gamut of true/false positives and true/false negatives.

 

Noting that confirm and dis-confirm are not *typically* held to be proofs and indeed doctors are sometimes cautioned by statisticians that accepting a null hypothesis, an intervention making no difference (placebo), is not the same as the treatment intervention being of no real  benefit (not just placebo) in all circumstances. As much as as a cautionary medical approach prefers "false alarms" (Type I)  to a "miss" (Type II), the fact is both errors can cause harm to the patient. At the end of the day we are dealing in probabilities not proofs. At the end of the day clinical (or real-world) and statistical significance are not one and the same thing. It is all relative to the situation and a matter of weighing the probabilities, Type I and Type II errors.This remains true whether testing for verifiability or falsifiability. It is just easier to test for falsifiability where one counter example dis-confirms (rejects) the null hypothesis.

 

And yes. like it or not, much of the above hinges on the validity, reliability, sensitivity, specificity of the test determining outcomes. Blind testing is NOT the issue.It is a necessary controlling factor under which the *test* is carried out.That is not the same as saying audio testing ABX methodology is bullet proof for complex musical passages. It just seems to be assumed so on audio fora in a kind of hand me down fashion or 'its all we have right now so go with it'. I wish there was scientific data to verify it's credentials.

 

 

 

7 hours ago, pkane2001 said:

 

Nobody is pressuring Mani. He chose the format, he chose the venue and he chose the music. He can do whatever listening evaluations he wants, as long as he can't tell which source is playing.  I've done tests like that many times and found it no more stressful than doing them sighted. If not knowing which component is playing induces so much stress that the 'not subtle' differences become too subtle to distinguish, then perhaps one should pick another hobby.

 

What may or may not be stressful to you may be quite different for others.

 

 

 

[PeterSt]

OK, maybe this appears even to be useful ...

 

16 minutes ago, manisandher said:

But there is another mode called 'Attended', where the file from the NAS is not copied to the local audio PC before playback, and the network is not shutdown.

 

That only will be true for files which don't need conversion whatsoever (like plain .WAV that nog being HDCD encoded), the "Always copy to XX Drive" not active, no Playback Drive filled in, Always clear Proxy active ([C] button in the main screen, near the bottom stays red) and all else I don't think about because it is and can't be a consistent SQ setting for all those different cases that copying has to be in order for reasons of its own.

 

But I think it may go like I kind of predicted - it will be something else which changes the sound - in your example (or in your envisioned case) the network staying on in full vs. switched off largely). And again if still necessary : this caching parameter (as a net functional result of all) is not under your control.

Also, for the mode you work in (which is "getting your files from somewhere at the LAN") I recall that all is overruled with "Always copy to XX Drive" = Active, because certain processes would be too slow otherwise (this is about how the LAN breaks down a burst command into smaller packages with as a result you waiting for the kind of obtainment which occurs in this case). And indeed, I just checked - it is so. Copying can not be prevented.

I suppose you have been set on the wrong foot by means of this message occurring when you switch off the "Always Copy to XX Drive" :

 

 

So this message should not occur any more and in your situation the "Always Copy to XX Drive" field should be greyed out and show active always, as it *is* active always. Btw, this won't prevail that you still might receive problems as indicated by the message if you switch off the field and go for Unattended (LAN may never come on or whatever, in certain situations).

 

You will be able to show a difference in SQ, but you both will fail on the explanation. You just won't know what is going on where and when.

For now, as far as I am concerned, you could have lived by expectation bias. Could have. In reality it should be the LAN being almost off vs fully on because nothing tells me why you should be wrong; you're too experienced. But now for the others.

 

Sorry to be your pain ! ... but in the end it is all about this, right ? and the testing is d*mn difficult.

[Spacehound]

1 hour ago, Audiophile Neuroscience said:

.....and the kettle calling the pot black.I

Not at all.

Unlike some I know how 'digital' actually works. We made it from scratch in about 1943 and it hasn't changed  significantly since.  (We didn't pick it off a tree and try to  figure it out.)

And I am aware of the exact point in the 'chain' where 'differences',  if  the inputs are identical,  might  begin to occur. And said so.

 

They don't argue with their heart surgeon, or airline pilot, Why argue with us? We are equally qualified in our field.

 

Where a discipline overlaps  the lay public's 'experience' this often occurs. In fact their opinions  are  just 'noise'. They are like many 'do it yourselfers' who do not have the knowledge to realise how poor their efforts actually are.

 

 

[PeterSt]

5 minutes ago, Spacehound said:

And I am aware of the point in the 'chain' where 'differences', if any, will begin to occur. And said so.

 

And are incorrect about.

[manisandher]

On 2/10/2018 at 4:10 PM, Spacehound said:

I've got about 20 ways of playing the same thing...

 

...snip...

 

As long as I don't change the DAC/Network player I don't hear the slightest  difference between any of them.

 

Luck for you - you can just sit back, enjoy, and not think about any of this stuff.

 

Mani.

[manisandher]

@Audiophile Neuroscience thanks for your insightful post.

 

Mani.

 

 

[manisandher]

45 minutes ago, PeterSt said:

You will be able to show a difference in SQ, but you both will fail on the explanation. You just won't know what is going on where and when.

 

I'd consider that a good first step, considering where Mans is coming from.

 

Mani.

[Spacehound]

30 minutes ago, PeterSt said:

 

And are incorrect about.

No.

I am aware of your DAC/player,  they are highly thought of, and you have a totally different approach than anyone else. Which includes, I believe 'manipulating' the digital input, so all bets are off.

 

And that approach may be superior. I would like to hear one.

 

But as I suspect I would not buy it, having a 'good enough' DAC already,  the chance of my buying it are extremely low. So unfortunately it would not be worth your while to provide one for me to try. I'm in the UK. Were I in your country I would jump at the chance. 

[Spacehound]

15 minutes ago, manisandher said:

 

Luck for you - you can just sit back, enjoy, and not think about any of this stuff.

 

Mani.

I'm interested in what you are doing, and am not actually on a particular 'side'. But if I am wrong about this the entire 'digital' world will need  to be rethought (which is happening but which is not about audio, though there is no inherent reason why it shouldn't be). 

 

And I don't think you have any kind of 'duty' to 'prove' anything .

[PeterSt]

3 minutes ago, Spacehound said:

Which includes, I believe 'manipulating' the digital input, so all bets are off.

 

This is silly.

Hey, you claimed to understand digital. And maybe I should refer to the process as a whole.

But do you really ?

[PeterSt]

Just now, Spacehound said:

But if I am wrong about this the entire 'digital' world will need  to be rethought

 

We cross-posted over this, but ... aha.

That is, your rethinking is required. 

[PeterSt]

7 minutes ago, manisandher said:

 

I'd consider that a good first step, considering where Mans is coming from.

 

I agree.

[rando]

@PeterSt It just occurred to me how much your English has improved since the early days of Mani's lovefest thread for the Lush cable.  

[manisandher]

9 minutes ago, Spacehound said:

And I don't think you have any kind of 'duty' to 'prove' anything .

 

I have no inclination to prove anything to anyone.

 

But I do have a desire to demonstrate what I hear to @mansr, hence the invitation.

 

Mani.