Modérateurs: Staff Univers Casques, Staff Haute-Fidélité, Staff Juridique • Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 16 invités

Discussions sur le matériel Haute-Fidélité

CD gravé : dites moi que c'est un effet placebo !!

Message » 21 Aoû 2003 23:32

Merci pour ton explication mais je vais continuer avec nero puisque c'est parfait!
REGISTLSE
 
Messages: 1716
Inscription: 01 Juil 2003 23:21
Localisation: Le pays de Nougaro con... (31)
  • offline

Annonce

Message par Google » 21 Aoû 2003 23:32

Publicite

 
Encart supprimé pour les membres HCFR

Message » 22 Aoû 2003 0:15

ajds a écrit:
GBo a écrit:Vous précipitez pas, il y a gourrance: le jitter dont on parle dans ce thread et qui affecte les CD-R mal gravés, est le jitter de gravure, c'est à dire le manque de précision des positions des transitions pit<->land ou équivalent: le red book stipule 35 ns max, le lecteurs CD doivent s'y conformer. Il se peut d'ailleurs que certains drives arrivent quand même à démoduler correctement au delà de cette tolérance... mais ça n'a rien à voir avec le DAC :cry:
cdlt,
GBo.


Ben non, c'est toi qui te gourre, le signal d'horloge qui va alimenter le DAC est extrait directement du signal RF, qui, je le rappelle est le signal en sortie de diode laser, donc directement issu des bosses et trous crées par la gravure. Si ton signal RF est merdique, l'horloge extraite le sera aussi et donc tu auras du jitter au niveau du DAC.



Argggg! l'horloge qui est notée "crystal oscillator" sur mon schéma, et qui est aussi idéalement celle du convertisseur, est ultra-précise et complètement décorrélée du rythme récupéré du signal RF: ce dernier est très fluctuant, et sert de consigne pour le contrôle de la vitesse de rotation du moteur de façon à ce que le buffer, vidé au rythme de l'horloge maître, soit constamment rempli (ni trop, ni trop peu).
HEUREUSEMENT que le rythme récupéré du signal RF ne sert pas à clocker le DAC, t'imagines pas le pleurage :cry:

Revenons au jitter de gravure. Pour moi il ne peut jouer qu'au niveau du démodulateur voire étages de correction:
Ex. 1: imaginons un jitter de gravure faisant qu'à un moment un pit de 3T aura une longueur de 4T. Le démodulateur enverra au décodeur CIRC un symbole erroné. Le décodeur CIRC essaiera (et dans ce cas arrivera à corriger les bits. Merci Reed Solomon.
Fin.
Ex. 2: supposons maintenant un jitter de gravure s'amusant à transformer des pits de taille (n)T successivement en en (n+1)T puis en (n-1)T, sans arrêt. Le démodulateur n'arrêtera pas de donner des symboles erronés au CIRC, ce dernier s'apercevra des erreurs grâce à la redondance, et déclarera vraisemblablement forfait en passant la main à l'horrible unité d'Error Concealment.
Fin.
Ex. 3: imaginons maintenant que le jitter raccourcisse systématiquement legèrement tous les pits (vicieux): si le démodulateur arrive quand même à donner des données correctes (tres vicieux), c'est OK, le buffer ne débordera pas (cf. Charlie Chaplin dans les temps modernes), le mécanisme d'asservissement est là pour calmer la vitesse de rotation en conséquence! Merci Philips.
Fin.

Image


Mais quel rapport avec le DAC et son horloge impertubable? :o

cdlt,
GBo.
GBo
 
Messages: 3377
Inscription: 03 Avr 2002 2:00
Localisation: RP 78
  • offline

Message » 22 Aoû 2003 1:29

GBo a écrit:
Argggg! l'horloge qui est notée "crystal oscillator" sur mon schéma, et qui est aussi idéalement celle du convertisseur, est ultra-précise et complètement décorrélée du rythme récupéré du signal RF: ce dernier est très fluctuant, et sert de consigne pour le contrôle de la vitesse de rotation du moteur de façon à ce que le buffer, vidé au rythme de l'horloge maître, soit constamment rempli (ni trop, ni trop peu).
HEUREUSEMENT que le rythme récupéré du signal RF ne sert pas à clocker le DAC, t'imagines pas le pleurage :cry:


