Does high quality digital cables matter?

headrott

Habanero Monk wrote: »

Toss in Ocean going ships, cars, car parts, and of all things absurd: Cake ingredients.

I'm sorry you didn't learn anything from the analogies.

headrott

villian wrote: »

I don't see how that proves that certain data is "Harder" for a cable to transport than other data. IF that were true then you'd have to test and see the results in a different way than what you've experienced. Something like this..

Cable A ---> Playback 2ch audio (PCM Bitstream 300kbs) ---> Success
Cable A ---> Playback 7ch mixed audio/video (20Mbps total) ---> Failure


Instead of your experiment of..

Cable A ---> Fail
Cable B ---> Sucess


I don't know how you concluded that something is "Harder" or more strenous for a cable to transport when your results were obtained with 2 different cables...

Go back and re-read the post from page 2 again. I refuse to post it a 4th time. I used the same cable for two different "data" types and got different results...........

villian

ZLTFUL wrote: »

Pot, meet Kettle. Talk about a spade calling a spade. Why don't you follow your own advice? You can be a "Polk enthusiast" without being a "dick" but that concept evades you in a most glorious fashion. You can't come into a conversation without spewing troll cooties all over the place. Maybe if you actually debated a point instead of the inane name calling and flame baiting, you would find the "dicks" as you call them more receptive to your point of view.

As my grandfather said, you catch more ants with honey than you do pouring gasoline on the ant hill and tossing on a match.

And where exactly have I been a dick and name called others? Needless to say that I don't think I've been the least bit unprofessional..unlike you and a few others making snide remarks. That said, I'm all for debating BUT I'm not going to debate things that don't need to be debated. Some things are factual, and those things that have long since been proven have no need for debate. IE: What's to debate in water filtration? NOTHING.

Habanero Monk

headrott wrote: »

I'm sorry you didn't learn anything from the analogies.

LOL. The Ship and Car analogy didn't quite work out the way the person making the analogy wanted so they abandoned the hot iron they were shown to have grasped and moved onto.... wait for it.... Cakes. Not sure chocolate or some other flavor.

I STILL haven't seen a riposte to when I took that analogy to it's proper conclusion: The person driving the assembled car has not a clue that the ships arrived 4 hours apart.

When you are shipping parts you are shipping parts. When you are shipping cars you are shipping cars. Parts to not the cars make

Part of the make up of a car is the LABOR(buffering, bitstreaming, CODEC) that goes into the assembly and not only the transport of parts in the analogy that DK provided.

I've never seen vehicles self assemble outside of a Michael Bay film.

That fact that you haven't even figured out that even if entire, assembled cars were being shipped, the person that is driving the car off the showroom floor doesn't know if it was 4 hours ahead or 4 hours behind another same identical car. But I digress because that is not how packet networking works. Which is the only thing I am concerning my self with or willing to speak to: CAT5/6/7 used for on label use.

