audiofiele netwerkkabels van audioquest

[EJ]

Jazeker gesprecificeerd tot 1 GBPS maar in de praktijk zal bijv een Fluke meter uitwijzen dat dat 960MBPS is of 980 Mbps, die minitieuze verschillen zijn er tussen bepallde kabels, daar merk je als normale gebruiker natuurlijk niets van, maar die verschillen zijn er wel degelijk. Als een Cat 5/6/7 installatie gemaakt wordt krijg je doorgaans dat soort meetrapporten in handen en zie je de verwschillen merken doe je ze haast nooit.

Absoluut niet. Heb vrijwel dagelijks meetrapporten in mijn handen, maar wat jij zegt is absolute kolder. Die kabels mogen niet als gecertificeerd doorgaan. Ze voldoen NIET.

[CZ79]

OK als jij het zegt....

[Kjelt]

waarom gaat er niemand in op deze info?

Misschien omdat het niet relevant is? UDP of TCP/IP het streamerdevice zal toch moeten bufferen als ie HDMI gebruikt. Dit omdat HDMI geen retries heeft, het is gewoon eenweg pompen van data en als die data er niet is (omdat er corrupte packets zijn ontvangen of sommige packets helemaal niet zijn ontvangen) kan ie ook niet verstuurd worden.

Als dit zo'n probleem zou zijn met gewone TCP/IP kabels dan had hier het halve forum al mee volgestaan.
Nee de praktijk is dat niemand problemen heeft met het streamen van video of audio tot bepaalde bandbreedtes. Er zijn enkele issues met het streamen van full BD rips omdat dan alle raw data meegestuurd moet worden en dan zit je al gauw op 60 tot 70 Mb/s, als je dan een zwakke schakel hebt kan dat problemen geven maar dat staat volledig los van de kabels en zeker van het streamen van lossless audio met de belachelijk lage datarate van 1,4Mb/s.

[Kjelt]

Jazeker gesprecificeerd tot 1 GBPS maar in de praktijk zal bijv een Fluke meter uitwijzen dat dat 960MBPS is of 980 Mbps, die minitieuze verschillen zijn er tussen bepallde kabels, daar merk je als normale gebruiker natuurlijk niets van, maar die verschillen zijn er wel degelijk. Als een Cat 5/6/7 installatie gemaakt wordt krijg je doorgaans dat soort meetrapporten in handen en zie je de verwschillen merken doe je ze haast nooit.

Stel dat dit waar is dan zou dat nog geen wetenschappelijk verklaarbare invloed kunnen hebben op het streamen van lossless audio met 1,4Mbps want die kabels kunnen dat met gemak aan.

[CZ79]

Nee absoluut niet daarom is er niets van merkbaar, de streaming snelheden zijn een peuleschilletje voor kabels die tot 1Gbps gespecificeerd zijn.

[EJ]

waarom gaat er niemand in op deze info?

Ok dan.

Bij streaming wordt er veel gebruik gemaakt van udp niet tcp.
Indien het udp/ip is kan zo'n kabel inderdaad verschil geven tov een andere kabel, echter als je kijkt welke voorwaarden een cat5 al aan moet voldoen is de kans klein.
Bij tcp is er een controle dat een pakket toekomt indien niet is er een request om het pakket opnieuw te zenden, bij udp is deze controle er niet en kan een pakket dus gedropt zijn onderweg, dit zou je dus horen alsof er een stukje uit de muziek is gesneden.

Bij udp wordt de ontvanger geacht zelf voor retransmits te zorgen als die denkt dat er wat mist, en dat relevante data is. En nee, dan nog kan een kabel geen verschil geven, zie het aantal fysieke fouten, dat is in het algemeen 0. De kans op interne buffer overruns is bij die snelheden ook 0 (door hardware buffers).

En, zoals Kjelt en cz79 al aangeven, zijn de snelheden dermate laag dat het totaal irrelevant is.

Dit soort kabels moet je toch echt rangschikken bij 'geldklopperij'.

[chansig]

Deze kabel wel... Nu is het wachten op de groep mensen die zegt het wel te horen en niet alles is nog meetbaar..ach we kennen het wel.

Gr Hans

[EJ]

Hoezo? We hebben coned toch al een tijdje niet meer gezien hier?   

[Raphie]

waarom gaat er niemand in op deze info?

