Bit-identical playback CAN sound different

[PeterSt]

13 hours ago, pkane2001 said:

appears to not size properly on my Windows 7 computer.

 

Might it help :

 

 

You can size and Skin about everything individually. See the [S] button in the main screen.

 

Also notice that the [1] button in the top, implies a separator bar :

 

 

When not dragged sufficiently to the right, this part will be not in view :

 

 

[PeterSt]

1 minute ago, sandyk said:

this means that you should also also include the  original captured identical .wav files for transparency. 

 

so you can run a checksum over it, right ?

hahaha

 

I am not Mani. But let's have both feet on the ground for once. All of us. Just have fun. And assume that nobody is fooling. Or making mistakes.

[PeterSt]

28 minutes ago, yamamoto2002 said:

network traffic, background tasks, power state vary in time. computer display noise varies when drawing content is different.

 

You realize that it is all about exactly that, right ?

(but the taming of it by various means and in various base states (statuses))

[PeterSt]

4 minutes ago, manisandher said:

and yamamoto2002 is referring to the latter and how it might affect what the mic is picking up directly.

 

Oh, he surely may refer to that. In that case ...

But (and he may speak for himself), I don't think he does. Mind you, there's all the logic in the world that your led lights etc. may influence. But in the end it is all about that (too). So without that all eliminated, some things won't work out at all. Remember the struggle for Windows 8 (and AmirM never responding -hahaha), this ended up with this (my sig) :

 

 

Maybe I said it too clumsy, but without these things sufficiently arranged for, all is moot (too much electrical noise to even start doing things well).

Btw, @yamamoto2002, you are one of the best out there. So as a matter of fact all comments are appreciated. I mean, aren't we all still learning ... for the good cause ? I sure am. Mani is too.  Actually we all are. Audiophiles you know...

 

[PeterSt]

2 hours ago, March Audio said:

If you are up for it we can try a little experiment next week.

 

I hope I am allowed to say that it is totally beyond me what you are trying to achieve or prove ? 🙂

 

On 3/26/2021 at 1:09 AM, March Audio said:

Just stumbled across this.

 

So yes, you did.

 

On 3/26/2021 at 2:01 AM, March Audio said:

You will be lucky to get a 60dB signal to noise ratio when you need to be looking more like 120dB+.

 

The only thing you could be stating here is that it is super easy to hear differences beyond 120dB (of differences), am I right ?

No, I am not right, but this is because you missed the gist of this "experiment".

 

Bit perfect playback for two different situations, means

- the data arriving at the DAC is 100% the same.

 

Still perceiving differences audibly means

- Something in-DAC happens to change the sound.

 

This is actually all.

But what you missed is that this is incurred for. By voodoo or other means.

- What you can hear, can be recorded by microphone.

- What you can hear for differences should be able to be recorded by microphone.

And that is what happened. At least so far it seems so.

Note : That these differences can be incurred for is nothing new to me (and my software users) because the software was made to do that from day one (2006 or so).

 

Also see next post.

[PeterSt]

That this would happen (record it by microphone and you will be able to "see" it), is something I predicted the other day (in an other thread) and is probably why Mani conducted the test like this in the first place. My explanation of why this means would work out, while recording the output directly at the output of the DAC by means of an ADC does not work out at all, is this:

 

All what occurs for differences at the output of the DAC are so minute that they will disappear in the noise of everything digital. You may think that amplifying all with 20dB+ may unveil differences, but since you'd be amplifying the noise just the same ... no.

Still the differences *are* there.

 

Amplify all through the power amp, put t through some speakers and all, say, "resonances" of the differences because audible, thinking that the room too is a huge amplifier. Thus we can easily hear what's hard to record at the output of the DAC (output of the power amp probably still the same issue).

But as said, what we can hear in the room obviously can be recorded. By noisy microphone environment or not.

 

The gist of the thread is also about being under 70dB loud kitchen hoovers, and still being able to pick 10 out of 10 the differences.

