Apport réel d'un bon câble usb.

[zeroundemi]

...

[Fyper]

Ce qui me chiffonne dans les mesures allemandes (car elles servent d'appui pour la crédibilisation d'écoutes de cables Ethernet utilisés sous protocole Ethernet), c'est qu'elles sont faites dans le domaine analogique... qu'a-t-il à voir avec un signal informatique sous protocole ethernet ?

L'intégrité des données numériques n'est jamais remis en cause, li s'agit de voir s'il y a des "perturbations" en plus transmises par les câbles qui affecteraient le son de manière audible. Ces perturbations devraient être mesurable de façon analogique par un oscilloscope.
Non?

[dinosaure 77]

Je pense que oui. Reste après à interpréter si ces perturbations sont dues au seul changement de câble ou à une interaction plus globale du câble et son environnement...

[Denis31]

Ce qui me chiffonne dans les mesures allemandes (car elles servent d'appui pour la crédibilisation d'écoutes de cables Ethernet utilisés sous protocole Ethernet), c'est qu'elles sont faites dans le domaine analogique... qu'a-t-il à voir avec un signal informatique sous protocole ethernet ?

Tout signal est analogique. C'est l'"interprétation" qui en faite par les circuits d'émission/réception qui est numérique. Ainsi, si on s'intéresse aux erreurs de transmission de la ligne, il faut analyser ce signal avec les outils de l'analogique, c'est ce que fait MickeyCam.
Après, il se trouve qu'Ethernet utilise des protocoles qui incluent des mécanismes de correction des erreurs de transmission, par sommes de contrôles et ré-émission de paquets, en fonction de la "qualité de service" désirée par l'application. Ainsi UDP/IP amène la garantie de bon acheminement des données (si une donnée arrive, elle est correcte), qu'IP seul ne fournit pas. Encore mieux, TCP/IP garantit que toutes les données envoyées arrivent, et dans l'ordre. (bien entendu des erreurs sont toujours possibles mais ces protocoles garantissent qu'elles sont identifiées et "remontées" à qui de droit).
Les applications basées sur ces protocoles n'ont donc pas à se soucier directement des caractéristiques physiques de la liaison, qui ne peuvent influer que sur les performances des échanges de données, mais en aucun cas (*) sur leur intégrité.

L'influence directe d'une connexion Ethernet sur le "son" d'une installation, si la musique qui y passe est bien sous forme "Ethernet" (i-e pas un câble Ethernet utilisé dans une liaison propriétaire pour faire passer un protocole "audio" synchrone), se fera amha sous forme de "tout ou rien" c'est-à dire des "blancs" occasionnels si le débit de la liaison est si mauvais qu'il ne permette pas à l'application qui reçoit la musique de maintenir le niveau de son "buffer" d'entrée.
Une autre possibilité d'influence indirecte serait via un problème de CEM.

(*) Pour être complet, il faut dire que toute "garantie" repose sur une probabilité. De bout en bout, le protocole TCP/IP est considéré comme très fiable (je ne sais plus la probabilité mais autour de 10e-15 ne m'étonnerait pas) mais une erreur non détectée survient de temps en temps (fonction de la qualité des liaisons) lorsqu'on y fait passer d'énormes quantités de données (les quantités manipulées aujourd'hui dans les centres de données - et même chez certains particuliers - dépassent de loin ce que pouvaient imaginer les concepteur des mécanismes de contrôle, qui datent des années 70).

[frgirard]

sur HCFR un spécialiste de la multi-modalité des sens qui s'obstinait à penser que le test dit "en aveugle", en privant l'auditeur du sens de la vue, affectait forcément sa perception

le un c'est moi et le mot spécialiste est presque insultant ennoncé comme tu l'énnonce.

Je ai pu constater avec un certain malaise, mais sans etonnement, une certaine sélectivité dans les réactions en fonction de celui qui énnoncé.
Comme par exemple quand je disais que sur des signals simples je ne voyais pas de pb, quolibet et autres crachats, et puis quand c'est un des membres de ton estimable (propos sincéres) club, approbation et ploussoiement.

Les choses sont plus complexe que tu ne le crois.

Francois

[sebp]

Ce qui me chiffonne dans les mesures allemandes (car elles servent d'appui pour la crédibilisation d'écoutes de cables Ethernet utilisés sous protocole Ethernet), c'est qu'elles sont faites dans le domaine analogique... qu'a-t-il à voir avec un signal informatique sous protocole ethernet ?

Même s'il est effectivement curieux de trouver des mesures de retour sur perte négatives, je ne pense pas qu'il y ait matière à se focaliser sur les mesures

J'ai par contre l'impression que le premier article de STEREO se contentait très subjectivement d'écouter chanter les câbles Ethernet, et que leur second article se contente très objectivement de répondre à deux questions très basiques :
1. Tous les câbles Ethernet se valent-ils ?
2. Tous les câbles Ethernet vendus respectent-ils les normes auxquelles ils sont censés se plier ?
La réponse à ces deux questions est clairement négative, et ça ne m'étonne pas plus que ça, très peu des câbles vendus au grand public étant certifiés.

Il n'y a vraiment pas de quoi en faire tout un fromage (cf. mes stats Ethernet), sauf si l'objectif sous-entendu de ce deuxième test est de prouver que ces différences techniques entre câbles suffisent à elles seules à justifier le fait que le classement à l'écoute qui avait été réalisé dans le premier test était recevable.
Mon allemand faiblard ne me permet pas de l'assurer, mais je n'ai pas l'impression que STEREO s'y soit risqué, ni même mis en relation les résultats du second test avec ceux du premier.

De ce que j'en ai compris, ils se contentent plutôt d'affirmer (avec raison) qu'il y a encore du boulot à faire pour respecter les normes, en particulier au niveau des connecteurs (cause principale du reflux/retour sur perte), et qu'il y a un marché à saisir pour satisfaire les audiophiles.

zeroundemi, qui semble manier le germain avec plus d'aisance que moi pourra certainement confirmer ou infirmer mes propos.

[haskil]

Ce qui me chiffonne dans les mesures allemandes (car elles servent d'appui pour la crédibilisation d'écoutes de cables Ethernet utilisés sous protocole Ethernet), c'est qu'elles sont faites dans le domaine analogique... qu'a-t-il à voir avec un signal informatique sous protocole ethernet ?

Tout signal est analogique. C'est l'"interprétation" qui en faite par les circuits d'émission/réception qui est numérique. Ainsi, si on s'intéresse aux erreurs de transmission de la ligne, il faut analyser ce signal avec les outils de l'analogique, c'est ce que fait MickeyCam.
Après, il se trouve qu'Ethernet utilise des protocoles qui incluent des mécanismes de correction des erreurs de transmission, par sommes de contrôles et ré-émission de paquets, en fonction de la "qualité de service" désirée par l'application. Ainsi UDP/IP amène la garantie de bon acheminement des données (si une donnée arrive, elle est correcte), qu'IP seul ne fournit pas. Encore mieux, TCP/IP garantit que toutes les données envoyées arrivent, et dans l'ordre. (bien entendu des erreurs sont toujours possibles mais ces protocoles garantissent qu'elles sont identifiées et "remontées" à qui de droit).
Les applications basées sur ces protocoles n'ont donc pas à se soucier directement des caractéristiques physiques de la liaison, qui ne peuvent influer que sur les performances des échanges de données, mais en aucun cas (*) sur leur intégrité.

L'influence directe d'une connexion Ethernet sur le "son" d'une installation, si la musique qui y passe est bien sous forme "Ethernet" (i-e pas un câble Ethernet utilisé dans une liaison propriétaire pour faire passer un protocole "audio" synchrone), se fera amha sous forme de "tout ou rien" c'est-à dire des "blancs" occasionnels si le débit de la liaison est si mauvais qu'il ne permette pas à l'application qui reçoit la musique de maintenir le niveau de son "buffer" d'entrée.
Une autre possibilité d'influence indirecte serait via un problème de CEM.

(*) Pour être complet, il faut dire que toute "garantie" repose sur une probabilité. De bout en bout, le protocole TCP/IP est considéré comme très fiable (je ne sais plus la probabilité mais autour de 10e-15 ne m'étonnerait pas) mais une erreur non détectée survient de temps en temps (fonction de la qualité des liaisons) lorsqu'on y fait passer d'énormes quantités de données (les quantités manipulées aujourd'hui dans les centres de données - et même chez certains particuliers - dépassent de loin ce que pouvaient imaginer les concepteur des mécanismes de contrôle, qui datent des années 70).

ça je l'avais bien compris que tout signal est analogique et que c'est l'interprétation qui en est faite qui détermine sa nature numérique, mais pourquoi mesurer un cable Ethernet fait pour fonctionner, dans le protocole ethernet, sans le mesurer à l'intérieur même de ce protocole. C'est cela que je voulais dire.

Sinon, on extrapole la portée de mesures qui, bien que donnant des résultats patents, ne sont pas forcément utiles une fois le cable en situation : c'est à dire introduit dans une ligne qui fonctionne selon le protocole ethernet.

[haskil]

Ce qui me chiffonne dans les mesures allemandes (car elles servent d'appui pour la crédibilisation d'écoutes de cables Ethernet utilisés sous protocole Ethernet), c'est qu'elles sont faites dans le domaine analogique... qu'a-t-il à voir avec un signal informatique sous protocole ethernet ?

L'intégrité des données numériques n'est jamais remis en cause, li s'agit de voir s'il y a des "perturbations" en plus transmises par les câbles qui affecteraient le son de manière audible. Ces perturbations devraient être mesurable de façon analogique par un oscilloscope.
Non?

Ben je serais tenté de dire : non !

Car l'influence négative éventuelle du cable lui-même, montrée par les mesures, doit être effacée par le protocole lui même qui les voit et les intégre dans son mode de vérifications.

[haskil]

Ce qui me chiffonne dans les mesures allemandes (car elles servent d'appui pour la crédibilisation d'écoutes de cables Ethernet utilisés sous protocole Ethernet), c'est qu'elles sont faites dans le domaine analogique... qu'a-t-il à voir avec un signal informatique sous protocole ethernet ?

Même s'il est effectivement curieux de trouver des mesures de retour sur perte négatives, je ne pense pas qu'il y ait matière à se focaliser sur les mesures

J'ai par contre l'impression que le premier article de STEREO se contentait très subjectivement d'écouter chanter les câbles Ethernet, et que leur second article se contente très objectivement de répondre à deux questions très basiques :
1. Tous les câbles Ethernet se valent-ils ?
2. Tous les câbles Ethernet vendus respectent-ils les normes auxquelles ils sont censés se plier ?
La réponse à ces deux questions est clairement négative, et ça ne m'étonne pas plus que ça, très peu des câbles vendus au grand public étant certifiés.

Il n'y a vraiment pas de quoi en faire tout un fromage (cf. mes stats Ethernet), sauf si l'objectif sous-entendu de ce deuxième test est de prouver que ces différences techniques entre câbles suffisent à elles seules à justifier le fait que le classement à l'écoute qui avait été réalisé dans le premier test était recevable.
Mon allemand faiblard ne me permet pas de l'assurer, mais je n'ai pas l'impression que STEREO s'y soit risqué, ni même mis en relation les résultats du second test avec ceux du premier.

De ce que j'en ai compris, ils se contentent plutôt d'affirmer (avec raison) qu'il y a encore du boulot à faire pour respecter les normes, en particulier au niveau des connecteurs (cause principale du reflux/retour sur perte), et qu'il y a un marché à saisir pour satisfaire les audiophiles.

zeroundemi, qui semble manier le germain avec plus d'aisance que moi pourra certainement confirmer ou infirmer mes propos.

C'est précisément le problème que j'ai posé plusieurs fois... car c'est ainsi que les choses nous ont été présentées dans les débuts de cette discussion.

[zeroundemi]

...

[robob]

Bonjour,

Concernant la question de départ : "Apport réel d'un bon câble usb." La réponse est cela dépend du protocole de transfert utilisé.

La plupart des DAC utilisent des connections adaptatives (isochrone) : Les données sont envoyées par paquet, sans controle d'erreur et sans renvoi, l'horloge est déterminée par la source (le PC), le DAC est esclave. Dans ce cas non seulement la qualité et la longueur du cable sont importantes mais aussi la qualité de l'horloge du PC. La qualité du cable va influer sur la qualité de l'horloge et sur l'integrité des données.

Dans le cas des DAC dits asynchrones, là aussi il y a confusion : asynchrone ne veut pas dire "avec correction et renvoi d'erreur", mais seulement controle du timming de l'envoie des données par le recepteur. C'est en fait un transfert de données isochrone à point de controle asynchrone. En d'autre terme, la qualité du cable joue mais dans une moindre mesure car le DAC gérant la transmission des données et les bufferisant, il peut les recadencer parfaitement avec sa propre horloge. reste uniquement l'integrité des données : le recepteur peut vérifier celles-ci avec un controle d'erreur (CRC), si une donnée est érronée, le sample est perdu et sans doute que le sample précédent est répété. En réalité, avec un cable USB de base, le nombre d'erreurs est tellement négligeable que cela sera totalement inaudible. Mais il peut y en avoir, d'autant plus si on associe une connectique USB du PC un peu faiblarde (bus USB mal alimenté) et un cable USB de 15m de long passant derriere un micro-onde . Il y a donc toujours matiere à débat idiophile.

Le mode idéal serait le bulk mode : c'est le mode utilisé lorsque l'integrité des données est prioritaire mais pas la durée de transfert, par exemple pour les disques durs. Dans ce cas le receveur non seulement controle le timming, mais il controle aussi l'intégrité des données grace à un protocole de controle et de renvoie d'erreur. Dans ce cas seulement la qualité du cable et de la connectique USB n'a strictement aucune importance : les données mettrons simplement plus de temps à arriver. Dans le cas par exemple d'un transfert de flux audio PCM en 24 bits 192khz, le débits est tel que sur un cable de tres mauvaise qualité, on pourrait arriver à "vider" le buffer du recepteur se qui se traduirait sans doute par le plantage de l'appareil. Je crois, mais je ne l'ai pas encore vérifié, que les convertisseurs comme le Musiland Monitor ou la Hiface utilisent un mode de transfert bulk pour acheminer les données ... jusqu'à leur sortie SPDIF (derriere laquelle il faudra mettre un cable vers le DAC et se poser la question de la qualité de ce cable) .

Un test qui permettrait au niveau du recepteur de récupérer les données pour comparer le résultat entre deux cables, permettrait de vérifier l'integrité des données (le bit-perfect) dans un transfert isochrone, mais pas le bon cadencement de celle-ci. hors, dans un transfert de flux audio, le plus important à l'écoute n'est pas l'integrité des données mais leur cadencement au niveau du DAC. Même si on avait 10 erreurs par seconde lors du transfert avec un mauvais cable, cela représenterait 10 répétitions du dernier sample connu sur 44100 samples par seconde, traduit ensuite par le DAC en un signal analogique continu : sans aucun doute parfaitement inaudible.

[sebp]

Voilà le début du second article :

Als wir im Dezember 2008 über Klangunterschiede bei Netzwerkkabeln berichteten, waren die Reaktionen heftig: "Schwachsinn", schallte es uns der IT-Ecke entgegen - "Stimmt genau", schrieben uns Streaming-erfahrene Audiophile. Unter den aufmerksamen Lesern waren auch zwei Ingenieure, die beruflich mit Netzwerktechnik zu tun haben und der sache messtechnisch auf den Grund gehen wolten.

Ma traduction très libre (et certainement pas très juste) :

Quand nous rapportions en décembre 2008 les relations entre <<truc en rapport avec le volume et la séparation - diaphonie ?>> et câbles réseaux, les réactions furent animées : "Foutaises", entonnèrent les informaticiens - "Bien entendu, évidemment", écrivirent les audiophiles expérimentés. Parmi nos lecteurs attentifs figuraient également deux ingénieurs, qui ont proposé <<se sont proposé pour ?>> d'effectuer des mesures de façon professionnelle, avec les techniques adaptées au réseau, et que ces mesures techniques sauraient en expliquer les raisons.

Ça semble changer un peu la donne par rapport à ce que je pensais précédemment.
Si ce sont des lecteurs de la revue qui ont mené les tests, bonjour l'impartialité ...

[Denis31]

Un test qui permettrait au niveau du recepteur de récupérer les données pour comparer le résultat entre deux cables, permettrait de vérifier l'integrité des données (le bit-perfect) dans un transfert isochrone, mais pas le bon cadencement de celle-ci. hors, dans un transfert de flux audio, le plus important à l'écoute n'est pas l'integrité des données mais leur cadencement au niveau du DAC. Même si on avait 10 erreurs par seconde lors du transfert avec un mauvais cable, cela représenterait 10 répétitions du dernier sample connu sur 44100 samples par seconde, traduit ensuite par le DAC en un signal analogique continu : sans aucun doute parfaitement inaudible.

Tu dis toi-même plus haut qu'en isochrone les erreurs de transmission ne sont pas détectées. Si c'est bien le cas, il n'y a pas répétition du sample précédent mais apparition d'un sample "faux" dans le flux a convertir; et selon le type de musique et l'éloignement (aléatoire) de la valeur fausse par rapport à la bonne valeur, ça peut être plus ou moins facilement audible.

[Kaotech]

...Aveugle, pourquoi pas. Si cela s'entend, si c'est vraiment audible donc, cela sera les yeux ouverts comme fermés.

Un essai d'écoute dit "en aveugle" ou "en double aveugle" ne signifie pas que l'auditeur doive fermer les yeux !

[MickeyCam]

Bonjour,

mon interprétation était erronée car je me suis basé sur un tableau avec des explications en teuton auxquelles je n'y comprends rien.
dans mes mesures, j'ai constaté que le rouleau de câble avec le blindage en l'air et l'autre extrémité non connectée véhicule aussi du 50 Hz et les perturbations HF provenant de mon pilote distributeur de 10 MHz.
en mettant ce blindage à la masse, ça disparait.