Bit-identical playback CAN sound different

[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 ...

[March Audio]

8 minutes ago, PeterSt said:

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 ...

Well my point still stands; that every room and its effects on the sound is different.  So why should we assume that any particular playback software will result in a noticeably different or better sound?

[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).

 

 

 

[jabbr]

On 3/22/2021 at 2:24 PM, PeterSt said:

 

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

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

Perhaps we can explain this this way:

 

I think most people would accept that it is uncontroversial that playing back a bit identical stream through two different DACs will sound different? Right? I hope so because there are only those with a somewhat extreme view that believe the sound of the music is determined solely by the bit stream.

 

If we accept that a difference in any electronic circuit causes a difference in SQ, then we need to realize that software in fact modifies the electronic circuit in the playback chain. This should be entirely uncontroversial actually. I'm surprised that this debate continues....

[fas42]

Just now, jabbr said:

If we accept that a difference in any electronic circuit causes a difference in SQ, then we need to realize that software in fact modifies the electronic circuit in the playback chain. This should be entirely uncontroversial actually. I'm surprised that this debate continues....

 

The electronic circuit is not modified, in most situations, but the pattern of electrical activity over a certain time period varies, because of software changing the way the circuit operates. Therefore, if there is any breakthrough of electrical noise from the digital to the analogue side causing audible SQ changes, then changing the spectrum of that noise, by changing the nature of the activity, is highly likely to be audible.

[jabbr]

14 minutes ago, March Audio said:

Well my point still stands; that every room and its effects on the sound is different.  So why should we assume that any particular playback software will result in a noticeably different or better sound?

 

It should be fairly obvious that playback software which converts/upsamples and filters the bits might certainly affect the playback. All software provides some type of transform. It should be entirely uncontroversial that software might affect SQ, what is the argument here? This should be entirely uncontroversial.

[jabbr]

4 minutes ago, fas42 said:

 

The electronic circuit is not modified, in most situations, but the pattern of electrical activity over a certain time period varies, because of software changing the way the circuit operates. Therefore, if there is any breakthrough of electrical noise from the digital to the analogue side causing audible SQ changes, then changing the spectrum of that noise, by changing the nature of the activity, is highly likely to be audible.

Sorry you just don't understand how computers work if you don't understand how software forms part of the electronic circuit. 

[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.

[March Audio]

5 minutes ago, jabbr said:

 

It should be fairly obvious that playback software which converts/upsamples and filters the bits might certainly affect the playback. All software provides some type of transform. It should be entirely uncontroversial that software might affect SQ, what is the argument here? This should be entirely uncontroversial.

There is nothing controversial about the the idea that software which modifies the data has the potential to audibly change the sound.

 

However we are talking about "bit perfect" software which does not modify the data.

[March Audio]

21 minutes ago, PeterSt said:

 

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).

 

 

 

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?

[jabbr]

3 minutes ago, March Audio said:

However we are talking about "bit perfect" software which does not modify the data.

As the digital stream enters the DAC it ceases to be entirely digital and becomes an analog signal. No one is saying that the analog streams are identical. 

[March Audio]

Just now, jabbr said:

As the digital stream enters the DAC it ceases to be entirely digital and becomes an analog signal. No one is saying that the analog streams are identical. 

Those changes will be the same if two players feed the same data.

[jabbr]

7 minutes ago, PeterSt said:

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.

 

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

 

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.

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

[jabbr]

4 minutes ago, March Audio said:

Those changes will be the same if two players feed the same data.

faulty assumption

[March Audio]

7 minutes ago, jabbr said:

faulty assumption

Not an assumption, its based on testing.

 

Anyway please take part in the forthcoming test.

[jabbr]

41 minutes ago, March Audio said:

Not an assumption, its based on testing.

 

Anyway please take part in the forthcoming test.

Yeah yeah this is a oermathread — show me the data please. 

[March Audio]

9 minutes ago, jabbr said:

I would require measurements that go from 0Hz to RF/EMI. Nothing personal but I’m not holding a breath waiting for someone to do this. Do your testing and publishing it and I’ll take a look. Most tests make lots of false assumptions. 

This wont be a "measurement" test, its a subjective test about what you can hear.

 

Whatever may or may not be going on out of the audible band, to be audible it must have effect in the audible band.  It must be something you can hear.  So lets see what you can hear.

[jabbr]

2 minutes ago, March Audio said:

This wont be a "measurement" test, its a subjective test about what you can hear.

Not interested, I’m happy with what I can hear.

[March Audio]

Well thats a shame, its what this thread is about.

[fas42]

22 minutes ago, jabbr said:

Sorry you just don't understand how computers work if you don't understand how software forms part of the electronic circuit. 

 

There is a hardware level - the physical bits of silicon, etc, on the board - and the software level - the instructions that drive the physical bits ... I would class changing the electrical circuit something like software activating a set of relays activating and deactivating two mainframes next to each; so one took over from the other, and the latter had its power cut.

[March Audio]

4 minutes ago, jabbr said:

Not interested, I’m happy with what I can hear.

So I am surprised that you wont participate in a listening test.

[jabbr]

3 minutes ago, March Audio said:

Well thats a shame, its what this thread is about.

We were just talking about electrical changes and you switched it to subjective hearing tests — your methodology is irrelevant to me.

[March Audio]

7 minutes ago, jabbr said:

We were just talking about electrical changes and you switched it to subjective hearing tests — your methodology is irrelevant to me.

This thread is clearly about the subjective - what people can hear.  How "Bit-identical playback can sound different"

 

I would be really grateful if this doesnt degenerate into some pointless semantic argument.  Those that wish to participate in some fun tests can, if you dont thats fine.

[Jud]

Let's get this back to a few objective points:

 

- Please have a look at John Swenson's tutorial regarding external clocking and the way noise affects zero-crossing time and thus jitter: https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_Clock_Considerations.pdf?v=1616799482

 

- Along the same lines, please have a look at Figure 1 in this white paper by the developer of the Audirvana player software, referencing Hawksford and Dunn and Meitner and Gendron from the dawn of the digital age, again illustrating how noise changes zero crossing times and thus jitter: http://www.hifi.ir/wp-content/uploads/2016/07/MAC-OSX-audio-players-Integer-Mode.pdf

 

- The tuning of @PeterSt's software that Mani identified correctly 9 out of 10 times was to how the player "chunks" the music file out of memory.

 

- Below is a quote from a conversation between John Swenson and Gordon Rankin at Computer Audio Asylum years ago.  Apologies for the length, but it's directly on point here, talking about how memory handling in player software affects noise in the DAC. So we've got a blind test successfully passed, we've got people from the dawn of the digital era onward writing about the mechanism, now why shouldn't running the signal directly to an ADC show this very clearly?  Think about the specs you want in test or measurement equipment relative to the item being tested.  A rule of thumb is that you would like the measurement equipment to have specs about 10x better than the device under test, or your measurements are quite likely to be showing the limits of the measurement equipment rather than the performance of the device under test.  That essentially means you'd need the world's best ADC to perform the measurements we're talking about accurately on a very good DAC.  Now it does seem quite counterintuitive that the human ear should be able to hear in a room what an ADC won't show on a scope, but Mani did get 9 out of 10 correct, right?  OK, without further ado, the quote:

 

Not all programs that read files and send bits to a DAC do it exactly the same way. Some may have several buffers the data goes throuigh on it's path, some may only have one or two. Some may be built using a "layered" hierachical approach with different software "modules" that call each other, where others may be fairly "flat" with just one routine that does all the processing.

 

 

The exact sequence of instructions and memory accesses is guaranteed to be different between the programs. Since it is these instructions and memory accesses that cause the ground plane noise, I hope you can see that differences in how a task is done can produce different noise.

 

 

And BTW this CAN be measured. I've built a little ground noise analyzer that can easily see the difference in the noise from different programs doing supposedly the same thing.

 

 

Now for a concrete example. Let's take a simple program that is just copying audio data from a file to a buffer and then to an simple output port. It has two threads, one reading the file and putting the data in the buffer, and one taking data out of the buffer and putting it on the out port using an external clock to time the operation. The first thread waits until the buffer is empty then fills it up and goes back to sleep. (in reality there would be two buffers used in a ping pong arrangement, but that is irrelevant to the issue at hand).

 

 

So lets take this program and make two copies, one which has a small buffer and one which has a large buffer. The total amount of processing is exactly the same, the code is exactly the same, but is the ground plane noise the same? NO!

 

 

In the case of the small buffer the first thread spends a fairly short period of time waiting since the buffer empties out quickly. It spends a small amount of work often. With the large buffer each time it wakes up it has to handle a lot more data, but it waits a much longer time between sessions.

 

 

So why does this matter? If you look at the "work performed by the thread" over time the large buffer version shows a very "bursty" activity, but the small buffer shows a much more uniform activity. If you look at this in the frequency domain the small buffer version is dominated by relatively low intensity at high frequencies, mostly above the human hearing range. But when you look at the large buffer version you see higher intensity at much lower frequencies that are right smack dab in the middle of the human hearing range. This latter noise is going to have a much bigger affect on audibility.

 

 

And note this was exactly the same code, just different buffer sizes. Think what can happen when you are comparing different programs that use very different program architectures.

 

[John Dyson]

18 minutes ago, Jud said:

Let's get this back to a few objective points:

 

- Please have a look at John Swenson's tutorial regarding external clocking and the way noise affects zero-crossing time and thus jitter: https://cdn.shopify.com/s/files/1/0660/6121/files/UpTone-J.Swenson_Clock_Considerations.pdf?v=1616799482

 

- Along the same lines, please have a look at Figure 1 in this white paper by the developer of the Audirvana player software, referencing Hawksford and Dunn and Meitner and Gendron from the dawn of the digital age, again illustrating how noise changes zero crossing times and thus jitter: http://www.hifi.ir/wp-content/uploads/2016/07/MAC-OSX-audio-players-Integer-Mode.pdf

 

- The tuning of @PeterSt's software that Mani identified correctly 9 out of 10 times was to how the player "chunks" the music file out of memory.

 

- Below is a quote from a conversation between John Swenson and Gordon Rankin at Computer Audio Asylum years ago.  Apologies for the length, but it's directly on point here, talking about how memory handling in player software affects noise in the DAC. So we've got a blind test successfully passed, we've got people from the dawn of the digital era onward writing about the mechanism, now why shouldn't running the signal directly to an ADC show this very clearly?  Think about the specs you want in test or measurement equipment relative to the item being tested.  A rule of thumb is that you would like the measurement equipment to have specs about 10x better than the device under test, or your measurements are quite likely to be showing the limits of the measurement equipment rather than the performance of the device under test.  That essentially means you'd need the world's best ADC to perform the measurements we're talking about accurately on a very good DAC.  Now it does seem quite counterintuitive that the human ear should be able to hear in a room what an ADC won't show on a scope, but Mani did get 9 out of 10 correct, right?  OK, without further ado, the quote:

 

Not all programs that read files and send bits to a DAC do it exactly the same way. Some may have several buffers the data goes throuigh on it's path, some may only have one or two. Some may be built using a "layered" hierachical approach with different software "modules" that call each other, where others may be fairly "flat" with just one routine that does all the processing.

 

 

The exact sequence of instructions and memory accesses is guaranteed to be different between the programs. Since it is these instructions and memory accesses that cause the ground plane noise, I hope you can see that differences in how a task is done can produce different noise.

 

 

And BTW this CAN be measured. I've built a little ground noise analyzer that can easily see the difference in the noise from different programs doing supposedly the same thing.

 

 

Now for a concrete example. Let's take a simple program that is just copying audio data from a file to a buffer and then to an simple output port. It has two threads, one reading the file and putting the data in the buffer, and one taking data out of the buffer and putting it on the out port using an external clock to time the operation. The first thread waits until the buffer is empty then fills it up and goes back to sleep. (in reality there would be two buffers used in a ping pong arrangement, but that is irrelevant to the issue at hand).

 

 

So lets take this program and make two copies, one which has a small buffer and one which has a large buffer. The total amount of processing is exactly the same, the code is exactly the same, but is the ground plane noise the same? NO!

 

 

In the case of the small buffer the first thread spends a fairly short period of time waiting since the buffer empties out quickly. It spends a small amount of work often. With the large buffer each time it wakes up it has to handle a lot more data, but it waits a much longer time between sessions.

 

 

So why does this matter? If you look at the "work performed by the thread" over time the large buffer version shows a very "bursty" activity, but the small buffer shows a much more uniform activity. If you look at this in the frequency domain the small buffer version is dominated by relatively low intensity at high frequencies, mostly above the human hearing range. But when you look at the large buffer version you see higher intensity at much lower frequencies that are right smack dab in the middle of the human hearing range. This latter noise is going to have a much bigger affect on audibility.

 

 

And note this was exactly the same code, just different buffer sizes. Think what can happen when you are comparing different programs that use very different program architectures.

 

It appears that what you wrote is 100% correct.  I do get worried about 'quoting out of context', where the situation would be expanded to an environment where there is no D/A or A/D to create the actual analog sensitivity to the noise.   The only effect of digital sensitivity to the noise manifests when the noise is so extreme so that an error would occur.

(Other analog circuitry could also be affected by the noise, but I believe that focusing on the A/D and D/A would find most of the problem.)   There is the possibility of especially vulnerable circuit designs -- and they DO exist -- esp with BJT circuits, but I don't think that is often a major cause.

 

The 'bursty' thing is exactly the situation (or something similar) that allowed me to agree with the possible audible difference between .wav files and .flac files, and it is NOT the format by itself.  It is all about the effect of the software, computer electronics, noise of all kinds (mostly ground noise) that can cause audible differences.

 

I believe that people should read EXACTLY what you wrote, and not do very much extrapolation without truly understanding what is being said.