That easy it is.

[PeterSt]

1 minute ago, March Audio said:

So if I understand you correctly what you are saying here is that rooms distort the sound so much

 

No, not distorts (although that too will happen obviously). Amplifies.

Compare with the anechoic room.

[PeterSt]

One of the most clear measures I always apply is the amount of "standing waves" behavior. Several years ago by now I ended with "nothing audible" (but still easily measurable). So if in a corner (pick your own) a lower frequency emerges louder, something is not on par.

But it counts for higher frequencies just the same (buzzing). This will be less caused by room reflections to begin with, but just implies wrong playback behavior.

 

And no room treatment at all ...

[PeterSt]

2 minutes ago, March Audio said:

So why should we assume that any particular playback software will always result in a noticeably different sound?

 

Over 12 years of (Phasure) forum posts do.

 

Plus it is the very reason I started writing my own. All sound different; Now I at least knew what's in there (as in: no anomalies, no mistakes ... bit perfect).

 

 

 

[PeterSt]

6 minutes ago, jabbr said:

playback software which converts/upsamples and filters the bits might certainly affect the playback.

 

Jonathan, sure. But this time it is not about those phenomena. Just different buffer settings, for example. Your DAC's driver could do it. Both output the same (net) data (both as bit perfect). Both will sound different.

And this is only that simple first step everybody could apply (with something like a DAC's driver control panel available). ... And then there was software ... As many as players exist, as many different ways they toy with buffers at numerous places.

 

But indeed, this subject is a bit old-fashioned by now. Still threads like these "have to" emerge in order to prove it to some.

[PeterSt]

 

 

...

 

This post from Yamamoto looks irrelevant or is at least hard to see through, but if Yamamoto himself does not see it like this, I will myself :

 

It seems unlikely to me that this noise is really audible like that (at -57dB or so only !) because else you would go crazy in that room and would have replaced the monitor('s supply if possible) long gone. But in my experience it does not work like that;

 

If you measure noises like this by microphone, the first thing what will happen is that you couple-in the electrical noise of what you think is audible. All the logic is there, ... except perhaps your perception in advance of what you should be able to hear. So Yamamoto, do you really hear this with your ears ?

 

Anyway, monitor's supplies are killing for audio and they should be banned as a first item from the audio electrical chain. Everybody (over at Phasure) knows this. This is also how we use Audio playback PCs which are headless (no monitor, not even a video card in there and btw also no keyboard and mouse). In the end *all* switching supplies have to be banned from the audio part of the chain.

Notice that this requires two fully separated earth systems, which not many people have (but I do).

 

Yamamoto, I think you will see that the level of the noise you can show there, will be highly related to unexpected other matters. It could be the cable used, it could be the grounding used. It could be a part of that measurement system that runs on batteries while it should run on the same grounded system ... etc. etc. etc.

Here is an example of a real happening, back from 2009:

 

 

I talk about -55 dB there,

In the same post I write this :

 

To eliminate all unnecessary disturbances I removed the microphone from in my case the Fireface800 which is the capturing device but kept reading the input. So, while before I was capturing the sound through air, now it is just from the electronics. Air molecule noise is avoided now, and only the electronics' noise is left. Here too the beautiful tone is visible. Now : When I connect an interlink anywhere in the audio system, the amplitude rises. Say, with 3dB. When I connect just a connector to that interlink, the amplitude rises again. 1 dB or so. When I connect a poor connector (like a cheap Y), the amplitude rises again. Can be 5dB. When I connect the NOS1 DAC without cabinet (this is how the whole subject started) the amplitude rises. 20dB. Yep. And the DAC wasn't even connected to the mains.

Read the above carefully please because this *is* how it works. And only when knowing *and* you have a microphone of some sort, you can find your best connections, hopefully avoiding all this sh*t,

 

Almost more importantly: When you have such piles of noise in order (not necessarily audible through air), would you think that differences occurring at say -70dB can ever come through ?

And this is the whole point. "We" over at Phasure are used to this stuff for more than a decade now. We behave according these physics. But this is also how we can hear deeper in the still noisy systems ... just because we generally may have tamed the noise(s) better.

 

I hope this helps someone.

Peter

[PeterSt]

5 hours ago, March Audio said:

So to be clear your position is that it's the rooms modification of the sound

 

Haha, why do you keep on changing subjects into ghosts ? Of course, I realize that everyone likes to find his own explanations, but why is it so difficult to see the amplification the room does, as an amplification of minute changes otherwise not measurable ?

Maybe I should add that no room really amplifies, but it reflects and makes sound "greater" (bigger). That's why the reference to the anechoic room/chamber. Such a room is dead. Such a room will also NOT lend itself to test for standing waves. ... Standing waves which are an exhibit of poor sound reproduction (outside of poor rooms / room nodes).

 

5 hours ago, March Audio said:

So to be clear your position is that it's the rooms modification of the sound which reveals the specific changes one software makes even though every single room makes often very different changes to the sound?

 

I am afraid it is worse; The same software changes (or players for that matter) imply the very same sound (Q) properties everybody perceives the same.

 

What worries me a bit (pun) more is that configurable USB cables for almost everybody implies the same SQ properties. This is only about shielding of cables and it works out the same for by far most (1000s of participants).

Have two quite random configs (out of more than 1000 in one cable) and I'd dare to take up the 10 out of 10 again (highly pretentious this one, because it is about the random pick of configs which I can't have learned in advance because of too many to ever listen to).

 

[PeterSt]

5 hours ago, jabbr said:

"bit perfect" playback has the implication to many people that the unmodified "pure" bitstream enters the DAC.

 

And so do I. Just set it to do that. Don't let the software upsample / filter. I suppose any software can still do that. :-)

In XXHighEnd that can be done too.

 

5 hours ago, jabbr said:

1) The computer becomes essentially the input filtering stage of the DAC in taking over the upsampling/conversion function which otherwise is typically done my the DAC. Your PCM1704 was often used with an 8x digital interpolation filter (on a separate chip). The connection between the computer and DAC should be seen as forming part of the DAC circuit.

 

