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

[Orb]

Let's hope they do come.

For now, an easier way to show the problem does not exist is to use the binary comparison tool "comp" in Windows. You run it from a command prompt. It will perform a bit for bit comparison. Audio files copied will always pass such a test so there can't be any argument of noise getting injected into the target file.

Hmm,
although Amir I remember quite a long time ago Daniel Weiss did the same bit test involving one of his DACs (created bespoke data file to bit test with his DAC) before ethernet so had to be something like firewire/USB/etc and it came out.... bit perfect.

Now I am not saying it would necessarily prove sound difference exists, but the ideal test is the J-test WAV file (or equivalent) that is either pushed or pulled and analysed at the analogue output.
I appreciate this brings the argument of defining the baseline as part of any correlated or uncorrelated jitter is created by the DAC/media server, and furthermore requires a comparison between many products or setups/intermediate components.
The added complexity is identifying specific deterministic-data dependent jitter.
Just to add I am very leery and cynical about expensive "bespoke" audio ethernet cables myself as I have been pretty much heavily involved in time sensitive audio/video solutions and products in the past myself like you.
Cheers
Orb

 

[Habanero Monk]

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.

Actually the process is the same: Data is fetched by a request and data is stored, STATICALLY, in a buffer.

The difference being one of volatility: Is the static data volatile or non-volatile. IE will it survive a power cycle and what IS the buffer? Some form of RAM or disk?

 

[Habanero Monk]

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.

Ugh. Anecdotal data has zero value.

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.

Jitter isn't 'added'. The file as transmitted over Ethernet will have multiple checks (CRC32 for the chance of 1 in 4 billion undetected error), TCP re-try etc...

The Jitter on the Ethernet wire is eliminated once the data is in the data buffer and being read back out. The time that jitter becomes an issue is when the protocol goes REAL TIME. Whether that is USB or S/PDIF.

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

So are you postulating that a file from HD Tracks transferred over a $90 Cisco Switch (SG 200-8) and a $58,000 Cisco Switch (6509) will sound different even if the are bit identical?

I doubt if people are imagining it.

I don't.

Amir makes a point about the cables radiated RFI making it back into the system. As I mentioned elsewhere it's a subject that should really be explored but somehow I'm a troll for wanting to go there.

TI's paper made an point about the power supplies being single ended in a lot of network environments. It goes along with just properly designing network systems from the get go. I have a suspicion that IF an Ethernet cable changes the sound it's glossing over some other root problem that should be addressed in a better manner. IE it's actually NOT the cable. The cable is just exposing a greater issue that needs to be sussed out.

 

[amirm]

Hmm,
although Amir I remember quite a long time ago Daniel Weiss did the same bit test involving one of his DACs (created bespoke data file to bit test with his DAC) before ethernet so had to be something like firewire/USB/etc and it came out.... bit perfect.

Now I am not saying it would necessarily prove sound difference exists, but the ideal test is the J-test WAV file (or equivalent) that is either pushed or pulled and analysed at the analogue output.

That's a different argument. The one here says that when we copy a file on the hard disk, it ends up different. That assertion does not include a DAC or analog output of the same.

 

[Orb]

That's a different argument. The one here says that when we copy a file on the hard disk, it ends up different. That assertion does not include a DAC or analog output of the same.

Ah sorry,
yeah if we are talking about copying no disagreement from me; this as I mentioned a bit earlier usually uses SMB/CIFS or something comparable and should be impossible for data bits not to match.

Cheers
Orb

 

[BlueFox]

That's a different argument. The one here says that when we copy a file on the hard disk, it ends up different.

I haven't noticed anyone making that argument in this thread. Asking a question to find out if it possible is not making an argument that it does.

 

[Habanero Monk]

correlated or uncorrelated jitter is created by the DAC/media server, and furthermore requires a comparison between many products or setups/intermediate components.
The added complexity is identifying specific deterministic-data dependent jitter.
Orb

I believe the difference is in the realtime vs non-realtime nature. When it comes to a computer or even a packet buffered media server the DAC needs to be treated separately since the Ethernet data packet rate just is magnitudes greater in speed than the S/PDIF / USB / FireWire that it has to be metered out on.