Ton shéma est bien mais incomplet. Le "timing generator" n'est pas détaillé. En fait, il s'agit d'une PLL sur le "recovered clock" du signal RF. Le "crystal oscillator" n'est autre que le quartz utilisé pour la PLL.
Au final, l'horloge générée est loin d'être "imperturbable" comme tu le crois, puisque c'est une fonction directe du signal RF lu et comme tu dis : "bonjour le pleurage" !, heureusement très atténué par le principe de PLL.

Un petit lien à lire sur la techno du CD :
http://www.ee.washington.edu/conselec/C ... 2/95x7.htm
The RF output is converted to a square wave, and then phase locks a clock with the period T



Revenons au jitter de gravure. Pour moi il ne peut jouer qu'au niveau du démodulateur voire étages de correction:
Ex. 1: imaginons un jitter de gravure faisant qu'à un moment un pit de 3T aura une longueur de 4T. Le démodulateur enverra au décodeur CIRC un symbole erroné. Le décodeur CIRC essaiera (et dans ce cas arrivera à corriger les bits. Merci Reed Solomon.
Fin.
Ex. 2: supposons maintenant un jitter de gravure s'amusant à transformer des pits de taille (n)T successivement en en (n+1)T puis en (n-1)T, sans arrêt. Le démodulateur n'arrêtera pas de donner des symboles erronés au CIRC, ce dernier s'apercevra des erreurs grâce à la redondance, et déclarera vraisemblablement forfait en passant la main à l'horrible unité d'Error Concealment.
Fin.
Ex. 3: imaginons maintenant que le jitter raccourcisse systématiquement legèrement tous les pits (vicieux): si le démodulateur arrive quand même à donner des données correctes (tres vicieux), c'est OK, le buffer ne débordera pas (cf. Charlie Chaplin dans les temps modernes), le mécanisme d'asservissement est là pour calmer la vitesse de rotation en conséquence! Merci Philips.
Fin.


Tu raisonne uniquement en termes de données, erreur fréquente, essaye donc plutot de voir ce qui se passe au niveau de l'horloge !

Mais quel rapport avec le DAC et son horloge impertubable? :o


Voir plus haut ;)
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 22 Aoû 2003 11:29

ajds a écrit:
Ton shéma est bien mais incomplet. Le "timing generator" n'est pas détaillé. En fait, il s'agit d'une PLL sur le "recovered clock" du signal RF. Le "crystal oscillator" n'est autre que le quartz utilisé pour la PLL.
Au final, l'horloge générée est loin d'être "imperturbable" comme tu le crois, puisque c'est une fonction directe du signal RF lu et comme tu dis : "bonjour le pleurage" !, heureusement très atténué par le principe de PLL.