Totally unrelated because it is not about that situation whatsoever.

 

5 hours ago, jabbr said:

2) at some point the analog characteristics of the digital signal become audible.

 

Following the above other two quotes ? No. It is not about that.

 

Apparently it is not easy to follow what's attested here:

 

1. Play back with one piece of software and one set of upsampling/filtering (hence do-not-change-that-ever);

2. Change a "buffer" of any type (numerous are in there).

--> The two files Mani uploaded are about #2. At the digital input of the DAC they would be equal (same checksums etc.). After loop-back to a digital capture, they would be equal (same checksum, but also the 100% same samples throughout). But they sound vastly different. Read Jud's quotes again. Or trust mine (I said the very same in advance of that).

3. Capture the sound of the two playbacks by microphone. Look at the diff files of it, might you be able to do something with that.

 

[PeterSt]

OffTopic alert

 

 

2 hours ago, Superdad said:

Oh, here's the thread: https://www.audioasylum.com/forums/pcaudio/messages/651.html  You can see that even 17 years ago I was trying to banish S/PDIF! 

 

Haha. I looked up my endeavors. This is from Sept. 21, 2006 (written to me):

 

 

-------------------------------

The application software should have a nice and simple to operate GUI (should be
discussed among us, also a remote control option would be perfect ), which
simply opens the wav file (checking header etc.) and send the PCM samples in the
same order like in the file to a kind of ring buffer. Via an API function the
buffer is read and written to the new product. The buffer size used by the API
function during a call must be approx. 64kByte, as the buffer size has a huge
impact on the transfer rate.

With other words, you simply transfer the data from the file via a buffer and
the API function. The API function must be called in a thread, so that the
program is free for other activities.
 
