Does a file with jitter keep the jitter when saved to a hard drive?

[BlueFox]

Thanks for the replies. What I am ultimately trying to determine is why some people hear a difference between Ethernet cables. On one hand it is easy to see how an Ethernet cable can attenuate a waveform representing the data so that the receiver circuitry creates timing errors in reconstructing the bits. In this case, it is easy to grasp how an Ethernet cable can affect digital audio.

The problem is some people claim jitter is removed at every step along the way, whether the data is written to a hard drive, or buffered before being played. However, this site implies that buffers can add jitter, not remove it.

“The digital audio data must make its way through the system over wires/traces and sometimes through buffers, such as the buffer to drive the S/PDIF cable. Each of these buffers has finite reaction times and imprecise detection of changing signal levels. What this means is that even though the signal may not have much jitter coming into the buffer, it may exit with additional jitter.”

http://www.positive-feedback.com/Issue43/jitter.htm

I doubt if the people reporting a difference in audio quality between Ethernet cables are hallucinating that experience. So, I am trying to get at least a hypothetical reason as to how there could possibly be a difference.

At this point, this issue does not affect me since I use a Bryston BDP-1 file player with a direct attached USB drive, although I guess the little 6” cable that comes with the drive could also have issues. If I do eventually migrate to a NAS system I want to make sure I have the issues relating to the Ethernet cables well understood.

 

[mep]

If you have already made up your mind you know the answer, why ask?

Coming from DonH who is the mild mannered reporter from the Daily Planet, this should be considered as an ass chewing.

 

[Ken Newton]

...What I am ultimately trying to determine is why some people hear a difference between Ethernet cables...I doubt if the people reporting a difference in audio quality between Ethernet cables are hallucinating that experience. So, I am trying to get at least a hypothetical reason as to how there could possibly be a difference...

In can readily think of only one reason, which is differences in jitter introduction. However, there are a number of possible causes for that jitter introduction. Among which are, imperfect interface impedance matching, insufficient interface bandwidth, common-mode noise currents circulating across the interface, and RFI/EMI intrusion. Keep in mind that jitter doesn't manifest as a simple phenomena captured by an picosecond metric, it manifests as a modulation in time with a complex spectral profile. Much like amplifier distortion is much more complex phenomena than is captured by a simple THD% metric.

 

[DonH50]

There are two things you could check.