omdat de mensen die financieel belang hebben bij dit soort onzin de ballen verstand hebben van audio of ip protocollen en zich dus daarom vooral niet de vingers willen branden aan onjuiste technische statements, tevens kan dit alleen maar kritische wedervragen oproepen.

We kennen bijv. allemaal Snowmaster, zoek maar eens in de analen van het HTforum naar DENON tcpip kabel......   Die kabel was destijds 2x zo duur als z'n entry level DENON speler en door hem erin te hangen speelde de speler direct beter dan de 3 modellen erboven (zonder deze ooit gehoord te hebben)
een week later was z'n speler op reparatie omdat die al die maanden vol hossana verhalen naar een defect loopwerk zat te luisteren.

Let wel, dit is dezelfde persoon die FrankB wijs kan maken dat z'n nieuwe stroomkabel exact 20dgn, (je leest het goed, geen 3wkn maar 20dgn!!!) moet inspelen om op st(r)oom te komen......   met dat soort "liefhebbers" kan je toch geen inhoudelijke discussie voeren....

[katwax]

Misschien omdat het niet relevant is? UDP of TCP/IP het streamerdevice zal toch moeten bufferen als ie HDMI gebruikt. Dit omdat HDMI geen retries heeft, het is gewoon eenweg pompen van data en als die data er niet is (omdat er corrupte packets zijn ontvangen of sommige packets helemaal niet zijn ontvangen) kan ie ook niet verstuurd worden.

Het gaat hier om een utp kabel het feit dat hdmi ook geen controle heeft zoals udp maakt het des te belangrijker dat de utp wel degelijk goed is. Ik wil hiermee zeker niet zeggen dat deze kabel beter is dan een cat5 ofzo. Het kan echter wel zo zijn dat er minder packetloss zal optreden bij deze kabel.
Volgens mij is het dus zeer relevant of het udp of tcp, btw drop de ip want dit is echt niet relevant.

[Raphie]

Het gaat hier om een utp kabel het feit dat hdmi ook geen controle heeft zoals udp maakt het des te belangrijker dat de utp wel degelijk goed is. Ik wil hiermee zeker niet zeggen dat deze kabel beter is dan een cat5 ofzo. Het kan echter wel zo zijn dat er minder packetloss zal optreden bij deze kabel.
Volgens mij is het dus zeer relevant of het udp of tcp, btw drop de ip want dit is echt niet relevant.

packetloss?!? alleen bij een defecte kabel of switch toch zeker?

[katwax]

packetloss?!? alleen bij een defecte kabel of switch toch zeker?

Inderdaad, ik werk zelf al lange tijd voor firma's met datacenters en meeste packetloss komt van hardware zoals switch, firewalls, ...
Kabels komen we echter ook wel is tegen als oorzaak, zelfs bij nieuwe, maar dit is zeer beperkt en is opgelost door deze te vervangen door eenzelfde kabel

Voor alle duidelijkheid ik zal nooit beweren dat deze kabel zijn geld waard is.

[Raphie]

Zoals ik al zei, deze kabel zal naar verwachting z'n werk net zo goed doen als een standaard UTP kabel. (lees: de topologie laat geen upside voor "beter z'n werk doen" toe) 

[EJ]

Inderdaad, ik werk zelf al lange tijd voor firma's met datacenters en meeste packetloss komt van hardware zoals switch, firewalls, ...
Kabels komen we echter ook wel is tegen als oorzaak, zelfs bij nieuwe, maar dit is zeer beperkt en is opgelost door deze te vervangen door eenzelfde kabel

Voor alle duidelijkheid ik zal nooit beweren dat deze kabel zijn geld waard is.

Dat is een nieuwe voor mij: packetloss komt van switches... Dan is er maar 1 conclusie: je hebt een defecte switch. Firewall zou kunnen als je een prutsoplossing zoals packeteer hebt en/of perse traphic shaping wil doen. Anders is packetloss ook daar een no-go area, lees slecht geconfigureerd spul. Ook applicaties op udp niveau kunnen prima met packetloss omgaan als dat applicatief goed is opgelost.

Je utp of stp is goed of het is niet goed. Tussenvorm bestaat niet. Dure kabels zoals de genoemde is echt zonde van het geld.

[katwax]

Slechte config zou kunnen, ik ben geen network engineer dat is een andere afdeling.
Echter komt het vaker voor dat hardware zoals switch, firewall, ... (alles met software) dingen fout doet of met bepaalde zaken niet overweg kan.
Packeteer is inderdaad een goed voorbeeld van "rommel" hardware.