To have an understanding of the new product, you need to know that I have taken
a different approach.

The main problems are currently:

Audio sample clock is at the source.
Isochronous audio data streaming via USB with no guarantee of data safety
Extracting the clock via PLL from the data stream
Windows, software player etc.
Complicated software settings for customer
Different results in different systems

 

-------------------------

 

The product was there (on the market) 6 months or so later. But it could do 16/44.1 only. And I think it was in 2008 already that my own DAC prototype did 24/384. So I wasn't very helpful to this great guy (who wants to remain in secrecy). That real product started with S/PDIF though and already 6 months later (2010) I changed it to USB. Since then I am against USB because of its properties, never good to SQ.

One of the first posts in this (C/A) forum was a discussion with (started by ?) Gordon, that the jitter g-d kept on getting through to the endpoint (D/A). He couldn't understand the why of that. This, while my software did so on purpose. 💀

 

[PeterSt]

13 minutes ago, manisandher said:

makes it pretty much impossible to get consistent nulls in DeltaWave.

 

Mani, you won't be able to get nulls anyway because of the inherent noisy nature of molecules and microphones etc. etc.

You won't even be able to get two nullable files from an ADC connected to the output of your DAC. You know ...

 

So it is not about nullable - or close to nullable letting the real differences remain (OK, you knew that) but it is about consistently being able to come up with the differences which, well, really make the difference. You should at least do this at night and tell your wife and kids not to snore. And take breath keeping classes. 🤪

 

Maybe it is a hint to take your normal Lush^2 (or Lush^3) config and hold this against a totally dull sounding config. I have those for the Lush^2 for sure. For the Lush^3 I'd have to look.

About rooms ... do notice that the key exhibit of Lush configs is that the total energy remains, but the one config keeps all in a plane between the speakers and the other throws it out all over the room (depth). If you can't take that by microphone then I don't know what can.

 

20 minutes ago, manisandher said:

I'll link the new recordings in a short while, for anyone who might be interested in playing with them...

 

I would not do that (useless according to yourself).

[PeterSt]

2 minutes ago, manisandher said:

 

It seems to me that there's something fundamental at play here that is not well-established and accepted. I believe that if we can explore it with an open mind, there may be something really fruitful at the other end.

 

But wait ...

What's fundamentally wrong -for me and dad-sure- is that

- differences can be appointed easily;

- but the general consensus is that it is at a too low level to be audible.

 

In addition, the differences can not be qualified by anyone, except by me. 

 

 

So that one AGAIN (from April 2009, shown for the 100th or so time 🤪).

 

So it should be well accepted by now that a cursor tracking the running time - and which cursor jumps each one second - implies a deviation of the intended signal as you see above. A sudden jump, implied by a current spike, that dying out "slowly".

Although the time scale on top shows 16.9, the .9 being 1/10th of a second, and horizontally you see thus 0.07 or so of a second (from 16.900 till 16.970), you can just as well see this as samples (thus at the sample level). Vertically this surely is the case, when in this plot the highest resolution is 65536. Thus, might you be able to count 100 dots vertically for the spread shown, this implies a maximum of 100 out of 65536 (this is peak to peak voltage).

 

We don't need to do any math to know beforehand that this will be an inaudible deviation of the intended signal.

However:

 

14 minutes ago, manisandher said:

It seems to me that there's something fundamental at play here

 

that again.

As long as we all keep on thinking that these differences - clearly there - are not audible, then "we" won't get anywhere. Or "you" because I + customers exploit it (call it abuse) and proceed and proceed and proceed.

 

So while this is a discrete / qualifyable - even including patterns - plot, the diff files working at the "dB" level are not at all. They show differences alright, but we can't work wit hit. With what I show above, we can work. And back at the time I plainly used it to calibrate the playback for least deviating results. Easy as that. example : don't have a GUI so you don't have a running time visible and there you go. Another disturbing factor eliminated. Without GUI with have an OSD time. Well, don't switch it on because it disturbs as hell. Easily made visible by this means. Oh yes, still bit perfect.

 

