Does high quality digital cables matter?
Comments
-
DarqueKnight wrote: »
However, due to noise contamination, there are now three different versions of the pulse sequence. Consider that, in a typical stereo music file, you will be dealing with millions of bits, therefore, the grossly simplified cases represented by A, B, and C translate to three files with multiple millions of differences between them.
This is completely wrong. The transport mechanism is not the same as the data being carried by that mechanism. That electrical pulse sequence does not alter the bits being transmitted. You're implying that 00000001 somehow can become 00000011 in the transport process. If this were the case then we would all see a different version of polkaudio.com every time we visited.
You're statement about analog conversion is irrelevant in this thread because it's topic was about digital cables which are a part of the transport process, not encoding or decoding.
The engineering and science behind the digital realm ensures that the bits and bytes transmitted are the same on the receiving end. If they are not then there are CLEAR and OBVIOUS problems. In the audio world that would be chirps, skips, etc. Digital error detection and correction prevent that unless there is a serious flaw in the transport process.
Everyone is allowed their own perception. If someone does or doesn't hear a difference between digital cables, cool. That's their perception and nobody can argue with or disprove that. It's impossible, so just stop trying and let people enjoy their own experience. Jeeze. -
DarqueKnight wrote: »No, but a file on a hard drive can contain noise.
No, it can contain data. You will have to expound on the 'contain noise'. It's too broad for interpretation.DarqueKnight wrote: »It's not quite that simple. "Ones" and "zeroes" are not being transmitted. Voltage pulses that correspond to logical high ("1") and logical low ("0") are being transmitted. The high and low voltage pulses have nominal values, for example low may be 2 V and high may be 12 V. In reality, high and low correspond to a range of values: low may be any value from 0-5 V and high may be any value 10-15 V.
Consider the sequence 1-0-0-1-1-0-1-1-0-1-1-1: Ideally this would be represented by the following pulse amplitudes according to the scheme given above:
12-2-2-12-12-2-12-12-2-12-12-12
A noise-affected version of the sequence is:
10-0-1-11-11-3-12-14-1-15-10-11
You have to show this in usage however. This could manifest as packet loss. This could manifest as no packet loss but malformed packet (which various protocols would most likely re-transmit) and re-order for correctness.
Also your optimal would be 15-0-0-15-15-0-15-15-0-15-15-15
Your "noisy versions" would be
12-2-2-12-12-2-12-12-2-12-12-12
10-0-1-11-11-3-12-14-1-15-10-11DarqueKnight wrote: »
Here, the demarcation between logical high and logical low is preserved, but the signal looks a lot different than the ideal case.
What happens when a more seriously noise-affected version occurs?:
14.79-4.38-1.13-9.9-13.8-0.3-11.5-0.45-11.5-13.88-10.65
Here, the demarcation between logical high and logical low is preserved, but the signal now approaches the amplitude characteristics of random noise.
Each of these voltage pulse sequences are within spec with regard to amplitude:
A. 12-2-2-12-12-2-12-12-2-12-12-12
B. 10-0-1-11-11-3-12-14-1-15-10-11
C. 14.79-4.38-1.13-9.9-13.8-0.3-11.5-0.45-11.5-13.88-10.65
While the mechanics are certainly sound, the differences, if they are in the signaling thresh hold, are inconsequential. You have a PHY that is designed to either accept 1-5 or 10-15 and ignore everything else. It's not random noise to the transceiver. It's delta has either been hit or missed. 9.9 isn't a near miss, it's a miss and data will be requested again.DarqueKnight wrote: »However, due to noise contamination, there are now three different versions of the pulse sequence. Consider that, in a typical stereo music file, you will be dealing with millions of bits, therefore, the grossly simplified cases represented by A, B, and C translate to three files with multiple millions of differences between them.
Questions:
1. Will all three files require the same processing effort?
2. When the D/A conversion is done, is one file going to be more prone to error than the others, or will they all convert to identical analog files?
That would be a question for someone that develops silicon for NIC's. Now lets say that if the Amplitude voltages are sent with some variance, but they are within the delta of the PHY and they come out to the exact same binary stored in buffer with some timing variance as they were transmitted on the line:
We can say that they are indeed the same exact file
We can say that the timing variance, that the difference in amplitude response, is non-sequiter at this point. The buffer is filled with exact data that took milliseconds or less to fill for seconds or 10's of seconds for playback.DarqueKnight wrote: »Consider another case of the sequence contaminated by electric fast transient noise, so that the following sequence results:
16.79-4.38-5.13-9.9-15.8-6.3-11.5-0.45-11.5-10.88-15.65
The values in red are outside the ranges for high and low. What happens in this case?
That is protocol dependent. TCP would resend, SMB/CIFS would re-request. UDP you are screwed.
I doubt that a $350 AQ Vodka cable would do any better at insuring amplitude response characteristics than my $13 certified BJC cable as long as I'm not on the USS Nimitz or running my Ethernet cable zip tied to my 12/2 20 amp service that is servicing my listening setup I'll take my chances.DarqueKnight wrote: »My example showed that multiple versions of the same file can result due to noise contamination. They were not perfect 1:1 bit copies, although each file maintained the proper relationship between logical high and logical low.
In your example the amplitude response may not be identical. But the transceiver that gets the stream will code out the same binary file regardless.
I'm sure there is some V drop at the 328 foot of cable vs 3 foot. So the spec is most likely designed to work at the extreme and do so reliably.DarqueKnight wrote: »If there is a high degree of amplitude randomness in a digital signal, why wouldn't this affect processing efficiency, especially with regard to digital to analog conversion? If the randomness affects processing efficiency, why wouldn't this translate to audible differences?
Because it doesn't have to be a hard 15 or 0. It's not randomness to the transceiver. It's either 1/0 or trash and let the higher layer protocols whether network, application, session etc work it out.
That is why at least getting a cable that is certified has merit. -
I don't know about others, but I try to get information about a subject from a variety of sources. For example, jitter is a relatively common topic on audio forums. Here is an excellent post, and with good timing (ha ha) for this thread. Monk, I hope your write-up reaches this level of detail.
First paragraph:
"One of the common arguments made against jitter mattering is that: "the data is buffered and clock regenerated in the DAC so jitter won't be there." This makes all the sense in the world. Once we capture the data and then push it out at our will, there shouldn't be a problem. Well, there is a problem. A serious one. Buffering and clock regeneration do not deal with jitter by themselves. I have explained this in words many times but this time I am bringing in some specific data to hopefully put this myth to bed (yeh, wishful thinking )."
http://www.whatsbestforum.com/showthread.php?14957-Yet-another-look-at-Jitter-Clock-Extraction&p=270683&viewfull=1#post270683
Did you bother to try comprehending the fact that Amir is speaking about the bitstream to the DAC and the buffer on the DAC?
He's not speaking to, nor can he speak to, if the file was read from local or remote storage.
Go ahead and ask him if his measurements of the bitstream can let him intrinsically determine if the data is derived from over at network cable or traditional HD. -
This is completely wrong. The transport mechanism is not the same as the data being carried by that mechanism. That electrical pulse sequence does not alter the bits being transmitted. You're implying that 00000001 somehow can become 00000011 in the transport process. If this were the case then we would all see a different version of polkaudio.com every time we visited.
All you have done is reveal your deficiencies in reading comprehension. My example had nothing to do with bits being changed from high to low or vice versa.You're statement about analog conversion is irrelevant in this thread because it's topic was about digital cables which are a part of the transport process, not encoding or decoding.
Again, reading is fundamental.The engineering and science behind the digital realm ensures that the bits and bytes transmitted are the same on the receiving end. If they are not then there are CLEAR and OBVIOUS problems. In the audio world that would be chirps, skips, etc. Digital error detection and correction prevent that unless there is a serious flaw in the transport process.
Again, reading is fundamental.Everyone is allowed their own perception. If someone does or doesn't hear a difference between digital cables, cool. That's their perception and nobody can argue with or disprove that. It's impossible, so just stop trying and let people enjoy their own experience. Jeeze.
You should be preaching this to Habanero Monk. He is the one taking issue with people claiming that they hear differences in Ethernet cables. He is the one challenging people to prove to him that they can hear differences in Ethernet cables.Habanero Monk wrote: »When you take the dubious step of saying it does X/Y/Z to the sound vs another competent CAT6 cable then I have to take issue since I understand how packet switched networks operate.Habanero Monk wrote: »My position is that it's not possible. I have actively put this out there at some other forums. A position that I would like to find a way to actively exploit people and the money they like to seemingly be fleeced of.
Because if they think there is a night and day difference between two Ethernet cables that pass spec and are willing to pay hundreds of dollars. Well it's immoral to let a sucker keep his or her money.Habanero Monk wrote: »All you need to know is there are some chumps here that are all talk. All bark no bite.
As a matter of fact I offered, while at the PETT GTG in Dayton, last summer to put together a computer with dual Radeon cards (that max out the HQV Blu-Ray benchmark) all going to a high quality display (with 2 HDMI inputs).
The display would be calibrated for both inputs. A $20 Belden HDMI and any HDMI cable they wanted to bring. I offered up a ~$600 AQ.Habanero Monk wrote: »Does anyone want to bet on a certified CAT6 cable vs any AQ Ethernet cable you care to pick?Habanero Monk wrote: »It's certainly not a 'fact'. Also some are claiming differences. I'm not testing cables. I'm testing claims. Discern the difference, and then form your opinion. I'm curious how this would work.
Heck if anyone is 90 minutes or so outside of Cinci it would be neat to test on their equipment.Habanero Monk wrote: »I'm saying I'm willing to bet you the cost of a DAC you can't follow the ball under the cup routine when one Ethernet cable is used vs another.
Let me know. I can get a contract drawn up.Habanero Monk wrote: »You said you can discern differences in Ethernet cables. So I'll pay you off with a $1600 DAC if you can.
You either can or you can not. Based on your conviction of your position it's an easy $1600 for you. I can always send the DAC back and give you $1600.
My vested interest is in showing people, rather publicly, that in this instance you are 100% in error of your understanding about how this works in regards to computer based networked audio.
Even if you decline my offer it still proves my point about your convictions. There is no downside for me other than you hitting it 13 out of 15.
I am the one who said I think it's possible that Ethernet cables might make an audible difference, but I have never heard a difference in any coax or optical digital cable I have used.Proud and loyal citizen of the Digital Domain and Solid State Country! -
This is completely wrong. The transport mechanism is not the same as the data being carried by that mechanism. That electrical pulse sequence does not alter the bits being transmitted. You're implying that 00000001 somehow can become 00000011 in the transport process. If this were the case then we would all see a different version of polkaudio.com every time we visited.
You misunderstood what Ray is saying. The transport mechanism(s) is/are affecting the data being transmitted. Ray is not saying thay the data and transport mechanism(s) is/are the same. The electrical pulse sequence most definately does alter the bits being transmitted. This is because (as shown in Rays example) the transport mechanisms including many many things such as: capacitors, resistors, diodes, etc. as well as ethernet cables all affect the electrical impulses sent through them. What makes you think that electrical impulses (making up the data being sent, which makes up the bits you referred to) are not affected by any of the transport "mechanisms"? What makes you think that there is no affect on these electrical impulses?
Ray was not saing that 00000001 can become 000000011. You are implying that extra data was added to the bits. This is not what Ray was saying at all. Ray is saying that the electrical impulses for the data being sent were to varying degrees of accuracy based upon the amount of noise affecting the data. Not that extra data was added, but that the noise altered the data to make it less than exact, while still maintaing the correct bits being received. Do you undertsand the difference?The engineering and science behind the digital realm ensures that the bits and bytes transmitted are the same on the receiving end. If they are not then there are CLEAR and OBVIOUS problems. In the audio world that would be chirps, skips, etc. Digital error detection and correction prevent that unless there is a serious flaw in the transport process.
They may appear to be the same when you look at them on a computer screen or they are analyzed with a scientific measuring device. When something more sensitive (as in the case of your ears, brain and consciousness) are used, it becomes much more apparent that what is received is not equivalent to the orignial source (to varying degrees of course). That's I believe the problem with "digital know-it-alls" is that they cannot use their brains and get to a fine enough detail (scale) to realise that when you get to a fine enough scale, there are electrical problems that show up in digital signals. Since their brains cannot get a hold of this, they think that digital transmissions are "perfect". Again, there are no perfect transfers of electrical signals, period.
When you are referring to chirps, clicks, etc. showing up in music transmitted digitally, you are referring to extreme cases. What about the more subtle cases of error. They are perceptible, but it does not seem that "digital-know-it-alls" can detect them.Everyone is allowed their own perception. If someone does or doesn't hear a difference between digital cables, cool. That's their perception and nobody can argue with or disprove that. It's impossible, so just stop trying and let people enjoy their own experience. Jeeze.
Yes, they are aren't they. Please see my response in the paragraph above this one.
People who suggest that there are differences in ethernet and other digital cables are trying to prevent others from enjoying their own experience by any means. In fact, people promoting better (higher quality) digital cables are promoting an improved audio experience.
Taken from a recent Audioholics reply regarding "Club Polk" and Polk speakers:
"I'm yet to hear a Polk speaker that merits more than a sentence and 60 seconds discussion."![:\](https://forum.polkaudio.com/resources/emoji/confused.png ":\")
My response is: If you need 60 seconds to respond in one sentence, you probably should't be evaluating Polk speakers.....
"Green leaves reveal the heart spoken Khatru"- Jon Anderson
"Have A Little Faith! And Everything You'll Face, Will Jump From Out Right On Into Place! Yeah! Take A Little Time! And Everything You'll Find, Will Move From Gloom Right On Into Shine!"- Arthur Lee -
Sorry Ray. I just noticed that you responded before I did. Carry on..... :redface:
Taken from a recent Audioholics reply regarding "Club Polk" and Polk speakers:
"I'm yet to hear a Polk speaker that merits more than a sentence and 60 seconds discussion."
My response is: If you need 60 seconds to respond in one sentence, you probably should't be evaluating Polk speakers.....
"Green leaves reveal the heart spoken Khatru"- Jon Anderson
"Have A Little Faith! And Everything You'll Face, Will Jump From Out Right On Into Place! Yeah! Take A Little Time! And Everything You'll Find, Will Move From Gloom Right On Into Shine!"- Arthur Lee -
I don't know about others, but I try to get information about a subject from a variety of sources. For example, jitter is a relatively common topic on audio forums. Here is an excellent post, and with good timing (ha ha) for this thread. Monk, I hope your write-up reaches this level of detail.
First paragraph:
"One of the common arguments made against jitter mattering is that: "the data is buffered and clock regenerated in the DAC so jitter won't be there." This makes all the sense in the world. Once we capture the data and then push it out at our will, there shouldn't be a problem. Well, there is a problem. A serious one. Buffering and clock regeneration do not deal with jitter by themselves. I have explained this in words many times but this time I am bringing in some specific data to hopefully put this myth to bed (yeh, wishful thinking )."
http://www.whatsbestforum.com/showthread.php?14957-Yet-another-look-at-Jitter-Clock-Extraction&p=270683&viewfull=1#post270683
Since we are quoting Amir:
While his explanation of what the J-test is, his reasoning for why it is used at the end is incorrect. The file itself contains no jitter whatsoever. Nor does it simulate "subtle timing inaccuracies." Remember, a file sitting on your hard disk before being played is just a bunch of digital audio samples. it is "perfect" in that regard. We can copy it 100 times and the last copy will be identical to first. So no timing problem exists or can exist in a digital file on a computer.
The J-test signal is designed to cause more jitter on the S/PDIF link. Due to the way the clock is transmitted on that link, the J-test signal can excite them due to the way the digital values are picked in that test signals.
http://www.avsforum.com/t/1531357/jitter/0_100#post_24730005 -
Apparently Monk's reading comprehension skill level is equal to his networking knowledge, which is negligible. He has just made two posts based on a post in the WBF forum. Neither of Monk's post have anything to do with the WBF post. The WBF post is showing jitter is not eliminated when the digital signal is buffered. Rather, Monk is either intentionally trying to distract from that idea, or he just has no idea what he is reading. I suspect it is the second item since he has already shown he does not understand jitter when he even posted the link to a jitter explanation.
Interestingly, the WBF post destroys the entire premise for both Monk and Villian. If buffering does not eliminate jitter then they have no case. Therefore, case closed. Ethernet cables have the potential to affect audio sound quality.Lumin X1 file player, Westminster Labs interconnect cable
Sony XA-5400ES SACD; Pass XP-22 pre; X600.5 amps
Magico S5 MKII Mcast Rose speakers; SPOD spikes
Shunyata Triton v3/Typhon QR on source, Denali 2000 (2) on amps
Shunyata Sigma XLR analog ICs, Sigma speaker cables
Shunyata Sigma HC (2), Sigma Analog, Sigma Digital, Z Anaconda (3) power cables
Mapleshade Samson V.3 four shelf solid maple rack, Micropoint brass footers
Three 20 amp circuits. -
Apparently Monk's reading comprehension skill level is equal to his networking knowledge, which is negligible. He has just made two posts based on a post in the WBF forum. Neither of Monk's post have anything to do with the WBF post. The WBF post is showing jitter is not eliminated when the digital signal is buffered. Rather, Monk is either intentionally trying to distract from that idea, or he just has no idea what he is reading. I suspect it is the second item since he has already shown he does not understand jitter when he even posted the link to a jitter explanation.
Interestingly, the WBF post destroys the entire premise for both Monk and Villian. If buffering does not eliminate jitter then they have no case. Therefore, case closed. Ethernet cables have the potential to affect audio sound quality.
Again: Ask Amir, in that thread, if his jitter measurements would enable him to deduce of whether the data is retrieved from local HD or pulled over the network.
If you read what he is writing about in PLL recovered clock sync inputted over SP/DIF you would see he is talking about the jitter induced error of the PLL and that of the DAC buffer (not computer buffer).
If you had also read the other post of his from AVSForum:
The file itself contains no jitter whatsoever. Nor does it simulate "subtle timing inaccuracies." Remember, a file sitting on your hard disk before being played is just a bunch of digital audio samples.
The buffer on a computer is the file that contains no jitter what so ever. Also keep in mind that JRiver can pull over an entire file to RAM (up to 1 GB).
You are truly out of your depth here and the sad thing is you don't even realize it.
Also find out where I said buffering destroys Jitter in absolute terms. Go ahead now and find it. What I said is what Amir said: Remember, a file sitting on your hard disk before being played is just a bunch of digital audio samples".
Jitter will be introduced once it is read into RAM, when it is read out of RAM, when it is transferred over bus X/Y/Z. It's the READ and WRITE process that will have some form of jitter. Not the storage state. Whether it's RAM, HD, RAM DISK. -
One of the common arguments made against jitter mattering is that: "the data is buffered and clock regenerated in the DAC so jitter won't be there." This makes all the sense in the world. Once we capture the data and then push it out at our will, there shouldn't be a problem. Well, there is a problem. A serious one. Buffering and clock regeneration do not deal with jitter by themselves. I have explained this in words many times but this time I am bringing in some specific data to hopefully put this myth to bed (yeh, wishful thinking ).
Introduction
The way a clock is "regenerated" is to have a local oscillator (clock) that we can change its frequency to eventually match and track the incoming digital stream. As you may know, S/PDIF is a serial digital connection with clock and data intermixed. By using this circuit which is called a Phase Locked Loop (or PLL for short), we are able to extract a clock that is cleaner than the incoming one. This clean up allows us to capture the digital samples reliably.
I've underlined the items of import that BlueFox is having a failure to understand the ramifications of and also his conflation as to what buffer is being referred to.
The data is buffered in the DAC. The clock is regenerated in the DAC. This is also DAC specific since there are many options for syncing clock.
The data buffered on the computer is being confused with the above by BF. -
Also from the thread Blue Fox mentioned:
There are no "inaccuracies of information" - the actual data gets transferred without errors and without any change. The issue is with the clock - cheaper DACs use a clock that is generated by having a PLL lock to the incoming data clock, and that PLL is not always very good at rejecting jitter. Thus the timing of the DAC conversion can be affected, resulting in jitter-induced distortion/noise on the analog output.
I have to thank him for that linked thread. It completely makes my point that there are some that don't understand what is going on here due to failure to launch in their understanding of what is being spoken about.
If one did understand they would never have attempted it's use in fortifying their already indefensible position.
Now I'll just have to wait and see how it can be tied back into a BJC vs some other high $$ Ethernet cable. -
DarqueKnight wrote: »No, but a file on a hard drive can contain noise.
It's not quite that simple. "Ones" and "zeroes" are not being transmitted. Voltage pulses that correspond to logical high ("1") and logical low ("0") are being transmitted. The high and low voltage pulses have nominal values, for example low may be 2 V and high may be 12 V. In reality, high and low correspond to a range of values: low may be any value from 0-5 V and high may be any value 10-15 V.
Consider the sequence 1-0-0-1-1-0-1-1-0-1-1-1: Ideally this would be represented by the following pulse amplitudes according to the scheme given above:
12-2-2-12-12-2-12-12-2-12-12-12
A noise-affected version of the sequence is:
10-0-1-11-11-3-12-14-1-15-10-11
Here, the demarcation between logical high and logical low is preserved, but the signal looks a lot different than the ideal case.
What happens when a more seriously noise-affected version occurs?:
14.79-4.38-1.13-9.9-13.8-0.3-11.5-0.45-11.5-13.88-10.65
Here, the demarcation between logical high and logical low is preserved, but the signal now approaches the amplitude characteristics of random noise.
Each of these voltage pulse sequences are within spec with regard to amplitude:
A. 12-2-2-12-12-2-12-12-2-12-12-12
B. 10-0-1-11-11-3-12-14-1-15-10-11
C. 14.79-4.38-1.13-9.9-13.8-0.3-11.5-0.45-11.5-13.88-10.65
However, due to noise contamination, there are now three different versions of the pulse sequence. Consider that, in a typical stereo music file, you will be dealing with millions of bits, therefore, the grossly simplified cases represented by A, B, and C translate to three files with multiple millions of differences between them.
Questions:
1. Will all three files require the same processing effort?
2. When the D/A conversion is done, is one file going to be more prone to error than the others, or will they all convert to identical analog files?
Consider another case of the sequence contaminated by electric fast transient noise, so that the following sequence results:
16.79-4.38-5.13-9.9-15.8-6.3-11.5-0.45-11.5-10.88-15.65
The values in red are outside the ranges for high and low. What happens in this case?
My example showed that multiple versions of the same file can result due to noise contamination. They were not perfect 1:1 bit copies, although each file maintained the proper relationship between logical high and logical low.
If there is a high degree of amplitude randomness in a digital signal, why wouldn't this affect processing efficiency, especially with regard to digital to analog conversion? If the randomness affects processing efficiency, why wouldn't this translate to audible differences?
If the logical output is the same as the logical input and the result is a 1:1 bit copy, then what else matters? You should be banned for this post. No joke. You've knowingly attempted to mislead anyone reading this thread, and this post is the worst bit of semantics yet. No wonder people here are stuck in this 1960's train of thought and unable to comprehend what does and doesn't effect digital signals..
Completely disgraceful DK.Too many good quotes to list..waiting for some fresh ammo.
-
Your example above does a phenominal job of demonstrating exactly why the ideas of "digital transfer is "bit perfect"" and "It's an exact copy of the original file" are falsehoods. There are absolutely no perfect, exact copies of electical signals. there is always degredation to higher or lower degrees.
Sheeple being completely mislead. Sigh.
Wow. That's about all I can say.
DK himself just explained how there IS "Bit perfect" 1:1 digital copies, and you just dismiss that right out the window in the name of ignorance..Too many good quotes to list..waiting for some fresh ammo. -
Jitter can be present in the original recording and this can never be mitigated. It's a permanent fixture to the recording unless they make a new digital master.
Pretty sure I just said that like 5 posts ago...
Yep, still there.Jitter that is recorded during the original Analog to Digital process (At the recording studio) cannot be fixed, corrected for, or removed. If jitter exists in the playback of an audio stream (Whether it's audible or not) it's either original recording jitter or jitter that was introduced in the very last step of digital/analog conversion before analog playback via the wires going to your speakers. Given that this is the case I would take a serious look at your DAC/AVR/Amps rather than playing the cable blame game...as the DAC/AVR/Amps are the only place that jitter heard during playback of audio could possibly be introduced. Every other step of the process effectively nullifies jitter since you are moving back and forth from the Real Time domain (Where jitter exists) to a domain where jitter doesn't (As a data file or digital data packets in a storage medium). Think about it..if this wasn't true then by the time any type of audio file was delivered to you it would be nothing but jitter. Especially after traveling through thousands of miles of fiber strands (Which are notorious for introducing jitter) in the digital domain before ever reaching you. Also consider that nearly every movie theater in the country now displays moving images and sound delivered via fiber and a cloud service. That is still considered true "Reference Level"...correct?
Love how the majority commenting in this thread seem to only see what they want, and ignore what they don't want to see. Even when later posting the exact same **** that myself and Habanero say..Too many good quotes to list..waiting for some fresh ammo. -
DarqueKnight wrote: »All you have done is reveal your deficiencies in reading comprehension. My example had nothing to do with bits being changed from high to low or vice versa.
Again, reading is fundamental.
Again, reading is fundamental.
I am the one who said I think it's possible that Ethernet cables might make an audible difference, but I have never heard a difference in any coax or optical digital cable I have used.
Wow, so you're going to openly play semantics then call out the users here who misunderstand the example you threw out there (That added nor subtraced nothing) in a volatile argument like this? Talk about baiting and switching. That was low, even for you.
Why don't you go ahead and clarify for everyone here, you did just openly provide an example as to how digital signals can and are bit perfect 1:1 matches, regardless of the effect noise has on them. Correct?Too many good quotes to list..waiting for some fresh ammo. -
Where to start?Habanero Monk wrote: »Again: Ask Amir, in that thread, if his jitter measurements would enable him to deduce of whether the data is retrieved from local HD or pulled over the network.
andThe file itself contains no jitter whatsoever. Nor does it simulate "subtle timing inaccuracies." Remember, a file sitting on your hard disk before being played is just a bunch of digital audio samples.
First of all, I, and others, are talking about the process of moving a file (a file containing musical data) from point A to point B, and how each link has the potential to introduce audible distortion into the data. For whatever reason, Monk and villain keep talking about files on a hard drive. I dont understand why they keep going there since it has no relevance to the discussion.If you read what he is writing about in PLL recovered clock sync inputted over SP/DIF you would see he is talking about the jitter induced error of the PLL and that of the DAC buffer (not computer buffer).
Yes, he started out mentioning the DAC buffer, however he later says;
Well, there is a problem. A serious one. Buffering and clock regeneration do not deal with jitter by themselves.
A buffer is a buffer regardless of where it is located; in a DAC, in a computer, or in a router. While the implementation might be different in each component, the technology is basically the same. The data is clocked into the buffer, and the data is clocked out of the buffer. Also, it is almost guaranteed that the parts used to implement these buffers in a generic computer, or a Cisco, Brocade, Juniper router will be the absolute least expensive part that barely meets the design spec.You are truly out of your depth here and the sad thing is you don't even realize it.
Possibly, but so far all the data points to you as being out of your depth. While you have occasionally cut and pasted accurate statements, you continue to demonstrate a lack of understanding of the subject matter. Which is, any link used in the transfer of a digital musical file has the potential to introduce audible distortion into that file, even while the CRC remains correct.
And that answers your quasi-question.Now I'll just have to wait and see how it can be tied back into a BJC vs some other high $$ Ethernet cable.
The rest of his three posts consists of rambling in an attempt to sound smart, but comes across as desperate. For example,It completely makes my point that there are some that don't understand what is going on here due to failure to launch in their understanding of what is being spoken about.
If one did understand they would never have attempted it's use in fortifying their already indefensible position.Lumin X1 file player, Westminster Labs interconnect cable
Sony XA-5400ES SACD; Pass XP-22 pre; X600.5 amps
Magico S5 MKII Mcast Rose speakers; SPOD spikes
Shunyata Triton v3/Typhon QR on source, Denali 2000 (2) on amps
Shunyata Sigma XLR analog ICs, Sigma speaker cables
Shunyata Sigma HC (2), Sigma Analog, Sigma Digital, Z Anaconda (3) power cables
Mapleshade Samson V.3 four shelf solid maple rack, Micropoint brass footers
Three 20 amp circuits. -
They may appear to be the same when you look at them on a computer screen or they are analyzed with a scientific measuring device. When something more sensitive (as in the case of your ears, brain and consciousness) are used, it becomes much more apparent that what is received is not equivalent to the orignial source (to varying degrees of course). That's I believe the problem with "digital know-it-alls" is that they cannot use their brains and get to a fine enough detail (scale) to realise that when you get to a fine enough scale, there are electrical problems that show up in digital signals. Since their brains cannot get a hold of this, they think that digital transmissions are "perfect". Again, there are no perfect transfers of electrical signals, period.
Can you please explain to me what the differences are in the digital transmission outputs from the inputs that you hear when the hash is a 1:1 match? Can you also show me where that extra sound information is stored within the file? Where are the extra or malformed 0's and 1's? Do your 0's and 1's sound different than mine?
I think you're actually the one misunderstanding things here. Myself and Habanero aren't saying that signals don't get degraded or change. We're not debating that there are no perfect transfers of electric signals. What we're stating is that *digital* signals (Binary signals) are non-physically existant signals that are simply transported and decoded across traditional electrical signals. So while the electrical signal carrying a digital signal itself may vary, the final digital output that the variances in that electrical signal form remains the same..an exact 1:1 recreation of the original digital signal.Too many good quotes to list..waiting for some fresh ammo. -
First of all, I, and others, are talking about the process of moving a file (a file containing musical data) from point A to point B, and how each link has the potential to introduce audible distortion into the data. For whatever reason, Monk and villain keep talking about files on a hard drive. I don’t understand why they keep going there since it has no relevance to the discussion.
Because you first claimed that files have jitter?
That and because what you're failing to realize is that getting from A to B isn't such a straight, non-stop path. You get subsets of A to B within the larger A to B, and at each intersecting point, each stop and each time the digital signal reaches a new storage medium (Which includes any buffers..) any jitter that was acquired from the previous step is nullified. It's gone. Poof. Gone. Reset to zero. Jitter is a REAL TIME issue, therefore it cannot and does not exist outside of REAL TIME. Period.
Example. Xfer from NAS (A) to final output speakers (B) has hundreds of mini steps. File on Hard disk to buffer to RAM to NIC Card to Ethernet Cable to NIC Card to RAM to Buffer to etc, etc, etc. Each of those steps that aren't in Real time, eliminate any jitter that was acquired previously. I can't think of a way to explain this without frustrating my typing fingers, so I'm done. You probably wouldn't learn anyways, so there's your crappy example. It shouldn't be THAT hard to understand...seriously..Buffering and clock regeneration do not deal with jitter by themselves.”
Exactly, because they have no need to. As has been stated before each and every step along the way automatically resets jitter to Zero, not to mention that jitter can ONLY exist in real time. Therefore buffering and clock regeneration do not deal with jitter as it does not exist for them to deal with. Much as a softball pitcher doesn't deal with reverse osmosis purification of drinking water. He or She deals with throwing softballs, and catching them...any link used in the transfer of a digital musical file has the potential to introduce audible distortion into that file, even while the CRC remains correct.
And so we ask again...
Q: Where does this audible distortion exist in the digital music file, if the CRC remains correct?
Wait, did you just openly state that jitter exists in a file...AGAIN? Didn't you just get done denying that you had ever said that, after being called out for it once before? Jiminy Christmas! Talk about coming full circle...
Obviously we know where your true feelings belong this time, regardless of future excuses..Too many good quotes to list..waiting for some fresh ammo. -
Question for you BlueFox...Just to clarify does or does not jitter exist in a file? On a stored file? Yes or no to each one?Too many good quotes to list..waiting for some fresh ammo.
-
Here is a good link that pretty much explains in more detail what I, and others, have been saying.
http://www.positive-feedback.com/Issue43/jitter.htm
"Playback jitter originates from a large number of contributors, which are usually additive. These range from the master clock, which has its own jitter, to logic devices, to mechanical systems for spinning a CD. One digital cable can even add more jitter than another. Each contributor adds more jitter to the signal as it makes its way to the D/A converter. This summation of this jitter is the system jitter.
Here is a lengthy, but probably not complete list of jitter contributors, including how each of these can or might add jitter to a digital audio system:"
This part is almost verbatim to the theoretical troubleshooting hypothesis I proposed earlier on how an Ethernet cable could add jitter. Great minds think alike.
8. Digital Cables
Cables don't actively add jitter to the signal, however they can slow the signal transitions or "edges". When the edges are slowed, the receiver or buffer at the cable destination is less likely to detect the transition at the correct time with certainty, which results in jitter.
and in regard to computers and network equipment.
"The problem for audiophiles is that the majority of these end-point devices were designed with high-volume manufacturing and low-cost as requirements, with performance taking a lower priority. As a result, the jitter from these devices is higher than it could be. It should be the lowest of all the audio source devices available."Lumin X1 file player, Westminster Labs interconnect cable
Sony XA-5400ES SACD; Pass XP-22 pre; X600.5 amps
Magico S5 MKII Mcast Rose speakers; SPOD spikes
Shunyata Triton v3/Typhon QR on source, Denali 2000 (2) on amps
Shunyata Sigma XLR analog ICs, Sigma speaker cables
Shunyata Sigma HC (2), Sigma Analog, Sigma Digital, Z Anaconda (3) power cables
Mapleshade Samson V.3 four shelf solid maple rack, Micropoint brass footers
Three 20 amp circuits. -
Question for you BlueFox...Just to clarify does or does not jitter exist in a file? On a stored file? Yes or no to each one?
^ That. Let's go ahead and add one more. Does jitter exist in a file in storage mediums?Too many good quotes to list..waiting for some fresh ammo. -
And so we ask again...
Q: Where does this audible distortion exist in the digital music file, if the CRC remains correct?
^ See aboveToo many good quotes to list..waiting for some fresh ammo. -
Does jitter exist in a file in storage mediums?
Here's one for you: Do you listen to files while they are in storage mediums or do you listen to files after they have been converted to analog signals that your ears can hear?
Consider the following scenario:
1. Trees grown in a forest.
2. A sawmill that converts trees into finished lumber.
3. Three trucking companies that transport the lumber (2" x 4" x 8' studs) to a construction company warehouse.
4. A carpenter that converts the finished warehoused lumber into houses.
Trucking company A transports the lumber in sealed trailers. The 2 x 4s arrive at the warehouse in the same size and condition as when they left the saw mill.
Trucking company B transports the lumber on a flatbed truck, where it is rained on and termites get to nibble on it a bit, but not enough to make the 2 x 4s unusable. Exposure to the elements also causes a slight amount of warping, but not enough warping to make the 2 x 4s go out of spec.
Trucking company C first takes the lumber to a wood chipping company where a little bits of wood are randomly sliced off. The 2 x 4 still meet spec size.
The carpenter goes to pick up a load of lumber to build a house and he is given an assortment of 2 x 4s from the perfect, rained on/termite eaten, and chipped off stocks. The carpenter complains that the inconsistency in lumber quality affects his workflow efficiency and causes fatigue due to having to work around the defects in some of the lumber. This translates to the fit and finish of the house not being up to his usual standards.
The warehouse manager tells the carpenter that his complaint is without merit because all the lumber in the warehouse meets spec.Proud and loyal citizen of the Digital Domain and Solid State Country! -
Where to start?
An understanding in how this actually works would be a good start for you.First of all, I, and others, are talking about the process of moving a file (a file containing musical data) from point A to point B, and how each link has the potential to introduce audible distortion into the data. For whatever reason, Monk and villain keep talking about files on a hard drive. I don’t understand why they keep going there since it has no relevance to the discussion.
Or a file stored, statically, in RAM. It has complete relevance.Yes, he started out mentioning the DAC buffer, however he later says;
“Well, there is a problem. A serious one. Buffering and clock regeneration do not deal with jitter by themselves.”
You have not a clue as to what Amir is referencing do you? I'll help you out:
Of course the problem can be solved using skilled designers and budgets that are measured in tens of dollars as opposed to single digit.
So what is Amir saying is being solved with skilled designers and budgets that are measured in the tens of dollars? He certainly goes on to show some other DAC's with lower jitter noise floor. Are they not using a buffer? Are they not using some form of clock recovery scheme?
He's talking about poorly implemented clock recovery schemes. He doesn't even mention what the SOURCE of the file is. Only that the input is SP/DIF and not even if it is optical or co-axial.
It's even mentioned in same thread about you should be using A-Sync USB:
"So, you want a perfect clock to drive your DAC, but you must provide buffering and/or some type of synchronization so you do not lose data in an asynchronous system. It's complicated."
And
"This is why async USB is a Good Thing."
They are mentioning this because Amir picked a delivery mechanism (SP/DIF) that can be problematic due to it's very nature.
The issue is that the PLL mechanism is creating it's own Jitter as it reads out of buffer. Even adding up to 2dB! Why don't you ask Amir how he knows it's ADDING 2dB. It's not there in the buffer, it's added in the re-clocking.
How on this earth are you even remotely tying this to the computer buffer? He's making the point that nothing can help out a cheap, poorly designed, clock recovery circuit.
You are trying to round the square with his thread and you are so off the mark you don't even understand the point he is trying to make.
Again: Ask Amir if he can deduce by the jitter measurement over SP/DIF the source: Ethernet Cable A or Ethernet Cable B.A buffer is a buffer regardless of where it is located; in a DAC, in a computer, or in a router. While the implementation might be different in each component, the technology is basically the same. The data is clocked into the buffer, and the data is clocked out of the buffer. Also, it is almost guaranteed that the parts used to implement these buffers in a generic computer, or a Cisco, Brocade, Juniper router will be the absolute least expensive part that barely meets the design spec.
Wrong again. There is NO audio clocking in and out of RAM or HD. It's a fetch after that point. It's still DATA. Static. Only when it's bitstreamed to the DAC and decoded at the DAC is clocking data extracted. -
Here is a good link that pretty much explains in more detail what I, and others, have been saying.
http://www.positive-feedback.com/Issue43/jitter.htm
Blue you must not be reading what you are posting, but thanks for another slow ball right over home plate. From the article you linked to:
Jitter and Networked audio
Networked audio (Ethernet), both wired and WiFi is a unique case. Because the data is transmitted in packets with flow-control, re-try for errors and buffering at the end-point device, it is not as much of a real-time transfer as USB, S/PDIF or Firewire. The computer transmitting the data packets must still keep-up" the pace to prevent dropouts from occurring, but the real-time nature of the transfer is looser. Unlike with other protocols, there can be dead-times when no data is being transferred. Networking also avoids the use of the audio stack of the computer audio system since it treats all data essentially the same. This avoids kmixer on XP systems and the audio stacks on Mac and PC Vista. Because of the packet-transfer protocol of Ethernet and data buffering at the end-point, the jitter of the clock in the computer is a non-issue. The only clock that is important is the one in the end-point device. Examples of end-point devices are: Squeezebox, Duet and Sonos. This would seem to be the ideal situation, which it certainly is. The only problem that can occur is overloading the network with traffic or WiFi interference, which may cause occasional dropouts. The problem for audiophiles is that the majority of these end-point devices were designed with high-volume manufacturing and low-cost as requirements, with performance taking a lower priority. As a result, the jitter from these devices is higher than it could be. It should be the lowest of all the audio source devices available.
it is not as much of a real-time transfer = it's not real time. There is no such thing as partially pregnant. Now lets see what I said about Networking and Computers not being real time.
Unlike with other protocols, there can be dead-times when no data is being transferred. Networking also avoids the use of the audio stack of the computer audio system since it treats all data essentially the same.
Another one knocked out of the park. Wow, dead times while audio is playing but no data is transfered. And drum roll please: Data is DATA.
This would seem to be the ideal situation, which it certainly is
The only problem that can occur is overloading the network with traffic or WiFi interference, which may cause occasional dropouts.
Total agreement with him there.
The problem for audiophiles is that the majority of these end-point devices were designed with high-volume manufacturing and low-cost as requirements, with performance taking a lower priority. As a result, the jitter from these devices is higher than it could be. It should be the lowest of all the audio source devices available.
So to finish this up he is talking about cheap end point devices like the Squeeze Box etc.... -
“8. Digital Cables
Cables don't actively add jitter to the signal, however they can slow the signal transitions or "edges". When the edges are slowed, the receiver or buffer at the cable destination is less likely to detect the transition at the correct time with certainty, which results in jitter.”
He's not talking about Ethernet at this point. He's talking about SP/DIF and Toslink.
He addresses Ethernet in it's own paragraph. -
LOL. Once again, The Monk shows his reading comprehension skills are nil, zero, none, and to think he has a Certificate in networking. :rolleyes:
In so far as the troll, he can make up his own answers, as he has done so far.Lumin X1 file player, Westminster Labs interconnect cable
Sony XA-5400ES SACD; Pass XP-22 pre; X600.5 amps
Magico S5 MKII Mcast Rose speakers; SPOD spikes
Shunyata Triton v3/Typhon QR on source, Denali 2000 (2) on amps
Shunyata Sigma XLR analog ICs, Sigma speaker cables
Shunyata Sigma HC (2), Sigma Analog, Sigma Digital, Z Anaconda (3) power cables
Mapleshade Samson V.3 four shelf solid maple rack, Micropoint brass footers
Three 20 amp circuits. -
LOL. Once again, The Monk shows his reading comprehension skills are nil, zero, none, and to think he has a Certificate in networking. :rolleyes:
In so far as the troll, he can make up his own answers, as he has done so far.
At least I'm not the idiot.
From the article YOU linked:
Because of the packet-transfer protocol of Ethernet and data buffering at the end-point, the jitter of the clock in the computer is a non-issue.
Feel free to point out my error as to the article that you linked to about jitter. -
Habanero Monk wrote: »At least I'm not the idiot.
You sure are doing a good job of fooling everyone else.From the article YOU linked:
Because of the packet-transfer protocol of Ethernet and data buffering at the end-point, the jitter of the clock in the computer is a non-issue.
What did I say when I posted that link. Oh yes.Here is a good link that pretty much explains in more detail what I, and others, have been saying.
And that is basically everything in the link as a file is transferred from A to B has the potential to add jitter, which I believe is all I have ever said.
So, to answer your question, from the link, some relevent passages.
Jitter has been with us since the inception of the CD format by Sony and Philips in 1982. It is a pervasive problem with all digital audio. It has prevented digital audio, both CD's and computer-driven-audio from competing with good vinyl and tape for decades. It is only recently that manufacturers have become aware of the problem and developed improved chips and systems to deal with jitter.
The jitter associated with digital streaming audio is usually a mix of non-correlated and correlated jitter, correlated being that jitter that is somehow related to the music data or waveform and uncorrelated usually being random jitter.
The audio data transfer must include both 1) accurate data and 2) accurate timing, whereas non-real-time transfers only require accurate data.
Playback jitter originates from a large number of contributors, which are usually additive. These range from the master clock, which has its own jitter, to logic devices, to mechanical systems for spinning a CD. One digital cable can even add more jitter than another. Each contributor adds more jitter to the signal as it makes its way to the D/A converter. This summation of this jitter is the system jitter.
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. This jitter is a result of the speed of the device, thermal effects on the silicon die, power delivery on the die and even transmission-line effects.
The DC power applied to each of the devices that must process or transmit the digital audio signal is critical. If this power varies in voltage, the devices will react differently to the applied digital signals. Power "noise" as it is referred to is probably one of the largest contributors to jitter. Voltage changes or "voltage droop" can happen anywhere on a circuit board, power cabling, or even on the silicon itself. Changes in power voltage will change the speed and reaction times of digital logic that is transmitting the digital signals resulting in jitter.
Cables don't actively add jitter to the signal, however they can slow the signal transitions or "edges". When the edges are slowed, the receiver or buffer at the cable destination is less likely to detect the transition at the correct time with certainty, which results in jitter.Lumin X1 file player, Westminster Labs interconnect cable
Sony XA-5400ES SACD; Pass XP-22 pre; X600.5 amps
Magico S5 MKII Mcast Rose speakers; SPOD spikes
Shunyata Triton v3/Typhon QR on source, Denali 2000 (2) on amps
Shunyata Sigma XLR analog ICs, Sigma speaker cables
Shunyata Sigma HC (2), Sigma Analog, Sigma Digital, Z Anaconda (3) power cables
Mapleshade Samson V.3 four shelf solid maple rack, Micropoint brass footers
Three 20 amp circuits. -
Question for you BlueFox...Just to clarify does or does not jitter exist in a file? On a stored file? Yes or no to each one?
Depends where the "stored" file comes from. Jitter can be present in the mastering process, which then will be present in every single copy made from that Master. You need to be more specific with your question.
H9"Appreciation of audio is a completely subjective human experience. Measurements can provide a measure of insight, but are no substitute for human judgment. Why are we looking to reduce a subjective experience to objective criteria anyway? The subtleties of music and audio reproduction are for those who appreciate it. Differentiation by numbers is for those who do not".--Nelson Pass Pass Labs XA25 | EE Avant Pre | EE Mini Max Supreme DAC | MIT Shotgun S1 | Puritan Audio PSM136 Pwr Condtioner & Classic PC's | Legend L600 | Roon Nucleus 1 w/LPS - Tubes add soul!
This discussion has been closed.