Bij een kabel is het inderdaad vaak alles of niets, echter komt een slechte kabel voor en hierbij zie je dan bv dat hij maar aan 10Mbits connect ipv 1Gbps.

[JackElenbaas]

Misschien wordt het tijd om dit verder te zetten in een computer forum

[EJ]

Waarom? Het is volstrekt ontopic.

[katwax]

Lijkt mij ook perfect ontopic te zijn, dit bewijst enkel maar dat er een hele boel van invloed kan zijn en dat een kabel het minste van je zorg zou moeten zijn 

[Raphie]

Sig

Misschien wordt het tijd om dit verder te zetten in een computer forum

[denoontje]

Even dit topic uit het stof halen, want ik ben getrieerd ;-)

op de av show in Veldhoven gevraagd bij Audioquest het verschil te laten horen tussen hun netwerkkabel cat 7 en een standaard kabel.
Gespeeld werd met een pioneer streamer. Muziek stond op een nas en in het netwerk zat een router/switch.

Ik moet zeggen ik hoorde wel verschil (natuurlijk maar 1 nummer gehoord en op die specifieke set)
Ondanks dat met niet aan de knoppen zat (ik ga er even vanuit dat we een 1 op 1 vergelijk deden, want als AQ dat niet doet vallen ze natuurlijk zelf ooit knetterhard door de mand) werd het geluid met de AQ wat harder, meer definitie en meer rust. Dat harder kan wellicht perceptie zijn door de andere veranderingen???

Ook Bob van wifimeda gaf aan in zijn lezing dat een cat 7 een verbetering in geluid zou geven (vandaar dat ik de vraag stelde bij AQ).

Nu niet direct naar de winkel voor mij, maar interesse is dus wel gewekt.

Bob gaf aan dat een cat 7 vanaf een switch ip voldoende zou zijn.
Stel je kies voor een AQ zou ik dat nog kunnen overwegen..heb nog een switch liggen en kosten voor een AQ vallen dan nog wel te overzien.
Anders wordt het evt 12 meter  :X
Wat ik ook evt kan doen is normale cat7 kopen (geen AQ) en dat direct of via een switch aansluiten.

Mijn linn ds is nu met cat5 direct aangesloten op de router (Nedgear) en op de netgear weer de Synology nas. en de pc's etc.


Zijn er mensen die al voor een soortgelijke keuze hebben gestaan en hebben mensen ervaring met cat 7 op een linn.
Zijn er mensen die een gewone cat7 hebben vergeleken met een uit de AQ serie --> cat 7 kun je nog steeds zelf krimpen volgens mij op afgeschermde stekker.
Zijn er meer mensen die op de Av een gelijksoortige waarneming hadden?

[bmateijsen]

Ja hoor, verschillende tests al gedaan op verschillende streamers met de kabels van AQ, maar ook met standaard CAT7.

[brickyfikkie]

toestellen die ethernetkabelverschillen laten horen, terwijl er geen timing over de kabel gaat gezien de masterclock in de streamer niet afhangt van enige clocking over ethernet, zijn per definitie slecht ontworpen omdat ze heel het OSI model aan hun laars lappen

slecht ontworpen streamers zoals aurender laten ook verschillen tussen wav/flac/aif horen, terwijl al deze codecs bitperfect en lossless zijn en na decodering van wav/flac/aif/monkey audio/wma lossless altijd dezelfde data oplevert, waarbij dan bvb de conclusie zou kunnen zijn dat aif beter is dan flac, terwijk dit louter afhankelijk is van de streamer

op andere slecht ontworpen streamers zou bvb flac beter kunnen klinken dan aiff

een goed ontworpen ethernetstreamer laat geen verschillen tussen netwerkkabels horen, en alle lossless formaten zijn equal

[denoontje]

Ja hoor, verschillende tests al gedaan op verschillende streamers met de kabels van AQ, maar ook met standaard CAT7.

en cat 7 vs AQ what was the verdict?

[Peerless Monster]

Ja hoor, verschillende tests al gedaan op verschillende streamers met de kabels van AQ, maar ook met standaard CAT7.

En en en?

[bmateijsen]

en cat 7 vs AQ what was the verdict?

Hetzelfde als wat je al hebt waargenomen....