The easy thing is to take a file and make a copy through an Ethernet cable. See if the files are identical at the bit level using one of the bit-compare programs around (I don't have a suggestion, in my work we use custom scripts). If the files are identical then there is no change to the data with the cable. Repeat with other cables.

The next step would be to look at the jitter and see if it changes with the cable. I can pretty much say it will if you have enough measurement bandwidth and resolution, but I don't know how that might affect the audible output from a DAC. For that to happen, the clock recovered from the cable must be applied to the DAC's clock. Since the clocks are not directly compatible, there has to be some sort of buffering/PLL in the path, so now you have to decide (if the clock gets to the DAC from the Ethernet cable) how different cables affect the clock into the DAC. That sounds like a lot of work requiring a lot of test equipment.

Note that things other than jitter impact cables, and usually with far greater impact. Insertion loss, return loss (loss and matching), connector discontinuities, etc. all are likely to have a far greater impact on the signal than jitter and could explain differences among cables. Still depends upon either (a) bit errors or (b) clock recovery and signal processing sensitive to cables.

Have there been DBT's to verify people are hearing differences among Ethernet cables? I don't know, just seems like something that should be asked. I remember green pens and CDs was all the rage for a while then debunked; I am sure some people still swear by it.

 

[Orb]

Maybe the discussion needs to differentiate between correlated and uncorrelated jitter AND the source-environment/products->file setup.
Some may be coming from different POV/assumptions with regards how it is streamed-saved and the environment/system used; which can have implications on either uncorrelated or correlated (maybe pertinent to this discussion *shrug*) jitter.
Anyway in nearly every scenario I am with Don/Amir and what others say.

Any test setup needs to bypass data transmission check-correction (context such as UDP vs TCP) as this does not exist for any audio streaming protocols (including SPDIF/AES-EBU/etc).

Cheers
Orb

 

[microstrip]

Orb,

May be the discussion should address how Ethernet is being used and implemented in audio systems. We are mixing contributions from several different media, ignoring the basic aspects.

As far as I know bit error is not an issue in any modern quality audio system.

 

[Bruce B]

There are two things you could check.

The easy thing is to take a file and make a copy through an Ethernet cable. See if the files are identical at the bit level using one of the bit-compare programs around (I don't have a suggestion, in my work we use custom scripts). If the files are identical then there is no change to the data with the cable. Repeat with other cables.

I've done this dozens of times are there are no differences.

 

[BlueFox]

I've done this dozens of times are there are no differences.

Yes. That is why the hypothesis of jitter being added is making sense as a possible reason why different Ethernet cables can sound different. Of course, copying files is not the same as sending music from a NAS to the file player.

 

[DonH50]

I've done this dozens of times are there are no differences.

Can't say I am surprised, but do different Ethernet cables sound different to you?

 

[DonH50]

Yes. That is why the hypothesis of jitter being added is making sense as a possible reason why different Ethernet cables can sound different. Of course, copying files is not the same as sending music from a NAS to the file player.

It depends upon how Ethernet cables impact the DAC's clock (if they do, I'd be surprised but it is implementation-dependent). For file transfers, the only significant difference is latency.

 

[Orb]

I've done this dozens of times are there are no differences.

Just to add.
Copying a file has data transmission checking/error correction with retransmission and correct packet asembly-etc, unlike streaming.
That would be like using TCP that does have connection orientated transmission so data is guaranteed, streaming audio is more like UDP that is connectionless and no guarantee or error correction mechanism (SPDIF and AES-EBU fits more into the UDP frame in this context as transmitted data has no retransmission/reclocking/etc mechanism).

I am not suggesting this means streaming is really unreliable, but worth knowing that it is not worth comparing file copying to playing/streaming whether push or pull music file.
Some scenarios you can have the copy being made from the stream or rip rather than file copy (which should always be perfect for all transmission media types) of music file .
Rips are not always perfect, hence DBPoweramp database checksum checker for music tracks-albums.

Cheers
Orb

 

[Orb]

Orb,

May be the discussion should address how Ethernet is being used and implemented in audio systems. We are mixing contributions from several different media, ignoring the basic aspects.

As far as I know bit error is not an issue in any modern quality audio system.

Yeah with you.
Also one could always use the J-test (square wave) as technically that is already in a data format and can be an "audio data file" wav file designed to identify both correlated (important in the context of this thread) and uncorrelated jitter anywhere in the system and one can see how this changes with mixing of components or where analysed in terms of output.
I know some already do such testing, but requires either the right analysis system-simulator-file generator or able to use Matlab and setup J-test correctly as per J. Dunn spec combined with analysing.
Is it really worth the effort
Think better off using existing tools IMO that can create and utilise bespoke J-test wav file, but that is more for interest rather than radical effects in most scenarios pertaining to this thread as already mentioned by nearly all.
Cheers
Orb

 

[Audioseduction]

The music sounds fine to me!

 

[amirm]

Let's parse this into a set of points.

1. Let's assume for the sake of discussion, there are differences between Ethernet cables, files on different media, etc. when playing music. Again, this is an assumption.

2. Digital audio has only two elements to it that determine the output data: digital samples and timing.

3. No one who agrees with #1, has shown that digital data is changed (assuming the system is not broken). Further, we can demonstrate as has been explained that corruption of data simply does not happen. If it did, then your programs would degrade and crash far more catastrophically than music. Note that when this is used as a reason to invalidate #1, it is not a proper argument. See #4/#5 below.

4. If there are audible differences, they must be either dependent on timing being communicated to a DAC being different, or noise being transmitted from the PC to the DAC. These factors cannot be ruled out like the digital samples.

5. Different cables, files on different media, and even the same file copied to another place *in theory* and at a microscopic level can lead to issues in #4. So this cannot be ruled out. It certainly can't be ruled out with the argument that digital data is not changed because that is not the sum total of what modifies the analog output of the DAC.

6. People are searching for why the sound is different to them. Based on above there are two possibilities:
6(a). They are imagining it. Yes, they can . I suspect vast majority of the observations here are due to that. Maybe all of it.

6(b). The difference is there but they are forming the wrong hypothesis of the digital data gathering jitter while it remains "at rest" (stored digital data). This is what we are dealing with in this thread. There is no foundation for this. Remember that this is not a "closed minded" answer. See that I assumed it is a given that there can be a difference. Even if it is provably there, it is not due to the theories put forward. We *do* understand this about digital audio. We absolutely do because we have a more mission critical task of preserving digital data in our computers.

 

[Bruce B]

Just to add.
Copying a file has data transmission checking/error correction with retransmission and correct packet asembly-etc, unlike streaming.
That would be like using TCP that does have connection orientated transmission so data is guaranteed, streaming audio is more like UDP that is connectionless and no guarantee or error correction mechanism (SPDIF and AES-EBU fits more into the UDP frame in this context as transmitted data has no retransmission/reclocking/etc mechanism).

The Merging Horus uses Ethernet to pass an audio signal back and forth.

 

[Orb]

The Merging Horus uses Ethernet to pass an audio signal back and forth.

Ah interesting, depends how they implement it.
Cheers
Orb

 

[Bruce B]

Ah interesting, depends how they implement it.
Cheers
Orb

Ravenna

 

[Orb]

Let's parse this into a set of points.

1. Let's assume for the sake of discussion, there are differences between Ethernet cables, files on different media, etc. when playing music. Again, this is an assumption.

2. Digital audio has only two elements to it that determine the output data: digital samples and timing.

3. No one who agrees with #1, has shown that digital data is changed (assuming the system is not broken). Further, we can demonstrate as has been explained that corruption of data simply does not happen. If it did, then your programs would degrade and crash far more catastrophically than music. Note that when this is used as a reason to invalidate #1, it is not a proper argument. See #4/#5 below.

4. If there are audible differences, they must be either dependent on timing being communicated to a DAC being different, or noise being transmitted from the PC to the DAC. These factors cannot be ruled out like the digital samples.

5. Different cables, files on different media, and even the same file copied to another place *in theory* and at a microscopic level can lead to issues in #4. So this cannot be ruled out. It certainly can't be ruled out with the argument that digital data is not changed because that is not the sum total of what modifies the analog output of the DAC.

6. People are searching for why the sound is different to them. Based on above there are two possibilities:
6(a). They are imagining it. Yes, they can . I suspect vast majority of the observations here are due to that. Maybe all of it.

6(b). The difference is there but they are forming the wrong hypothesis of the digital data gathering jitter while it remains "at rest" (stored digital data). This is what we are dealing with in this thread. There is no foundation for this. Remember that this is not a "closed minded" answer. See that I assumed it is a given that there can be a difference. Even if it is provably there, it is not due to the theories put forward. We *do* understand this about digital audio. We absolutely do because we have a more mission critical task of preserving digital data in our computers.

Amir, problem with point 3 is that it does not differentiate between UDP and TCP, in streaming UDP will be the carrier for the music data while TCP is used by the application-server/application management, so the programs will never crash but audio data is still not guaranteed, although one is more likely to hear a glitch than any other issue.
Just to add most programs relying upon program type data nearly always use TCP or something similar, again to stop any possible crashes as you rightly point out.
But they do handle streaming differently (which is a combination of both TCP and UDP).

Comes down to the scenario being used, but Ethernet is designed that error correction-retransmission is handled by higher level protocols and/or application.
That said TBH I have problems thinking how ethernet cables can change the sound (probably like you) if they are good quality network types; more likely comes down to devices-components-software/firmware IF any differences happen rather than ethernet cable.
Only way I feel can truly test is to use J-test WAV file and analyse the analogue out; although requires a baseline with ability to identify correlated jitter while ignoring uncorrelated and use various components in the chain to see if it changes.
But then this is a streaming (applicable to both push and pull) type scenario, rather than a normal copy setup.

Just my thoughts on it, but not an issue I am going to lose sleep over as there are higher priorities for getting the best out of audio IMO
Cheers
Orb

 

[BlueFox]

.6(b). The difference is there but they are forming the wrong hypothesis of the digital data gathering jitter while it remains "at rest" (stored digital data). This is what we are dealing with in this thread.

Actually, that is not correct. I started the thread to clarify a question that occurred to me as to whether it was possible if jitter in data could be saved along with the data. I was reasonably sure the answer was no, but wanted some clarification and validation. It is my fault I then sidetracked the thread with the Ethernet question.

However, the HD question occurred to me in another discussion regarding whether or not different Ethernet cables can affect sound quality. My initial thought is no, but there is anecdotal data that it does, and AudioQuest and others are selling 'better' Ethernet cables for this issue.

All I am trying to do is come up with some possible scenarios or reasons where this is technically possible, even if unlikely. Since an Ethernet cable, like any other cable, will attenuate the signal, or be subject to interference from outside sources, it certainly seems reasonable that the signal can be degraded enough to result in the receiver circuitry adding jitter as the musical data is reconstructed. The question is can this jitter make it to the DAC, or will it be eliminated as it travels through the rest of the circuit.

My assumption is, it depends. It depends on the topology used, and the ancillary equipment.

I doubt if people are imagining it. That is the argument used by cable deniers for every other cable. It wasn't true then, and I suspect it will not be true in this case, or at least in some implementations.

 

[Ken Newton]

Ravenna

Bruce, I'm not familiar with the RAVENNA spec., having only read the Wiki page you linked. Do you know whether the spec. contains special provisions to minimize jitter, ideally, by enabling the receiving end to direct packet flow control? I wonder because, at first glance, the spec. appears intended for handling streaming media over IP, and so, may only address limiting the latency of network packet forwarding. Limiting packet latency, of course, doesn't necessarily mean minimizing jitter.