We don't need to do any math to know beforehand that this will be an inaudible deviation of the intended signal ?

 

hmm

 

 

[PeterSt]

49 minutes ago, pkane2001 said:

I'd love to see the same type of a recording, with a modern DAC with a decent USB implementation. Nothing fancy, just a decent implementation

 

I understand (really).

 

50 minutes ago, pkane2001 said:

I see a lot of examples where the PC activity is reflected at the output of a DAC in case of a ground loop or just a poor differential USB implementation

 

So I think you will be able to show that. Then everyone (including me and thousands of Lush customers) will be able to see what they solve with the cable.

Paul, I am half-serious (but honest), but it is you who make the sort of counter claim. Tbh, I see only noise in your plots. And that with a cable comparison of ... what actually ? of that situation where you found differences (the poor implementation etc.) or where no differences are to be found ? Thus .., make that the poor one and please show some patterns. What I would call discrete and qualifyable. Maybe my terms are wrong.

[PeterSt]

1 hour ago, manisandher said:

Hypothetically speaking... At what level of resolution would the diff files have to be in order to be useful? -120dB? -150dB? -200dB? Or lower still?

 

There is no easy answer to this;

In my case I wanted to be genuine to the data in the file and did NOT upsample (/filter). Also, the DAC does nothing to the data (@pkane2001 you may notice a first difference here). The data was just Redbook as such. Thus 16/44.1. That's a theoretical 96dB plus a little of resolution.

 

The ADC I used, also was used at 16/44.1 because else it would be impossible for me to make the comparisons. Side note: Last year I tried to upgrade my analysis software so it would work with 24 bits upon 16 bit data, and I kind of failed. This already starts with the resolution of the monitor (I know, hard to believe) and 24 but being way too much for vertical resolution. Anyway:

I used one clock for both the DAC and the ADC which is totally logic (to me). This is already necessary to sync the starts 100%, or IOW, make the comparisons with the recordings as the base, infinitely repeatable (they were). I could also say: Paul, make us two recordings and show us two 100% the same dif files. If you can't then we *or* look at random noise after all, or you can't sync the samples (oh, you can by cutting off the earliest, but it takes way too much time for various dozens of tests).

 

Mani, with deeper looking into the noise, you'd also *see* more noise. This seems counterproductive to me. That's why I started referring to my 16/44.1 recordings. There can be (microphone etc.) noise in Redbook, but not as much as e,g. DVD-A (24/96 or 24/192). So when the noise is a. not in the recording (resolution too low) and b. not in the re-capture of it, all what remains are the chain-impeded differences. Be that Lush or XXHE or voodoo. Plus it would be at audible levels automatically.

 

...

 

How did I do ? total rubbish ?

I am used to that. Haha.

[PeterSt]

8 minutes ago, pkane2001 said:

I've run a stress-test utility while playing audio through a DAC and compared the result to a capture where the PC is not so stressed. The result? No measurable or observable difference, very similar to the null I posted earlier in both cases. What does that prove? Nothing,

 

Paul, it has about zero to do with stress of the PC. Some of (the best) settings in XXHighEnd imply a CPU usage of 100%. Ask anyone.

IIRC we went through this before.

[PeterSt]

8 minutes ago, pkane2001 said:

Maybe I misunderstand something... don't you believe in dither and analog noise?

 

I don't think you misunderstand. Buy possibly you missed my BS about (too much) bit depth and incurring for too much noise in the first place.

 

I forgot to tell that my analysis software shows that there's (IIRC) 3 decimal values of noise deviating (peak-peak 6).

 

 

So it will be the skill of using your "diff" means as a kind of FFT-like to see patterns.

 

PS: Funny, this is what the zoomed thumbnail shows at the bottom of the page:

 

 

 

[PeterSt]