So parts being put into shipping containers (actually cars disassembled into it's constituent parts) = packetization process (on a fixed frequency carrier and digital data)

Time to port = 10/100/1000 (on a fixed fequency carrier and digital data)

Ethernet standard packet (doesn't matter size 1500/4096/8000/9014: The ships

Assembly= the assembly of data in buffer/CODEC/ bitstreaming to the sound device. Still digital data (just pulled out of packets and buffered).

Driving= Listening to it on your speakers (analog data and multi-frequency)

I mean for pete's sake I had to point out we aren't even doing this stuff on RTOS's. Not to be confused to ROES's :biggrin:

So when you download your favorite album from HD tracks on a $60 router and a $1000 router is there a difference. Would you want to stake some money on that. Say the price of a really nice DAC?

DarqueKnight

Habanero Monk wrote: »

LOL. The Ship and Car analogy didn't quite work out the way the person making the analogy wanted so they abandoned the hot iron they were shown to have grasped and moved onto.... wait for it.... Cakes. Not sure chocolate or some other flavor.

I STILL haven't seen a riposte to when I took that analogy to it's proper conclusion: The person driving the assembled car has not a clue that the ships arrived 4 hours apart.

Go back and carefully read posts #614 and #644. I realize you think you are making a lot of sense, but when you think things through you might come to a correct conclusion.

Again, the time of arrival of parts is irrelevant. What happened to the parts in transit and the accuracy with which the parts are reassembled are the relevant concepts.

Habanero Monk wrote: »

When you are shipping parts you are shipping parts. When you are shipping cars you are shipping cars. Parts to not the cars make

Tell me this. Assume you are going to ship your diassembled vehicle to Europe. Would you insure it as an automobile or as a collection of parts? If the ship sinks, would you want to be reimbursed for the value of the parts or for the total value of the car?

Habanero Monk wrote: »

Part of the make up of a car is the LABOR(buffering, bitstreaming, CODEC) that goes into the assembly and not only the transport of parts in the analogy that DK provided.

You saying all this does not obscure the fact that you do not understand that a digitally encoded signal is still multi-frequency and wideband. The bandwidth and frequency relationships are still maintained in digital form, otherwise the signal could not be accurately converted back to analog. I'm assuming you are not being purposely obtuse, therefore I'll take one more stab at it.

If a car is disassembled for shipping, some marking of parts had to occur so that the relationship between the various parts can be properly reassembled. Such a shipment would not be seen by taxation authorities and shipping authorities as a shipment of raw parts, such as those to a factory, but rather as a complete vehicle shipment, although the vehicle is in disassembled form. The receiver on the other end did not order a bunch of parts, they ordered a complete automobile.

In other words, the labor that went into first assembling the car must be coded while in shipment so that the assembly process can be replicated at the delivery end.

Habanero Monk wrote: »

I've never seen vehicles self assemble outside of a Michael Bay film.

Not sure why you said this as I never explicitly stated or alluded to such.

Habanero Monk wrote: »

That fact that you haven't even figured out that even if entire, assembled cars were being shipped, the person that is driving the car off the showroom floor doesn't know if it was 4 hours ahead or 4 hours behind another same identical car. But I digress because that is not how packet networking works. Which is the only thing I am concerning my self with or willing to speak to: CAT5/6/7 used for on label use.

The bizarre thing is that you can't grasp that, for a non-isochronous process, packet time of arrival is irrelevant. What is relevant is what happened to the packet in transit and how the associated packets were reassembled into a complete data file.

Again, you are assuming that the transport and reassembly experience of the two cars was the same. Mishandling and damage of some sort could have occurred in shipment. Errors and damage could have occurred in reassembly.

Habanero Monk wrote: »

So parts being put into shipping containers (actually cars disassembled into it's constituent parts) = packetization process (on a fixed frequency carrier and digital data)

Time to port = 10/100/1000 (on a fixed fequency carrier and digital data)

Ethernet standard packet (doesn't matter size 1500/4096/8000/9014: The ships

Assembly= the assembly of data in buffer/CODEC/ bitstreaming to the sound device. Still digital data (just pulled out of packets and buffered).

Driving= Listening to it on your speakers (analog data and multi-frequency)

You are assuming that:

Each ship and shipping route is identical.
Each assembly team will do an identical job.
If there are shipping damage and assembly errors, no drivers will be able to perceive them.

Habanero Monk wrote: »

So when you download your favorite album from HD tracks on a $60 router and a $1000 router is there a difference. Would you want to stake some money on that. Say the price of a really nice DAC?

I am not sure why you keep asking me if I want to make a bet on a perceptual exercise that I have no training or experience in. Perhaps you think doing so makes your point seem more valid. I have already advised you twice to seek out those individuals who are claiming to hear differences in Ethernet cables. My position is that it is possible.

I have asked you several times to provide the article you mentioned where some sales reps from either AQ or MIT met with Jim Salk and they could not pick out their company's cables in a blind test. Do you have proper citation for this or were you just parroting something you read on the Internet?

ZLTFUL

villian wrote: »

And where exactly have I been a dick and name called others? Needless to say that I don't think I've been the least bit unprofessional..unlike you and a few others making snide remarks. That said, I'm all for debating BUT I'm not going to debate things that don't need to be debated. Some things are factual, and those things that have long since been proven have no need for debate. IE: What's to debate in water filtration? NOTHING.

This is going to be a fun exercise in that it is so easy, I am almost ashamed to point out how obviously silly you sound. But here goes...

And quite a foolish looking one now? Understandably so, but I'd like to see you admit it first

Thank you all for showing up to class today, but I have to wipe this chalk off my hands and get to bed

Veiled douchebaggery is still douchebaggery.

That was an ignorant statement.

Actually, the person you called ignorant made a very valid point but it didn't fit into your own preconceived opinion so...yeah.

So...

You used MDF instead of high ply count Baltic Birch plywood. Obvious SQL mistake number one.

Mistake number two. You used ROUND ports?

Come on, you guys all talk about Sound quality..then make rookie mistakes like this? (Round ports induce huge amounts of noise via horrific airflow characteristics into and out of the port, especially along the edge and throughout the center) Correct me if I'm wrong on the ports, but I hope I'm not! My point is, we all know a few great things that can make an home theater just totally awesome! (Like you Dennis..awesome sub box idea..on point, no doubt, and honestly quite brilliant!) BUT we all know just a smidget of the total sum that equates to reference level sound quality, and therefore should be open to the ideas of others who may specialize in a different smidget than ourselves. Quality Live Sound/DJ amps is one of those things that I know quite a bit about, as well as speaker box construction Please feel free to school me on the rest, as I will gladly take in that knowledge and improve my own with it!

I'm not going to claim to know everything, because I don't. But as a whole, I'm pretty sure we do. So let's put that knowledge together and work from there. Fair enough? It's 2014, we just had a member buy himself a modern, reliable, high quality Live Sound/DJ amp (Crown XLS 1500) to compare to other HT dedicated amps costing hundreds more. His verdict? So far so good, no complaints. Boom. Let's all learn and keep testing out theories like this to avoid wasting money on products we should have never bought in the first place!]

That whole response is nothing more than a trolling attempt. If you can't see that, you are far more delusional than we thought.

I just lol'd...hard! Thread is so full of win!

Not trolling? Sure you're not... /sarcasm

http://www.webmd.com/pain-management/what-is-the-placebo-effect

Yeah...still not trolling? Sure...

You'd be surprised at the difference between "Cheap" and "Expensive" speaker wiring Try a coat hanger yet?

Starting to see a theme here...anybody else? Only everyone except you.

50% effectively, Jesus didn't know I had to spell that one out. I get how cameras work and I'm trying to keep it in simple terms for everyone.

What I find abso****inglutely hilarious is the part in a previous thread where you say

I don't claim to know everything

but then...well you claim to know everything. From cameras to water filters to packetized data networks to...well...you sure ACT like you know everything...even though,

Sounds like I'm going to be hitting the books, or at least google, tonight!

I answered you twice already, and stated that I have no desire to continue a fruitless conversation with you or anyone else in this thread as there's no need for that...but...I will once again post...

Now, I'm not saying you're trolling, but trolling.

So I mention some very valuable facts in a photography thread and get ripped by someone who's totally clueless.

Actually, once again, you are calling someone clueless who offered advice just as pertinent as yours. But it didn't match your OPINION so you call this well respected member of the forum "clueless". Yup...no trolling there at all. /sarcasm

You know what...it is way too easy to continue. Wasn't much of a challenge. But we will cap it off with the latest and greatest where you "weren't a dick to anyone"...

Just don't get why some people here would be total dicks after answering their question.

We are a reactionary species. We (mostly) treat others how they treat us. So if you wonder why people are treating you like ****, maybe it is because you have been doing likewise in turn. I would say that it is something for you to ponder but I know people like you. People who think they are always right and have no desire to have their opinions challenged. If someone does, they are immediately perceived as a threat and your first instinct is to challenge them to some kind of neurotic pissing contest.

Habanero Monk

DarqueKnight wrote: »

Go back and carefully read posts #614 and #644. I realize you think you are making a lot of sense, but when you think things through you might come to a correct conclusion.

Again, the time of arrival of parts is irrelevant. What happened to the parts in transit and the accuracy with which the parts are reassembled are the relevant concepts.

For amplitude derived digital data absolutely not. There is a peak and trough threashold for starters. Once the peak or trough hit's the demarcation point for a solid 0 or 1 it's done.

I understand your point. You are making the wrong one.

You are saying that there is a potential for an AQ or Chord Ethernet cable to some how via what ever modulated method used is somehow potentially better at this than another certified cable that is well above spec.

That's pure rubbish.

First you have to prove that there is going to be a difference in error rate. If both cables pass the modulated signal with out error, the nano-scale measured timing variance doesn't matter because the computer OS isn't real time. It's NOT time sensitive on a scale that will translate into error that you can hear.

Lets take a gross and overly simplistic example of this:

BJC CAT6 that it's worst measurement is 200% above baseline. Well first off you have to be willing to make a hypothesis why this would introduce any significant timing errors that would produce an audible result.

AQ Vodka 1.5 meter and assume it's no worse measurement wise an potentially better in some aspects.

The receiving system is now at the mercy of the weakest link: The transceivers that make up the Ethernet PHY at both the NIC and the switch. Well you are kind of screwed there now aren't you? You have cables that at minimum have almost twice the performance metric needed.

Now lets say we have JRiver setup and using the Play Back from RAM feature. That is 1GB of RAM is MMU'd off and the entire album is transferred with out any packet error. Just some nano-scale timing varience. You are going to sit there tell people here that a file that took 7.0001 seconds on cable A and Cable B took 7.00189 to transfer into RAM, then decoded, then bitstreamed to a DAC is going to have differences?

DarqueKnight wrote: »

Tell me this. Assume you are going to ship your diassembled vehicle to Europe. Would you insure it as an automobile or as a collection of parts? If the ship sinks, would you want to be reimbursed for the value of the parts or for the total value of the car?

If you can relate that to packet data let me know.

DarqueKnight wrote: »

You saying all this does not obscure the fact that you do not understand that a digitally encoded signal is still multi-frequency and wideband. The bandwidth and frequency relationships are still maintained in digital form, otherwise the signal could not be accurately converted back to analog. I'm assuming you are not being purposely obtuse, therefore I'll take one more stab at it.

It's not far as the cable is concerned. On the wire it is just DATA. You are having a failing to understand that this can all be turned into a mathematical equation. It's a construct. The only time is is purely still multi-frequency and wideband is the time it hits the microphone and is analog to the A/D and the time it hits the D/A and is again analog. Every thing in between is a simulacrum of the analog realm.

You show me a O-Scope measurement of 250Mhz Ethernet where I can see if it's 20Hz or 20Khz then we can talk. I mean you are showing me a true 'analog' signal at that point.

We are going to have to agree to disagree on that point. You certainly haven't made yours.

If I 3D image your head, save it to a file, send it to a resin 3D printer 3000 miles away, is the signal still 3 dimensional and wideband as it goes through 28 hops? or is it just data?

If the resultant bobble head is 5 inches by 8 inches did the cabling that sent the file have to be 6 by 9?

If it goes through a $60 dollar router do you gain a funny mustache and goatee and if it goes through a $1000 router do you look like an uncanny rendition of George Clooney?

DarqueKnight wrote: »

If a car is disassembled for shipping, some marking of parts had to occur so that the relationship between the various parts can be properly reassembled. Such a shipment would not be seen by taxation authorities and shipping authorities as a shipment of raw parts, such as those to a factory, but rather as a complete vehicle shipment, although the vehicle is in disassembled form. The receiver on the other end did not order a bunch of parts, they ordered a complete automobile.

In other words, the labor that went into first assembling the car must be coded while in shipment so that the assembly process can be replicated at the delivery end.

You do realize that you are stretching the analogy. If you want to continue on that tangent I'm willing to entertain it provided you can find me a large scale auto manufacturer that assembles their cars, then disassembles them, ships it, then re-assembles.

Because that is what data networks do all the time.

DarqueKnight wrote: »

The bizarre thing is that you can't grasp that, for a non-isochronous process, packet time of arrival is irrelevant. What is relevant is what happened to the packet in transit and how the associated packets were reassembled into a complete data file.

What is bizarre is you still have yet to answer the simple question of if I sent a 24/192 encoded file of some well mastered music do you think anyone could tell me after playback if it landed on the computers HD via a $60/$1000/$58,000 router?

DarqueKnight wrote: »

Again, you are assuming that the transport and reassembly experience of the two cars was the same. Mishandling and damage of some sort could have occurred in shipment. Errors and damage could have occurred in reassembly.

Actually I made myself quite clear on this where MD5 Hashes are quite the rage for verification of file integrity.

You are assuming more errors would happen on one vs another cable. You have brought nothing to the table data wise that would leave me no other choice then to line up with your anecdotal POV.

You have to show me the actual error in order for me to see it.

DarqueKnight wrote: »

You are assuming that:

Each ship and shipping route is identical.

Absolutely not.

DarqueKnight wrote: »

Each assembly team will do an identical job.
If there are shipping damage and assembly errors, no drivers will be able to perceive them.

Absolutely not. CRC of SMB/CIFS at the session layer, TPC at the transport layer, custom protocols at the session through application layer, is there for a reason including both benign and malign problems.

Now once that file has hit my HD and plays back with out issue I am guaranteed delivery.

DarqueKnight wrote: »

I am not sure why you keep asking me if I want to make a bet on a perceptual exercise that I have no training or experience in. Perhaps you think doing so makes your point seem more valid. I have already advised you twice to seek out those individuals who are claiming to hear differences in Ethernet cables. My position is that it is possible.

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.

DarqueKnight wrote: »

I have asked you several times to provide the article you mentioned where some sales reps from either AQ or MIT met with Jim Salk and they could not pick out their company's cables in a blind test. Do you have proper citation for this or were you just parroting something you read on the Internet?

You could ask several more...

DarqueKnight

Habanero Monk wrote: »

My position is that it's not possible.

Since you have convinced yourself that your hypothesis is infallible, then others may also become convinced that there is no point in participating in your "research". You present yourself as someone hell-bent on proving that people are either deluded or lying rather than someone interested in learning about network audio perception.

A true scientist forms a hypothesis with the understanding that experimentation and observation may prove or disprove the hypothesis, or the experimental results might be inconclusive.

In the scientific world, the burden of proof is on the challenger of a theory. For example, when someone said they invented ABX in 1977, I did not get in his face and ask him to prove his claim. I researched the topic and found that the ABX test was invented 27 years earlier, by Peryam and Swartz in 1950. The outside observer could then choose whichever source of information they deemed most credible.

When a group of people claimed that the ABX and other blind tests were the only way to mitigate bias in stereo equipment evaluation, I did not get in their face and ask them to prove their claim. I researched the topic and found credible scientific evidence of consumer debiasing methodologies in addition to credible scientific evidence from the field of sensory science that said descriptive tests, rather than discrimination tests, are appropriate for the multi-dimensional sensory stimuli presented by a stereo sound stage. I left it up to the outside observer to choose whichever source of information they deemed most credible.

Habanero Monk wrote: »

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.

People will be more inclined to take you seriously and assist you if you approach them in the spirit of honest and sincere scientific curiosity and inquiry rather than with a chip on your shoulder and a vulgar attitude of arrogant entitlement. No one owes you their time. Someone who has proven to themselves what they can hear has nothing to prove to you or anyone else.

Ignoring a challenge does not equate to fear of the challenge. Bruce Lee, Muhammad Ali, and Mike Tyson walked away from a lot of street fights.

Habanero Monk wrote: »

You could ask several more...

That's what I thought. Thanks for the confirmation.

Habanero Monk

DarqueKnight wrote: »

Since you have convinced yourself that your hypothesis is infallible

I'm convinced how packet data works. I'm convinced transferring an entire album of 16/44.1 that is 50 minutes in human time in ~7 seconds and then playing it back from RAM all backed with the knowledge how TCP, how SMB/CIFS, works.

I'm convinced when I downloaded both Vortex Box and FreeNAS ISO's that when I burn them to disc, insert them into a drive, boot and install those products that at the end I have exactly what was at the server that I downloaded them from.

I understand leaving your options open. I mean try putting diesel in your car that takes gasoline. It COULD work. I guess I'll have to go and do oodles of research...

Hey just because it doesn't work for you just means your only so so in your car driving skills. But someone else might be able to do it.

I think it's rather telling that some major points that I have put across have still to this 18th page been totally ignored.

BlueFox

Monk, it has been explained to you multiple times how jitter is introduced into musical files, and that it is possible for this to occur due to the Ethernet cable used in the final link to the hardware converting the data to SPDIF data. These packets will have no Ethernet errors, but will have musical errors. Yet you continue to ignore this. As DK said, a real scientist will have an open mind on these issues. No where have you demonstrated that the level of jitter in the musical file is the same regardless of the cable used. Instead you keep harping on irrelevent issues that DACs remove all jitter (not true), or it is inaudible. No wonder nobody takes you seriously.

I did learn something from this thread. When a resume shows up, and the applicant states they have a Networking Certificate, it is going straight into the circular file. :rolleyes:

Habanero Monk

BlueFox wrote: »

Monk, it has been explained to you multiple times how jitter is introduced into musical files, and that it is possible for this to occur due to the Ethernet cable used in the final link to the hardware converting the data to SPDIF data. These packets will have no Ethernet errors, but will have musical errors. Yet you continue to ignore this. As DK said, a real scientist will have an open mind on these issues. No where have you demonstrated that the level of jitter in the musical file is the same regardless of the cable used. Instead you keep harping on irrelevent issues that DACs remove all jitter (not true), or it is inaudible. No wonder nobody takes you seriously.

I did learn something from this thread. When a resume shows up, and the applicant states they have a Networking Certificate, it is going straight into the circular file. :rolleyes:

A file transferred by BJC cable or a Audio Quest cable. Buffered entirely in RAM. You show me where the jitter is less. Show me the amount of jitter in the file.

You do realize that jitter is in the time domain right? When I download a file from HD Tracks and it's stored on my HD jitter doesn't matter any longer. Jitter doesn't have a ringing period for petes sake.

The next time Jitter comes up for that file is when it get's played. It doesn't matter a fig what the jitter was like on the initial transfer.

Same as it doesn't matter what the jitter on the transfer of the file was to RAM. As long as the buffer is not under run the data is the data is the data.

Jitter is a REAL TIME phenomenon. Windows, Mac OSX, aren't real time. This stuff gets dumped to a buffer. It's just a type of storage medium. The next possible jitter is the signalling on a stick of RAM as it's read out.

Jitter isn't "part of the musical file".

I didn't say DAC's remove Jitter. I said they RECLOCK the input. Jitter suppression. Jitter removal is impossible. You can only get it down to levels that are inaudible.

BlueFox

Keep on digging that hole. You almost are in China by now. When you catch a clue then come on back. You have, once again, shown you have no idea what you are talking about. Ignorance is bliss.

F1nut

http://www.stereophile.com/news/050905debate/

heiney9

Habanero Monk wrote: »

DK's welcome point about transporting car parts via ship makes my point:

You have two different ships show up 4 hours apart, they could have even come by different routes. They all get parts offloaded next day, cars assembled, trucked to show room.

The consumer purchasing the car is none the wiser for knowing that the parts came by two different routes and 4 hours apart.

Very poor analogy as time delay in an audio signal is detrimental, time delay in manufacturing isn't in your above analogy.

H9

tonyb

Breath...wasted.

Those that seek out nothing.....find nothing.

Habanero Monk

heiney9 wrote: »

Very poor analogy as time delay in an audio signal is detrimental, time delay in manufacturing isn't in your above analogy.

H9

BTW it's DK's analogy. And I did answer rather explicitly the time delay in the "manufacturing" or "assembly" process:

The next time Jitter comes up for that file is when it get's played. It doesn't matter a fig what the jitter was like on the initial transfer.

Same as it doesn't matter what the jitter on the transfer of the file was to RAM. As long as the buffer is not under run the data is the data is the data.

I didn't say DAC's remove Jitter. I said they RECLOCK the input. Jitter suppression. Jitter removal is impossible. You can only get it down to levels that are inaudible.

In this instance the difference in arrival has nothing to do with the manufacturing. Both ships have arrived with parts in the window that they needed to arrive in. The assembly plant is still working with inventory at hand and the parts will arrive and sit there in a LILO manner vs parts already at the plant. It's a moot point.

Look it's clear you guys are out of your native element here and that's ok. Let me finish up with ZLTFUL and then I'll move onto the rest of you.

I'm dealing with people that believe jitter is 'Part of the Music File'. What is there really to say?

BlueFox

Habanero Monk wrote: »

Look it's clear you guys are out of your native element here and that's ok. Let me finish up with ZLTFUL and then I'll move onto the rest of you.

Yeah right. You have clearly demonstrated your 'knowledge' over and over. :rolleyes:

I'm dealing with people that believe jitter is 'Part of the Music File'. What is there really to say?

You are dealing with people who understand the issues related to digital music files, while you obviously do not. Go back and actually read the link you posted about jitter. Read other links about jitter. Quit thinking you know everything because you have a 'Certificate'.

If you want to get spanked some more you can also start a thread about how you don't think power cords make a difference.

Habanero Monk

BlueFox wrote: »

Yeah right. You have clearly demonstrated your 'knowledge' over and over. :rolleyes:



You are dealing with people who understand the issues related to digital music files, while you obviously do not. Go back and actually read the link you posted about jitter. Read other links about jitter. Quit thinking you know everything because you have a 'Certificate'.

I'll let any points made on their own merit for any outsider. Quit thinking you know everything.

I'll await your answer on how jitter is 'part of the file'. I'll await your answer on how a file that passes CRC or MD5 HASH is different when transmitted over a BJC or AQ Ethernet cable.

Habanero Monk

BlueFox wrote: »

These packets will have no Ethernet errors, but will have musical errors. Yet you continue to ignore this. As DK said, a real scientist will have an open mind on these issues.

When an application is playing back audio, JRiver for instance, it's not playing data directly off the cable. It's playing it out of buffer. The default is 6 seconds of pre-buffer (up to 20).

This is an area set aside and roped off in RAM by the MMU. Once data is resident in RAM, the buffer is filled, the timing variance doesn't matter.

You are talking about audible jitter in a system were 6/10/20 seconds of playback is transferred in the millisecond and possibly quicker range. After the transfer has happened to fill the buffer regardless of jitter on a transfer that took place over a CAT5/6/7 cable that exceeds specs with out any signaling errors the only jitter that you no worry about is the RAM signalling.

Once the five gallon bucket is filled at a rate of 5 gallons a minute where you are taking out only 1 quart a minute to consume it doesn't matter if the rate of fill had some time variance. As long as that 5 gallon bucket doesn't go below 1 quart you aren't going to have issues.

Then it goes to the DAC over the USB (Jitter there) then it hits the re-clocking mechanism that attempts to get that last leg of jitter suppressed. In computer processing terms an Jitter on the network wire is way back in the rear view mirror. It's a non-starter in this Windows or Mac Client / Server scenario.

badchad

F1nut wrote: »

http://www.stereophile.com/news/050905debate/

That was a good read.

villian

Habanero Monk wrote: »

Jitter is a REAL TIME phenomenon. Windows, Mac OSX, aren't real time. This stuff gets dumped to a buffer. It's just a type of storage medium. The next possible jitter is the signalling on a stick of RAM as it's read out.

Jitter isn't "part of the musical file".

Trust me, there's more jitter in music stored in 64k ReFS blocks than 4k NTFS blocks. I'm not sure why yet but you can hear the difference. I calculate it's 2db at 0 disk RPM, regardless of block size or file system. Night and day difference when I used my Kimber Kable Cat5e to transfer from the web to the disk. You should try it!




Jitter existing in tracks on a storage medium...at a standstill. Heck, that's even news to me!

DarqueKnight

One of the things I continually stress is the importance of the noise performance of cables and components. With regard to Ethernet cables, which are UTP (unshielded twisted pair), one would think that environmental noise would be of concern...and it is.

A recent IEEE paper by Leersum et al, "Ethernet Susceptibility to Electric Fast Transients", which was published in the Proceedings of the 2013 IEEE International Symposium on Electromagnetic Compatibility (EMC Europe 2013), Brugge, Belgium, September 2-6, 2013, provided some insight:

Abstract
The effect of Electric Fast Transients (EFT) phenomena in an Ethernet interface set-up is investigated in order to get more insight in coupling and interference mechanisms, robustness and susceptibility levels of a typical Ethernet installation on board of a naval vessel. It is shown that already a small EFT pulse is capable of disturbing or disrupting Ethernet communication at protocol level, which makes this not just a matter of signal integrity. It seems that the protocol is not designed to handle EFT phenomena in an efficient way. We focused on the quality of the interface, i.e. cables, connectors and feed-thoughs. While affordable high quality cable
is readily available, it is more difficult to find low cost and robust connectors without a large variability in performance for EMC, but to decouple data handling electronics from disturbing transients is of paramount importance for interference free data communication. As expected, screened cables help to mitigate the interference, but only when the screens are properly connected on both sides.

Conclusion
It is shown that already a small EFT pulse is capable of disturbing or disrupting Ethernet communication at protocol level, which makes this not just a matter of signal integrity. It seems that the protocol is not designed to handle EFT phenomena in an efficient way. We focused on the quality of the interface, i.e. cables, connectors and feed-thoughs. While affordable high quality cable is readily available, it is more difficult to find low cost and robust connectors without a large variability in performance for EMC, but to decouple data handling electronics from disturbing transients is of paramount importance for interference free data communication. As expected, screened cables help to mitigate the interference, but only when the screens are properly connected on both sides. Further research will focus on the coexistence of power lines and Ethernet cables in the same conduits and on the use of low cost connectors.


A couple of important points from the paper:

An earlier study* that focused on crosstalk showed that EFT bursts on nearby power lines are very effective in causing interference and loss of data on Ethernet cables. The impact of these disturbances, referred to as EFT, on the performance of an Ethernet connection is further investigated.

and

It is expected that digital circuits are more likely to exhibit non-linear failure characteristics compared to the gradual degradation of analogue signals with increasing noise.

*T. Wijnands, “Analysis Report: Crosstalk in Cables", Thales Nederland B.V., Internship Report, July 2008.

Discussion

From what I have read so far, it appears that, as with analog signals, cable quality matters with Ethernet's digital signals. It seems that jitter is not the only gremlin that can affect the integrity of Ethernet signals.

More later...

headrott

Thanks Ray for the confirmation of what we are discussing from a credible source. Cable quality does matter in Ethernet cables. There is more to it than simply "meeting spec.". As I and some others have said in the past. "Meeting Spec." is the minimum level needed in a cable to have it work correctly. If you meet and far exceed "spec.", you will have further reduced EFT effects (and other negative effects including jitter) on the digital signal running through the Ethernet cable.

F1nut

Madmax said it best, "Everything matters."

headrott

Indeed Jesse. Madmax got it right......

DarqueKnight

increasing-the-sound-quality-of-your-music-by-switching-from-cat-5-networking-to-cat-7

"I have spent a good while thinking about this one, and I have a background in networking, but I can’t work out why one Ethernet cable would sound different from another. In the case of speaker cables or HDMI, where the actual audio signal is transmitted, I can see how there might be a difference between cables. Likewise, I can see how the noisiness of the power source could play a big role. Packetized, error-checked digital data, though… I just don’t know.

Van Es really does seem adamant about a change in sound quality — but as an audiophile, though, he must surely know that double-blind testing must be carried out if he wants his findings to be taken seriously. He needs to be blindfolded and then have someone else change the cables, to see if he can still hear the difference. I’d also be very interested to see if Ethernet cables can affect the quality of compressed streams from Spotify, iTunes, or Rdio — or whether it’s just super-high-quality 16/44, 24/96, and 24/192 recordings that are impacted."

Blindfolds?

I thought the "blind" in "blind tests" was just a figure of speech.:rolleyes:

headrott

DarqueKnight wrote: »

I’d also be very interested to see if Ethernet cables can affect the quality of compressed streams from Spotify, iTunes, or Rdio — or whether it’s just super-high-quality 16/44, 24/96, and 24/192 recordings that are impacted."

Why was DSD (the highest resolution audio available today) not included in that list?

DarqueKnight wrote: »

Blindfolds?

I thought the "blind" in "blind tests" was just a figure of speech.:rolleyes:

They don't put "blind" in "blind tests" for nothing Ray!

WilliamM2

DarqueKnight wrote: »

Blindfolds?

I thought the "blind" in "blind tests" was just a figure of speech.:rolleyes:

So you found someone who doesn't understand blind testing...bravo!

If you were looking for people who don't understand blind testing, you really didn't need to leave this thread.

headrott wrote: »

They don't put "blind" in "blind tests" for nothing Ray!

See? Easy as that.

villian

DarqueKnight wrote: »

From what I have read so far, it appears that, as with analog signals, cable quality matters with Ethernet's digital signals. It seems that jitter is not the only gremlin that can affect the integrity of Ethernet signals.

More later...

The difference is that while every bit of interferrence effects the output quality of an analog signal, interferrence and degradation within a certain range doesn't effect the final product of packetized data being transported on an ethernet cable. You'll either get the signal correctly, or you won't. There is no grey area. Like Habanero said, once the amplitude of the signal being carried on a digital line hit's the demarcation point for a solid 0 or 1 it's done. Amplitude has no effect on volume, frequency, or anything else that it would normally have in an analog signal...it's simply a signaling method to determine 0's and 1's for perfect reproduction. If the MD5 hash matches the source MD5 hash then there is NO variance in the file being output that wasn't in the source file to begin with. They are 1:1 bit copies. Perfect copies. It's impossible to have additional "Data" within that signal that wasn't there at the get go. IF there is anything there that wasn't in the source file it's being introduced along the way by means other than the computer system or network components, and to make matters more interesting it's not actually part of the signal nor is it within it..althought it can creep along with it..around/outside/within the actual cable being used to transport the digital signal but not actually reproduced within it. Things like electrical interferrence, ground interferrence, magnetic interfrrence, etc...and not things like routers, switches, or fibre. But regardless those are just using the cable for a carrier, and are not within the digital signal being decoded. They are creeping from cable to cable to your receiver to your tv, to whatever they can to cause interferrence where they can. Do not confuse those resulting specks in your tv's image as interferrence caused by the cable itself, or the digital stream that is being played back. That noise is an overlay, nothing within.

phuz

Well, I see not much has changed around here. :P