L'impédance des câbles 50 Ohms est-elle parfois de 75 Ohms?

[[Tonio]]

Ne pas multiplier les horloges, certes — mais dans mon type de branchement, la liaison drive/convertisseur (si c'estbie de ça qu'il s'agit? éviter les convertisseurs externes?) n'est pas contournable.

Cdlt

En effet ce n'est pas contournable dans ton cas. Mais dis toi bien que ce jitter, tu ne l'auras que sur un CD audio, pas sur un signal DTS ou AC3 . Donc si c'est pour une liaison purement HC, le mieux est de ne pas se prendre la tête .

[dub]

Ne pas multiplier les horloges, certes — mais dans mon type de branchement, la liaison drive/convertisseur (si c'estbie de ça qu'il s'agit? éviter les convertisseurs externes?) n'est pas contournable.

Cdlt

En effet ce n'est pas contournable dans ton cas. Mais dis toi bien que ce jitter, tu ne l'auras que sur un CD audio, pas sur un signal DTS ou AC3 . Donc si c'est pour une liaison purement HC, le mieux est de ne pas se prendre la tête .

Il n'y a justement pas que ça…
CD (en numérique) — MD (idem) — 24/48 (idem) — DVD (idem)
— SACD (en analogique) — DVD-A (idem) — 24/96 (idem)

Cdlt

[nico-]

Mais dub, je n'ai JAMAIS dit que les platines CD sonnaient toutes pareil! .

En revanche, il est pour moi clair et net qu'on peut lire un CD audio sans le moindre jitter, mais pour celà, il faut éviter de multiplier les horloges.

Un PC fait très bien celà .

Le jitter il y en a à tous les etages, le PC n' en est pas exempté.

[[Tonio]]

Le jitter il y en a à tous les etages, le PC n' en est pas exempté.

Disons qu'il n'y a pas de problème de synchro interhorloges. Donc oui, l'horloge en elle même n'est jamais complètement stable, mais il n'y a pas les problèmes habituels de liaison convertisseur/drive.

[Emile]

Mais dis toi bien que ce jitter, tu ne l'auras que sur un CD audio, pas sur un signal DTS ou AC3

Parbleu et pourquoi donc ?
Le jitter est un problème indépendant du type d'encodage,
et est inhérent à tout processus de transmission de signal numérique.

De plus :
Les données de type AC3 ou DTS (norme IEC61937) sont transportés par une liaison de type SPDIF ou IEC60958 , comme le CD audio ...
http://www.epanorama.net/documents/audio/spdif.html

. Evidemment et cependant, j'imagine que Dolby et DTS ont blindés leur format avec beaucoup de contrôles redondants.

[[Tonio]]

Mais dis toi bien que ce jitter, tu ne l'auras que sur un CD audio, pas sur un signal DTS ou AC3

Parbleu et pourquoi donc ?
Le jitter est un problème indépendant du type d'encodage,
et est inhérent à tout processus de transmission de signal numérique..

Reformulons : Le DTS et l'AC3 ne sont pas sensibles au Jitter de transmission numérique (tant qu'on reste dans le domaine du raisonnable) . Le phénomène existe mais a un effet totalement nul sur le résultat auditif.

[Emile]

Reformulons : Le DTS et l'AC3 ne sont pas sensibles au Jitter de transmission numérique (tant qu'on reste dans le domaine du raisonnable) . Le phénomène existe mais a un effet totalement nul sur le résultat auditif.

Pourquoi ? Sur quel(s) élément(s) bases-tu ton affirmation ?
C'est le sens de ma question

[dub]

Parbleu et pourquoi donc ?
Le jitter est un problème indépendant du type d'encodage,
et est inhérent à tout processus de transmission de signal numérique.

De plus :
Les données de type AC3 ou DTS (norme IEC61937) sont transportés par une liaison de type SPDIF ou IEC60958 , comme le CD audio ...

Ça c'est une info très intéressante! Merci Emile.

[[Tonio]]

Reformulons : Le DTS et l'AC3 ne sont pas sensibles au Jitter de transmission numérique (tant qu'on reste dans le domaine du raisonnable) . Le phénomène existe mais a un effet totalement nul sur le résultat auditif.

Pourquoi ? Sur quel(s) élément(s) bases-tu ton affirmation ?
C'est le sens de ma question

Tout simplement parce qu'un flux compressé par paquets (du streaming) est totalement intolérant aux erreurs de transmissions. Si tu perds des bits en route pour cause de jitter , la coupure est audible sous forme de craquement.

En flux compressé le récepteur se cale sur l'horloge de l'émetteur et décompresse des "paquets" de donnée assez conséquents. un raté=un paquet manquant=un crac. C'est très distinct, ça m'est arrivé avec une carte son qui marchait mal, je peux te dire que c'est inécoutable

[Emile]

+1 avec toi Tonio sur les conséquences.

i. mais le jitter est bien une cause de ces erreurs de transmission :
c'est ce point que je voulais souligner.

D'autre part, le récepteur ne peut se caler sur l'horloge de l'émetteur :
. physiquement déporté dans une liaison SPDIF : l'horloge et les données sont mélés ....
Il faut la retrouver !
. ou véhiculer ce signal d'horloge séparément des données, ce n'est pas le cas du SPDIF ....

ii. "streaming" signifie juste une diffusion en continu : ce qui est bien le cas pour la sortie digitale CD ... sur SPDIF,
comme pour la FM analogique.
Plus de détails http://www.telematica.polito.it/Telecom ... apter6.pdf