@pkane2001Paul, maybe we can turn this into something also interesting; what if you provide me with the best Antelope direct-DAC-output recordings of two playbacks which you'd deem bit perfect. I am NOT asking for USB cable stuff but merely for XXHighEnd playback. Use case could be that same cursor thing. So one output with GUI and one without (Unattended). Mind you, just music and all else the same. Align the two and post.

 

Now *I* am going to try with DeltaWave to find the patterns. Maybe I can, maybe I can't. But the purpose: I might be able to see how things can be adjusted so differences become visible in a workable fashion.

 

I am asking you because you know your gear while my ADC is not operable at the moment (it died on me and I need to buy a new one). I also have analyzers, but for the cursor thing it will be useless. They will useless for everything, but at least I have them.

[PeterSt]

9 minutes ago, pkane2001 said:

I don't recall your explanation for what a blinking cursor does to cause audible changes at the output.

 

With "we have been through that" I referred to the apparent impossibility to make it clear (while it is so obvious, but blame me !).

 

All with the very best intentions:

 

Why would you come up with a stress test (of millions and millions of current spikes per ms) while I refer to a similar -but piled up- of spike of less than millions in the same time unit (ms) - where you thus cover up my cursor spike (pls think about this).

So apparently you can't think along these lines (my lines).

 

I have:

16 million of taskswitches per second which already is in the "minimized" (Audio) environment; Compare 50W usage with 130W system usage).

Add 100K of taskswitches so a cursor starts to move.

What do you see ? ... NOTHING.

 

Now turn those 16M switches into 400K (I suppose you can't because you won't know where to begin).

That cursor again adds the same 100K (it requires the same resources).

What do you see ? 25% extra rubbish.

 

Understand the equation ? sure you do.

 

Redrawing of the screen under Windows (two pixels imply the full screen) implies 10000 (ten-thousand) times MORE activity than without GUI and drawing to the most native canvas. 10K times more.

And in *that* environment you try to find noise of a(n e.g. !) buffer (size) change ?

 

In the other thread I referred to the virtual zero cpu usage when XXHE plays 32/705.6, in real time upsampling from 16/44.1. I know, it is the opposite of 100% usage but it is a setting. Now what if I would be able to incur for a hand full of taskswitches per second (the whole PC being dead) and next dunk my cursor thing on top of that.

 

All is unrelated to having the best isolation and further hardware and what not. It is 100% related to having all noise free FIRST.

... Which you seem to avoid because you are sure it won't matter anyway ... (Paul, please ...).

 

Now on to who is able to show the best sound

(which is childish but somehow related :-).

 

All 'n all we have been through this before. But I think you always deem it unimportant and lay it aside.

 

Btw, my mentioned figures are all real and have been spelled out on my forum at some stage (over time). Screenshots and such.

 

Paul, I hope it is clear that I am not on the blaming track here. At least you want to understand (I keep on repeating that foremost); stuff like computer response is a skill/profession I may own and of which I don't know a single soul elsewhere. Also not my own personnel (in the ERP software branch) and they work there for ... 35 years ?

So I am the idiot. Not you. And my English is not so English.

[PeterSt]

25 minutes ago, pkane2001 said:

Should have an RME ADI-2 Pro here by the end of the week :)

 

Ah, I planned for that myself. In that case I will also have one by the end of the week. :-)

 

Thank you, Paul.

[PeterSt]

20 hours ago, manisandher said:

21 hours ago, PeterSt said:

Ah, I planned for that myself. In that case I will also have one by the end of the week. :-)

 

I have one too 🙂.

 

Phew, I did not know they produced only 500 of the ADI 2 Pro FS R. And there doesn't seem to be a replacement ?

Yesterday I found only two stores who still had them. Today this diminished to one (I am counting out the obscure ones). So if all is right ... on its way now ! And if not right, then I found another obscure one.

[PeterSt]

On 3/30/2021 at 1:54 PM, PeterSt said:

So if all is right ... on its way now !

 

All is right indeed. Now as usual, find some play time.