Ah la la! re-confusion! :(
Bien sûr qu'il y a une PLL pour retrouver l'horloge RF, c'est vrai dans chaque système ou une clock est déduite d'un flot de données bruité ou sujet à fluctuation. Comment pourrait t'on d é m o d u l e r sans cela et donner un signal de consigne utilisable par le mécanisme de régulation par FIFO?
Et ce n'est pas parce que la PLL a un besoin d'un signal de référence temporelle que ce signal de référence ne sert qu'à: il sert aussi à la c o n v e r s i o n !

Voici le doc d'où j'ai tiré le schéma, il y a aussi du texte (sans blague!), dont j'ai traduit un paragraphe :
http://perso.club-internet.fr/gbotet/Chapter6_6.pdf

La mémoire du buffer du CIRC joue le rôle de dénsentrelaceur du CIRC proprement dit, et est utilisé pour la correction de la base de temps.
Si les données sont écrites en mémoire par le truchement de l'horloge récupérée du signal grâce à la PLL, puis lues au rythme dépendant de l'horloge quartz ("crystal oscillator") après qu'une certaine quantité de donnée ait été stockée, alors les données peuvent être correctement traitées avec un timing stable.
De cette façon, les pleurages et scintillements du signal audio numérique sont réduits à un niveau égal à la stabilité du "crystal oscillator".

:wink:
Lire aussi ce qu'il y a juste avant sur le diagramme de l'oeil et sur la distorsion pit...

Une seconde source? un composant peut-être?
http://www.st.com/stonline/books/pdf/docs/6151.pdf
Ce "Digital Servo & Decoder" banal contient entre autre, je cite:
CIRC (Cross Interleaving Read Solomon code) consists of 2 following blocks;
- Memory control for
M1: The FIFO memory to absorb Jitter of input signals
M2: The De-interleaving memory

Plus loin, ils confirment clairment que cette FIFO act as a time base corrector en évitant tout débordement ou vidage.
Comment veux tu faire sans deux horloges, une issue du niveau channel bit, moyennée par la PLL parce que fluctuante, et celle hyper stable destinée à fournir les échantillons à un rythme tip-top?

:wink:

Par contre tu ne fournis pas d'explications qui montrerait comment ton DAC magique pourrait recupérer une gigue de gravure supérieure à ce que spécifie le red book et que le démodulateur n'a pas su traiter lui-même. Encore une fois, je crois qu'on ne parle pas de la même gigue...

Au fait, le lien que tu donnes (et que j'ai déjà cité sur un autre post...) est vraiment très bon, mais il n'entre pas dans le détail du sujet dont on cause.

cdlt,
GBo.
GBo
 
Messages: 3377
Inscription: 03 Avr 2002 2:00
Localisation: RP 78
  • offline

Message » 22 Aoû 2003 16:14

GBo a écrit:Ah la la! re-confusion! :(
Bien sûr qu'il y a une PLL pour retrouver l'horloge RF, c'est vrai dans chaque système ou une clock est déduite d'un flot de données bruité ou sujet à fluctuation. Comment pourrait t'on d é m o d u l e r sans cela et donner un signal de consigne utilisable par le mécanisme de régulation par FIFO?
Et ce n'est pas parce que la PLL a un besoin d'un signal de référence temporelle que ce signal de référence ne sert qu'à: il sert aussi à la c o n v e r s i o n !

Voici le doc d'où j'ai tiré le schéma, il y a aussi du texte (sans blague!), dont j'ai traduit un paragraphe :
http://perso.club-internet.fr/gbotet/Chapter6_6.pdf

La mémoire du buffer du CIRC joue le rôle de dénsentrelaceur du CIRC proprement dit, et est utilisé pour la correction de la base de temps.
Si les données sont écrites en mémoire par le truchement de l'horloge récupérée du signal grâce à la PLL, puis lues au rythme dépendant de l'horloge quartz ("crystal oscillator") après qu'une certaine quantité de donnée ait été stockée, alors les données peuvent être correctement traitées avec un timing stable.
De cette façon, les pleurages et scintillements du signal audio numérique sont réduits à un niveau égal à la stabilité du "crystal oscillator".

:wink:
Lire aussi ce qu'il y a juste avant sur le diagramme de l'oeil et sur la distorsion pit...

Une seconde source? un composant peut-être?
http://www.st.com/stonline/books/pdf/docs/6151.pdf
Ce "Digital Servo & Decoder" banal contient entre autre, je cite:
CIRC (Cross Interleaving Read Solomon code) consists of 2 following blocks;
- Memory control for
M1: The FIFO memory to absorb Jitter of input signals
M2: The De-interleaving memory

Plus loin, ils confirment clairment que cette FIFO act as a time base corrector en évitant tout débordement ou vidage.


Ces textes disent simplement que le buffer sert, entre autres, à avoir une horloge propre en sortie, mais ca on le savait déjà.
Le problème reste que l'horloge finale est asservie a celle décodée au niveau du RF et donc il y a transmission de jitter. Le mécanisme de buffer permets d'obtenir quelque chose de potable en sortie au niveau timing, mais c'est tout.

Voici un article avec un schéma de principe complet du fonctionnement d'un lecteur CD :
http://www.tc.umn.edu/~erick205/Papers/3011Paper.pdf

Figure 1.
Tu noteras la flèche entre la boite "Clock Regeneration" (autrement dit extraction de l'horloge au niveau du signal RF" et "Synhronisation detection and timing".
On voit clairement ici, comment est générée l'horloge finale : a partir d'une PLL asservie à l'horloge issue du RF.

Comment veux tu faire sans deux horloges, une issue du niveau channel bit, moyennée par la PLL parce que fluctuante, et celle hyper stable destinée à fournir les échantillons à un rythme tip-top?


Ai je dit qu'il ne fallait pas 2 horloges ?

Depuis le début, j'arrête pas de dire que il y a bien 2 horloges, mais la deuxième est asservie à la premiere et ce n'est pas possible autrement.


Par contre tu ne fournis pas d'explications qui montrerait comment ton DAC magique pourrait recupérer une gigue de gravure supérieure à ce que spécifie le red book et que le démodulateur n'a pas su traiter lui-même. Encore une fois, je crois qu'on ne parle pas de la même gigue...


Tu parles du DAC1 ? Le mécanisme anti-jitter employé est radicalement différent de ce que l'on trouves ailleurs. Ils ne travaillent pas sur l'horloge elle même mais sur une modulation du taux de sur-echantillonnage (ou asservissement si l'on préfère). Une page explicative était présente sur leur site mais le lien ne fonctionne plus, ca va surement revenir.

Au fait, le lien que tu donnes (et que j'ai déjà cité sur un autre post...) est vraiment très bon, mais il n'entre pas dans le détail du sujet dont on cause.


Pour la partie que j'ai citée, si.
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 22 Aoû 2003 16:37

Un autre article encore plus détaillé, puisque le premier pourrait faire croire que le système de buffer est 100% efficace :

Page 8 du premier lien :
However, the careful engineer has beaten the marketeer to the punch by having the samples read off the disc into a RAM buffer. As the buffer becomes full, a local crystal oscillator can then “clock-out” the samples in a reliable manner, independent of the transport and reading mechanisms. This process is referred to as timebase correction and as stated before, any quality piece of equipment will implement it.


Le deuxième article :

http://www.iar-80.com/page59.html

CD players often do contain a FIFO buffer for what's called timebase correction, which does reduce the transport's high wow and flutter. But merely having and using a FIFO buffer is not sufficient, for it to be an effective firewall that can protect the timing integrity of your master clock from contamination. For a FIFO buffer to be an effective isolator, it is also necessary that the timing needs of the circuitry before the FIFO buffer not be tied in any way to the timing by the master clock of the circuitry after the FIFO buffer. This means that the timing of all the circuitry prior to the FIFO buffer must be totally asynchronous relative to the timing of all the circuitry after the FIFO buffer.
Even a slight degradation of the eye pattern quality could produce a few picoseconds' worth of temporal indeterminacy as to exactly when each and every zero crossing occurs. For instance, a slight reduction in CD surface reflectivity could slightly reduce the eye amplitude in the eye pattern, or could make the ramp slope at the zero crossing less vertically steep, which would make the precise time at which the zero crossing occurred less precisely determinate. Also, a slight reduction in reflectivity could worsen the signal to noise ratio, thereby making noise a larger contributory factor in degrading the determination of precisely when each zero crossing occurred. Slowly acting AGC circuits in the laser-reading photodetector amplifier might be able to approximately compensate for gross variations in eye pattern amplitude, but not slight variations, and they could not improve a degraded signal to noise ratio.
Thus, it at least makes sense that even slight degradation of eye pattern quality might adversely affect not the exactitude of the amplitude dimension of the final music waveform, but rather the exactitude of the time dimension of the final music waveform that your CD player is wholly responsible for creating. If the time dimension is not exact for each and every sample, then distortion of the music waveform results, and that distortion could well be the sonic degradation that we in fact hear, when the eye pattern is not at its best quality.


En gros et en Français, ca dit que pour être 100% efficace, le mécanisme de Timebase correction (buffer FIFO) doit être totalement décorellé de la source (horloge récupérée du signal RF) ce qui ne peut pas être le cas pour les raisons que j'ai déjà évoquées plus haut. Il faudrait pour cela lire préalablement l'intégralité du disque en RAM, puis envoyer les données au bon rythme : bonjour l'ergonomie si on est obligé d'attendre 15 minutes avant de pouvoir lire son CD :lol:

Enfin, pour finir, j'aime bien la conclusion de l'article :
If we add up everything we've learned in the four lessons above, it suddenly becomes clear that all kinds of CD tweaks can and indeed should be effective in making a sonic difference. Those who deride CD tweaks as snake oil are actually themselves the peddlers of improbability, or perhaps they naively subscribe to the popular misbelief that bits is bits, that digital is robust if not immune to external influences, and therefore nothing can possibly make any sonic difference. Now we know better. Digital is vulnerable, fragile, and as susceptible to analog external influences as analog ever was. Digital is as fertile a ground for inventive tweaking as the vinyl LP ever was, and legitimately so.
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 22 Aoû 2003 17:28

question bete: je previens :oops:

je vois vraiment pas ce qu'un dac vient faire dans une copie de CD :o
WhyHey
 
Messages: 13833
Inscription: 29 Avr 2002 12:31
Localisation: WhyCity
  • offline

Message » 22 Aoû 2003 17:31

WhyHey a écrit:je vois vraiment pas ce qu'un dac vient faire dans une copie de CD :o


La copie du CD engendre plus de jitter au niveau de la lecture et comme le jitter n'est important qu'au niveau de la conversion numérique/analogique, cela explique pourquoi on parle de DAC.
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 22 Aoû 2003 18:36

avec des fichiers mp3 en 192 kbits,et des cd pro et une gravure pas trop rapide,genre 4 - 8 * c'est en tout point pariel.
mcfly587
 
Messages: 12
Inscription: 17 Aoû 2003 21:33
  • offline

Message » 22 Aoû 2003 18:52

Ajds, tu sais que tu as un sacré culot? :wink:
Avec l'espèce de morphing que tu es en train de faire, tu vas voir tu vas finir par dire EXACTEMENT la même chose que moi... et en te l'APPROPRIANT en plus! :lol:

Comme c'est assez exemplaire, j'ai pris le temps de choisir quelques morceaux pour les forumeurs intéressés par la méthode, digne du premier générique de Thalassa, et après j'arrête promis!

1) Lorsque je décris que tous les lecteurs CD ont buffer CIRC, entre autres pour le désentrelacement, tu n'es pas d'accord:
ajds a écrit:oui, mais les buffers traditionnellement utilisés ne servent qu'a ca, il n'y a pas de re-synchronisation d'horloge et le schéma que tu affiche le montre très bien. Ces buffers sont en général très limités en taille, quelques Ko, car justement leur seul but est de permettre le décodage et la correction d'erreur.

Ensuite, j'amène les preuves du contraire en posant une doc de composant sur la table:
GBo a écrit:M1: The FIFO memory to absorb Jitter of input signals
M2: The De-interleaving memory[/i]

Et là, attention, début de retournement de veste :wink: :
ajds a écrit:Ces textes disent simplement que le buffer sert, entre autres, à avoir une horloge propre en sortie, mais ca on le savait déjà.

Ah bon, JE le savais déjà, non?
Puis en citant un article qui confirme mes propos plus clairement, fin du retournement:
ajds a écrit:CD players often do contain a FIFO buffer for what's called timebase correction, which does reduce the transport's high wow and flutter.

Eh oui, "Often do contain"! (ne pas confondre avec DON'T contain).
Je précise que le "reduce wow & flutter" signifie jusqu'à un point trés difficile à mesurer :wink: , merci le quartz.

--

2) quand je prétends que le jitter de gravure n'a aucun rapport avec le DAC, tu rétorques:
ajds a écrit:Ben non, c'est toi qui te gourre, le signal d'horloge qui va alimenter le DAC est extrait directement du signal RF

Erreur que tu confirmes en essayant de te rattraper aux branches de la pauvre PLL qui n'en demandait pas tant:
ajds a écrit:au final, l'horloge générée est loin d'être "imperturbable" comme tu le crois, puisque c'est une fonction directe du signal RF lu et comme tu dis : "bonjour le pleurage" !, heureusement très atténué par le principe de PLL.

Je te contredis en essayant d'expliquer au lecteur attentif que le rythme RF ("recovered clock" par PLL), c'est A GAUCHE du buffer (coté IN), alors que le rythme de sortie est A DROITE du buffer (coté OUT), et qu'ils ne sont pas de même nature, celui de sortie étant infinement plus précis que l'entrée pour éviter tout pleurage dans les limites de la précision du quartz bien sûr (alors que je rappelle que tu prétends toujours que c'est la PLL qui l'évite, ce pleurage).
Et maintenant tu cites un article avec lequel tu sembles tout à coup d'accord:
ajds a écrit:This means that the timing of all the circuitry prior to the FIFO buffer must be totally asynchronous relative to the timing of all the circuitry after the FIFO buffer.

Ah c'est bien asynchrone alors? Deuxième retournement de veste, deux.
Quand je pense qu'hier ce buffer ne servait qu'au décodage, d'après toi...

--

Et au final tu n'as toujours pas prouvé que, dans un contexte de jitter de gravure, sujet du moment pour un post sur le CD-R:
ajds a écrit:Il existe malgré tout, au moins un DAC totalement insensible au jitter, le Benchmark Media DAC1

...car, AMHA, tu confonds le jitter de gravure, avec le jitter numérique entre transport et DAC séparés, tout simplement!
Bah, maintenant que je te l'ai soufflé, tu finiras par dire que tu l'avais toujours dit, voire par me l'apprendre, qui sait? :D

cordialement,
GBo (pas rancunier).

PS: ajds, avant qu'on se fasse disputer pour encombrement de fil exponentiel, mon MP est dispo...mas pas de morphing STP! :wink:
GBo
 
Messages: 3377
Inscription: 03 Avr 2002 2:00
Localisation: RP 78
  • offline

Message » 22 Aoû 2003 18:58

mcfly587 a écrit:avec des fichiers mp3 en 192 kbits,et des cd pro et une gravure pas trop rapide,genre 4 - 8 * c'est en tout point pariel.

Le MP3 applique une compression avec perte, même à 320K.
Le fait qu'on entende pas la différence est un autre sujet, fort intéressant mais déjà débattu, et j'ai peur qu'on s'eloigne du sujet initial de ce post.
Tu peux raviver ce fil si tu veux:
http://www.homecinema-fr.com/forum/view ... ht=gbo+mp3
cdlt,
GBo.
GBo
 
Messages: 3377
Inscription: 03 Avr 2002 2:00
Localisation: RP 78
  • offline

Message » 22 Aoû 2003 19:35

GBo a écrit:Ajds, tu sais que tu as un sacré culot? :wink:
Avec l'espèce de morphing que tu es en train de faire, tu vas voir tu vas finir par dire EXACTEMENT la même chose que moi... et en te l'APPROPRIANT en plus! :lol:


ben voyons.

Comme c'est assez exemplaire, j'ai pris le temps de choisir quelques morceaux pour les forumeurs intéressés par la méthode, digne du premier générique de Thalassa, et après j'arrête promis!


Plutot qu'essayer de critiquer la personne (en l'occurence moi), je pense que ca serait bien plus utile à tous que de rester sur le débat et ne pas partir dans des attaques personnelles comme tu est en train de le faire. Relis la charte, elle n'est pas la pour rien.

1) Lorsque je décris que tous les lecteurs CD ont buffer CIRC, entre autres pour le désentrelacement, tu n'es pas d'accord:
ajds a écrit:oui, mais les buffers traditionnellement utilisés ne servent qu'a ca, il n'y a pas de re-synchronisation d'horloge et le schéma que tu affiche le montre très bien. Ces buffers sont en général très limités en taille, quelques Ko, car justement leur seul but est de permettre le décodage et la correction d'erreur.


Effectivement, je m'étais trompé la dessus, c'est grave docteur ?

Ensuite, j'amène les preuves du contraire en posant une doc de composant sur la table:
GBo a écrit:M1: The FIFO memory to absorb Jitter of input signals
M2: The De-interleaving memory[/i]

Et là, attention, début de retournement de veste :wink: :
ajds a écrit:Ces textes disent simplement que le buffer sert, entre autres, à avoir une horloge propre en sortie, mais ca on le savait déjà.


Ah bon, JE le savais déjà, non?


Si tu veut, il te reste la confusion entre horloge propre (jitter toujours présent) et horloge parfaite.

Puis en citant un article qui confirme mes propos plus clairement, fin du retournement:
ajds a écrit:CD players often do contain a FIFO buffer for what's called timebase correction, which does reduce the transport's high wow and flutter.

Eh oui, "Often do contain"! (ne pas confondre avec DON'T contain).
Je précise que le "reduce wow & flutter" signifie jusqu'à un point trés difficile à mesurer :wink: , merci le quartz.

--


Oui, j'ai bien compris et je ne confonds pas avec Don't, merci.

Par contre, ta traduction de de reduce wow & flutter est fausse, le texte dit "reduce the transport's high wow and flutter" ce qui traduit en français donne " réduit les fluctuations et le pleurage du drive", rien à voir avec ce que tu dit concernant la difficulté de mesure.

2) quand je prétends que le jitter de gravure n'a aucun rapport avec le DAC, tu rétorques:
ajds a écrit:Ben non, c'est toi qui te gourre, le signal d'horloge qui va alimenter le DAC est extrait directement du signal RF

Erreur que tu confirmes en essayant de te rattraper aux branches de la pauvre PLL qui n'en demandait pas tant:
ajds a écrit:au final, l'horloge générée est loin d'être "imperturbable" comme tu le crois, puisque c'est une fonction directe du signal RF lu et comme tu dis : "bonjour le pleurage" !, heureusement très atténué par le principe de PLL.


Je te contredis en essayant d'expliquer au lecteur attentif que le rythme RF ("recovered clock" par PLL), c'est A GAUCHE du buffer (coté IN), alors que le rythme de sortie est A DROITE du buffer (coté OUT), et qu'ils ne sont pas de même nature, celui de sortie étant infinement plus précis que l'entrée pour éviter tout pleurage dans les limites de la précision du quartz bien sûr (alors que je rappelle que tu prétends toujours que c'est la PLL qui l'évite, ce pleurage).



Je maintiens ce que j'ai dit :
"au final, l'horloge générée est loin d'être "imperturbable" comme tu le crois, puisque c'est une fonction directe du signal RF lu et comme tu dis : "bonjour le pleurage" !, heureusement très atténué par le principe de PLL."

La fonction dont je parle ici est tout simplement l'asservissement entre horloge source et cible. Par contre, pour la fin, j'aurais du effectivement dire "par le principe de FIFO et de PLL", pour être plus précis.

Et maintenant tu cites un article avec lequel tu sembles tout à coup d'accord:
ajds a écrit:This means that the timing of all the circuitry prior to the FIFO buffer must be [b]totally asynchronous relative to the timing of all the circuitry after the FIFO buffer.

Ah c'est bien asynchrone alors? Deuxième retournement de veste, deux.
Quand je pense qu'hier ce buffer ne servait qu'au décodage, d'après toi...



Tu va le rappeler combien de fois que je pensais que le buffer ne servait qu'au décodage ?
A priori c'est ma seule erreur, sur ce sujet, sur le fond il n'en reste pas moins que l'horloge de sortie est bel et bien dépendante du signal RF, ce que je défends depuis le début.

Et justement ce que tu n'as pas l'air de saisir c'est que le texte cité dit "FIFO buffer must be totally asynchronous" et non pas "FIFO buffer IS totally asynchronous". Le sens du texte est clairement de dire que le FIFO marcherait SI c'était totalement asynchrone, ce qui n'est pas le cas et c'est d'ailleurs pour ca que l'auteur en conclue que les drives restent sensibles a ce qui passe au niveau de la lecture même.
Donc je ne vois pas ou tu vois un retournement de veste ici, mais bon je te laisse fabuler.

Et au final tu n'as toujours pas prouvé que, dans un contexte de jitter de gravure, sujet du moment pour un post sur le CD-R:
ajds a écrit:Il existe malgré tout, au moins un DAC totalement insensible au jitter, le Benchmark Media DAC1

...car, AMHA, tu confonds le jitter de gravure, avec le jitter numérique entre transport et DAC séparés, tout simplement!
Bah, maintenant que je te l'ai soufflé, tu finiras par dire que tu l'avais toujours dit, voire par me l'apprendre, qui sait? :D


Je suis désolé mais je ne confonds rien du tout. Le jitter de gravure génère un signal RF de mauvaise qualité et donc génère du jitter tout court qui sera additionné a celui de toutes les autres étapes de traitement, transport y compris.

Quand à prouver que c'est le cas, je pense avoir avancé pas mal d'arguments et la discussion était plutot constructive jusqu'ici, jusqu'a ce que tu t'attache plus à essayer d'attaquer l'homme plutot que le débat ...

A court d'arguments peut être ?

Pour finir, je te signale que tu n'as toujours pas répondu sur le fond :
- comment, avec un débit de 1,5 MegaBits/s gérer un buffer de quelques Ko avec 2 horloges totalement asynchrones ?
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 22 Aoû 2003 19:58

Ajds, pour ma part j'arrête, car il y encore des erreurs; j'ai l'impression d'avoir déjà suffisamment donné d'explications, en plus d'avoir fait l'effort de chercher des documents de qualité.
Ne compte plus moi pour ce genre de joute à l'avenir, tes méthodes m'indisposent.
GBo.
GBo
 
Messages: 3377
Inscription: 03 Avr 2002 2:00
Localisation: RP 78
  • offline

Message » 22 Aoû 2003 20:08

GBo a écrit:Ajds, pour ma part j'arrête, car il y encore des erreurs; j'ai l'impression d'avoir déjà suffisamment donné d'explications, en plus d'avoir fait l'effort de chercher des documents de qualité.
Ne compte plus moi pour ce genre de joute à l'avenir, tes méthodes m'indisposent.
GBo.


Pas de problèmes, personne ne t'oblige à discuter avec moi et encore moins à m'apprécier, je te laisse donc à tes certitudes. L'essentiel c'est que tu en sois convaincu.

PS : il me semble aussi avoir fourni des documents de qualité.
ajds
 
Messages: 10779
Inscription: 02 Fév 2000 2:00
Localisation: Région Parisienne
  • offline

Message » 22 Aoû 2003 20:08

Restez cool les gars.

Je ne pourrais intervenir techniquement, car je suis largUé depuis 2 pages.

Mais vous partiez sur de bonnes bases. Continez-donc.
Restez techniques (un peu moins pour le betien que je suis) et surtout pas d'attaques personnelles.

Allez, on y va cool.
Henri ....La liberté de chacun s'arrête là où commence celle des autres....
Et au fait, t'as pensé a utiliser la fonction Rechercher ??? ;-)
Avatar de l’utilisateur
henri66
Membre d'Honneur
Membre d'Honneur
 
Messages: 36293
Inscription: 07 Déc 2001 2:00
Localisation: Toulouse (mais catalan d'origine...)



Retourner vers Discussions Générales

 
  • Articles en relation
    Dernier message