iii. En regardant rapidement le format des données sur un DVD video,
si la sensibilité à toute perturbation de transmission, jitter y compris, est moindre,
cela viendrait de ces éléments ? :
. contrôle des données redondants, bis repetita
. tous les frames video et donc "son" correspondants sont indicés : par le fameux Time Stamp
http://dvd.sourceforge.net/dvdinfo/pes-hdr.html

[[Tonio]]

+1 avec toi Tonio sur les conséquences.

i. mais le jitter est bien une cause de ces erreurs de transmission :
c'est ce point que je voulais souligner.

Certes. Mais une erreur de transmission ou de réception ne se traduit donc pas forcément par une erreur d'interprétation.

D'autre part, le récepteur ne peut se caler sur l'horloge de l'émetteur :
. physiquement déporté dans une liaison SPDIF : l'horloge et les données sont mélés ....
Il faut la retrouver !

. ou véhiculer ce signal d'horloge séparément des données, ce n'est pas le cas du SPDIF ....

ii. "streaming" signifie juste une diffusion en continu : ce qui est bien le cas pour la sortie digitale CD ... sur SPDIF,
comme pour la FM analogique.
Plus de détails http://www.telematica.polito.it/Telecom ... apter6.pdf

Oui en effet le CD sur SPDIF est un streaming.

iii. En regardant rapidement le format des données sur un DVD video,
si la sensibilité à toute perturbation de transmission, jitter y compris, est moindre,
cela viendrait de ces éléments ? :
. contrôle des données redondants, bis repetita
. tous les frames video et donc "son" correspondants sont indicés : par le fameux Time Stamp
http://dvd.sourceforge.net/dvdinfo/pes-hdr.html

Je ne suis pas certain de te suivre... le lien ici décrit le format du DVD vidéo(format des "paquets élémentaires", indexation des frames), mais ne parle nullement de liaison SPDIF, me trompe-je?

Dans le cas d'une lecture de DVD vidéo, il me semble que c'est la puce et le soft de décompression qui demandent les données au support et non l'inverse, comme dans le cas d'une liaison SPDIF donc je ne pense pas que ce soit tout à fait comparable.

[Emile]

a. SPDIF cf au-dessus :
Les données de type AC3 ou DTS (norme IEC61937) sont transportés par une liaison de type SPDIF ou IEC60958 , comme le CD audio ...

b. Le lecteur extrait les flux DTS ou AC3 du DVD video et le transmet par liaison SPDIF au décodeur : l'ampli HC.


c. Le format DTS ici : http://webapp.etsi.org/action/PU/200208 ... 10101p.pdf

i. Le §5.2 détaille les niveaux d'erreurs tolérés :

V Vital: The element is designed to change from frame to frame and its corruption is likely to lead to failure in
the decoding process and instability in decoded PCM outputs.

ACC Corruption could cause failure. Since the element usually does not change from frame to frame, the error may
be compensated for by a majority vote over consecutive frames.

NV Non-vital: corruption will degrade the quality of PCM outputs, but the degradation will be graceful.

[Emile]

+1 avec toi Tonio sur les conséquences.

i. mais le jitter est bien une cause de ces erreurs de transmission :
c'est ce point que je voulais souligner.

Certes. Mais une erreur de transmission ou de réception ne se traduit donc pas forcément par une erreur d'interprétation.

et donc ? Que veux-tu dire ?

[[Tonio]]

et donc ? Que veux-tu dire ?

Que dans certains cas, le jitter doit être maitrisé et dans d'autres, on s'en fiche .

[[Tonio]]

Un passage utile page 11 :

SYNC = 0x7ffe8001 V 32 bits
So the first decoding step is to search the input bit stream for SYNC. In order to reduce the probability of false synchronization, 6 bits after SYNC in the bit stream may be further checked, since they usually do not change for normal frames (they do carry useful information about frame structure). These 6 bits should be 0x3f (the binary 111111) for normal frames and are called synchronization word extension. Concatenating them with SYNC gives an extended
synchronization word (32 + 6 = 38 bits):
SYNC = 0x7ffe8001 + 0x3f for normal frame V 38 bits
which reduces the probability of false synchronization to 10 –7. In addition, the fact that SYNC occurs at a fixed interval further reduces the probability of false synchronization to almost zero.

The above search procedure shall be carried out only when the decoder is out of synchronization with the bit stream. After synchronization is established, the decoder should only check if SYNC = 0x7ffe8001 before it begins to decode a frame, because the 6 bits after SYNC may change for abnormal (termination) frames.
The SYNC word appears at the beginning of each DTS data frame in the stream. The length of the DTS data frame is fixed for the entire DTS stream and consequently the SYNC words occur at the fixed intervals within the stream. During the initial synchronization process the decoder shall calculate the distance between the two consecutive SYNC words. While in synchronization with the incoming DTS stream, the decoder shall only look for the SYNC word of a
new data frame at the calculated distance from the SYNC word of previously decoded data frame. If the SYNC word is found at the specified distance the decoder shall proceed with the decoding of the new data frame and if not the "out-ofsync" state shall be pronounced.
When DTS bit stream is stored in 16-bit words such as on CD, SYNC will be stored as 0x7ffe and 0x8001.

However, when DTS bit stream is viewed on an IBM PC platform, since the high byte and low byte are switched, SYNC will
appear like 0xfe7f and x0180.