If using a computer streamer the intermediate data interconnects have no bearing since it is hurry up and wait (unless they are too slow). The data is sent in bursts. That is if this is what you where referring to in regards to intermediate components. Let me know if I am misunderstanding in the context I presented.

 

[Orb]

It is a bit more complicated unfortunately and comes down to whether data can be guaranteed/error correction/retransmission, but yes a primary consideration is streaming (real-time time sensitive includes VOIP/vid conferencing/media streaming for both video and audio/etc) vs non-streaming (includes file copying/file transfer/web browsing file transfer-downloadetc).
This has to take into consideration the pysical layer, network protocol and critically session/application control that for non-streaming sessions can have advanced with high level data integrity-redundancy-correction/retransmit.

As an example say you setup server-media player system:
The music files you download and put onto the NAS will be bit perfect and without jitter, because this is using something like SMB/CIFS for ensuring the data is transferred and data integrity guaranteed (session and application-to-application).
Now those files when played (whether pushed or pulled) has the potential to suffer bit errors/jitter/etc as the session-application control is only for aspects not pertaining to the actual music data streamed.
Playing the music file uses multiple sessions combining both TCP and UDP (look back and I touched a bit on this) with UDP used for the real music data that is time-latency sensitive.

As a real world example using wireless with poor strength-signal quality.
You will still be able to transfer the file, if problems happen it will either retransmit or possibly require the operation to start again but is pretty painless.
But when it comes to playing the music over the wireless network then it is possible one can hear glitches and worst case scenario a total breakdown of session-application between the server (whether NAS or laptop) and the end device player-dac that may require a reboot of said end device or refresh of application management.
This actually has happened for some users with various solutions/hardware.

Before anyone responds please appreciate this is a very basic-crude description.
Anyway Habanero the consideration is streaming time-latency sensitive data, physical network-transmission considerations such as Ethernet-WLAN-USB-etc, network protocols used (will usually be several simultaneously), wether it is possible to support higher level data integrity-error correction from session and application (this potentially can involve multiple sessions between multiple devices such as ipad controller-NAS server-end device player/DAC) such as offered by SMB/CIFS (file management-sharing) and their equivalents.

So yes it is possible for jitter/latency/bit errors even over a network including Ethernet BUT this is really only relevant to when the music is being played (which would involve streaming).
Setting up/transferring/copying files on a NAS or laptop will always be bit perfect with no issues pertaining to jitter-latency-etc due to data integrity guaranteed and also the operation is not real-time time sensitive streamed.
Now ripping CDs is not necessarily bit perfect but this is something else and beyond I think what the purpose of this thread was about.
Cheers
Orb

 

[Habanero Monk]

In context of a correctly setup network and I would say safe to assume no gross error is jitter actually part of the successfully transmitted file.

I've routinely now on my GBe network been copying over a 2.5GB 24/192 album between my server and my client machine and doing it in ~30 seconds as a test. I haven't had a failure as of yet and my MD5 hash has stayed the same.

Now even when listening to audio I literally pull the plug and still listen, plug back in etc and finish a song with no drop out or other error. While the music is real time the data obviously isn't. So is there any scenario where Jitter in the packet stream on the Ethernet side going to introduce into the S/PDIF or USB protocol?

 

[Orb]

As I said you will NOT have issues with file transfer/copying or its equivalent because all data integrity is handled at both session and application providing guaranteed data
Technically sessions may fail and re-initiate without you even knowing in this instance, data may also need retransmitting, may have a delay of X seconds due to session response,etc and again would not know about it - you need some way to analyse it to see this happening.
A complete file transfer retry or continue can happen with serious network/session faults or errors that you would be aware of, but it is still painless as the data integrity will still be 100%, well it should be

BUT, the above is not how it is handled for actually playing the music, whether it be laptop or NAS to the end device player-DAC over Ethernet.
Cheers
Orb

 

[Habanero Monk]

Agreed. Me pulling the Ethernet cable is certainly introducing a huge error And it's an error that can indeed never be experienced on the S/PDIF/USB DAC side of things.