Drive bitperfect : Mac ou PC ? et quel player ?

[old100]

Ben... en utilisant les sorties SPDIF numériques prévues à cet effet

Il est entendu que le rip se fait par un autre ordi et le stockage sur un NAS ou autre

Ce n'est pas un drive, le fichier n'est pas sur le transporter.

[Seb.26]

Est-ce que quelqu'un pourrait réexpliquer ce que c'est exactement que le jitter et pourquoi l'usb est forcément jitter-free ?

En gros :

En SPDIF la liaison est unidirectionnelle et sans horloge, cela veut dire que les données sont "produites" par la source ( le drive ) et "consommées" par le DAC au fur et à mesure ... l'horloge de la sortie est donc issue du débit des données qui "entrent" ... donc de la qualité du drive ...

Si ton drive qui devrait produit un flux 16b@44100KHz produit en réalité un flux 16b@44116Hz, tu as une distorsion du signal original : il est plus aigu.

Hors, faire un signal d'horloge proche de la perfection est assez compliqué en électronique, c'est pour ça que tu mets pas mal d'euros dans ton DAC ( est-ce justifié ou non est une question à laquelle chacun doit répondre selon ses propres critères ... )

Utiliser une liaison USB (ou WIFI, Bluetooth, RS485, SPI, I2C ... toute liaison informatique ) permet d'annuler ce jitter durant la transmission car le signal n'est plus alors un flux temps réel, mais un flux asynchrone de données ... le DAC aura alors des données qu'il pourra convertir selon sa propre horloge, qui sera dépendante de la qualité de ses composants ... le flux à disposition du DAC sera donc parfait ( RIPP parfait, compression lossless, transmission parfaite ) au DAC de le convertir du mieux qu'il peut.

Le DAC devient le seul éventuel "maillon faible potentiel" de l'installation.

Autre question: je lis sans arrêt qu'il faut encoder ses cds et stocker les données sur le disque dur en flac par exemple.
Ok c'est pratique pour celui qui apprécie.
Mais otez moi un doute: on est pas censé entendre de différence entre le cd lu dans le pc et la version flac komêm?!?

Alors ... Tu eux entendre une différence éventuellement : le flac sera "meilleur" ( = plus proche de la réalité du CD que la lecture en live du CD lui même )

Pour une simple (mais bonne) raison : lorsque tu RIPP ton CD, si un secteur du CD est mal lu par le lecteur ( une vibration durant le balayage du laser du à un grattement du DD par exemple ) tu peux recommencer jusqu'à que ce soit parfait ( si l'état du CD le permet ) ... un drive ne peut pas le faire, car il doit "produire" en temps réel les données ...

Le RIPP permet d'y passer le temps qu'il faut ... une lecture synchrone se doit d'êtres en "temps réel" ...

Le flac est un format lossless ( = sans pertes ) ... cela veut dire qu'il ne touche pas aux données ... un peu comme un ZIP :
une photo BMP extraite d'un ZIP n'est pas moins jolie que la photo non ZIPPée !

[van.alstine]

Merci Seb,
j'ai déjà pigé quelque chose, tu es un fin pédagogue

[tobal]

Ca c'est quand il est bien luné .
Des fois il peut être très ... obscur.

Par exemple, demandez-lui qu'il vous parle des quartz des horloges et de leurs fréquences sur les cartes graphiques .

Non en fait, non, SURTOUT ne lui demandez pas.

@+,
Xavier.

[popette59]

Transfert de commande : énumération

envoi de paquet direct et par rafale
comprend 3 étapes : installation, données, état
garantie de livraison, renvoi du paquet erroné
Transfert d’interruption : souris, clavier

temps de retard garanti
détection d’erreur et nouvel essai
Ce ne sont pas des interruptions au sens informatique du terme, le périphérique doit attendre que l’hôte l’interroge avant de dire qu’il a une information urgente à transmettre.

Transfert isochrone : audio ou vidéo

pas de retard de données
pas de garantie de livraison
un accès garanti à la bande passante USB
C’est le transfert le plus efficace en matière de débit et du délai d’attente.

Transfert en Block : clé USB, appareil photo

détection d’erreur avec garantie de livraison
pas de temps d’attente minimum
pas de garantie de bande passante USB
Utilisé quand il faut transférer une grande quantité d’information pendant un temps relativement court.

Source : wikipédia

Il est dit dans plusieurs endroits du web que l'usb fonctionne en asynchrone pour les données informatiques, mais en isochrone pour les données audio et video, ce qui le rend sensible au jitter en audio et encore plus en video. Ton avis ? Je me trompe quelque part ?

[~Sypher~]

Autre question: je lis sans arrêt qu'il faut encoder ses cds et stocker les données sur le disque dur en flac par exemple.
Ok c'est pratique pour celui qui apprécie.
Mais otez moi un doute: on est pas censé entendre de différence entre le cd lu dans le pc et la version flac komêm?!?

Alors ... Tu eux entendre une différence éventuellement : le flac sera "meilleur" ( = plus proche de la réalité du CD que la lecture en live du CD lui même )

Pour une simple (mais bonne) raison : lorsque tu RIPP ton CD, si un secteur du CD est mal lu par le lecteur ( une vibration durant le balayage du laser du à un grattement du DD par exemple ) tu peux recommencer jusqu'à que ce soit parfait ( si l'état du CD le permet ) ... un drive ne peut pas le faire, car il doit "produire" en temps réel les données ...

Le RIPP permet d'y passer le temps qu'il faut ... une lecture synchrone se doit d'êtres en "temps réel" ...

Oui mais il y a le buffer, toujours activé par défaut dans les players je crois.
Sinon concernant les erreurs de lecture me suis amusé avec eac (aucun intérêt puisque les softs qu'on utilise en lecture intègrent déjà les mêmes fonctions d'extraction)
jamais vu la moindre erreur ni même son ombre.

[Seb.26]

Ca c'est quand il est bien luné .

... salo !

Il est dit dans plusieurs endroits du web que l'usb fonctionne en asynchrone pour les données informatiques, mais en isochrone pour les données audio et video, ce qui le rend sensible au jitter en audio et encore plus en video.
Ton avis ? Je me trompe quelque part ?

Oui et Non ... en effet, la norme USB dés ses débuts a prévue un mode de fonctionnement calqué sur la SPDIF, c-a-d sans aucune gestion de protocole/collision/erreur ... cela dans le but de limiter l'encapsulation des données pour augmenter le débit utile de la liaison ( moins de données ajoutées pour contrôler la transmission = plus de données utiles qui peuvent transiter à la place ) ...

Mais aujourd'hui, on est en 2008, l'USB est en v2.0 et offre des débits de 480Mbps ... un flux PCM stéréo 16b @44.1KHz = 44.1*32 = 1.4112Mbps ... soit 0.3% du débit d'un port USB 2.0 full speed ...

Donc si un constructeur décide d'utiliser le mode isochrone pour augmenter son débit utile : libre à lui ... mais personnellement, je penserai de son produit qu'il est mal conçu et inadapté à mon besoin ... donc j'en voudrais pas ...

C'est pas parce que l'USB offre cette possibilité que les constructeur doivent faire transiter du son dans le mode là ... c'est une possibilité, rien de plus ...

[haskil]

Pour en revenir à l'écran tactile.

J'ai commandé sur un site allemand un écran tactile 15" :
http://www.fine-buy.de/shop/index.php?cPath=3_30

Prix plus que correct (305 €port inclus). Service très pro et rapide (commandé le Dimance soir, reçu le Jeudi).

Et l'écran fonctionne très bien. Plus de photos et d'infos si vous le souhaitez.

Oui et un grand merci !

Alain

[Seb.26]

Oui mais il y a le buffer, toujours activé par défaut dans les players je crois.

Tout dépend du player, mais j'en connais pas beaucoup qui accèdent au niveau de données auquel accède EAC ...

Un CD audio est un CD dans lequel on a une couche pour permettre la lecture sans répétitions, il y a donc pas mal de données en plus ( CRC & co ) ...

Sur un CD, il y a 8 octets de correction pour 24 octets de données ... ces 8 octets permettent de masquer les éventuelles erreurs de lecture ... lorsque l'on accède au CD audio en tant que CD audio, le hard du lecteur fait tout seul ces corrections, EAC accède au CD brut : il n'interprète pas ces codes erreur, il les lit ... et tant qu'il a des erreurs, il recommence ... il va donc chercher à lire les bonnes valeurs, et pas les valeurs corrigées par interpolation, c'est dans ce sens qu'il est meilleur qu'un drive HdG ... remettre cela en cause revient à remettre en cause les drives HdG ( ce qui ne me dérange pas plus que ça )

Une fois de plus, l'utilité de cela est une question à laquelle chacun répond ...

[Edit] Correction des petites anneries et fautes ...

[haskil]

Pour EAC : ne pas oublier deux choses :

La première rappelée par Lansing : il faut étalonner le lecteur de l'ordinateur avec EAC pour que ce logiciel fonctionne au mieux : avec un CD normal et les erreurs C2 avec un CD rayé.

La seconde rappelée par Emmnuel Piat : il faut choisir son lecteur d'ordinateur parmi les modèles capables d'extraire avec le moins d'erreurs possibles. ça facilite le travail. J'ai perdu le lien du site où les lecteurs-graveurs sont testés de ce point de vue et tous, loin s'en faut, ne sont pas égaux devant cette tâche...


Pour le reste : tenons l'audiophilie loin de nous. La Haute fidélité, c'est mieux.

[Denis31]

Oui mais il y a le buffer, toujours activé par défaut dans les players je crois.

Tout dépend du player, mais j'en connais pas beaucoup qui accèdent au niveau de données auquel accède EAC ...

Un CD audio est un CD ROM dans lequel on ajoute un couche en plus pour permettre la lecture sans répétitions, il y a donc pas mal de données en plus ( CRC & co ) ... c'est pour ça qu'une piste audio gravée sur un CD et bien plus grosse sur le CD que le même fichier WAV gravé en mode ROM ...

Sur un CD, il y a 8 octets de correction pour 24 octets de données ... ces 8 octets permettent de masquer les éventuelles erreurs de lecture ... lorsque l'on accède au CD audio en tant que CD audio, le hard du lecteur fait tout seul ces corrections, EAC accède au CD en Mode CD-ROM : il n'interprète pas ces codes erreur, il les lit ... et tant qu'il a des erreurs, il recommence ...
OK, je comprends pourquoi Alain parle (dans un autre fil) de durées de rip différentes selon l'état du CD, avec EAC.

il va donc chercher à lire les bonnes valeurs, et pas les valeurs corrigées par interpolation, c'est dans ce sens qu'il est meilleur qu'un drive HdG ... remettre cela en cause revient à remettre en cause les drives HdG ( ce qui ne ma dérange pas plus que ça )
OK, mais en lecture "cd-audio" les erreurs c2 sont corrigées sans interpolation (utilisation des bits de parité), du moins jusqu'a une perte de piste de 2,47mm.
C'est pourquoi un lecteur cd (ou un rip "classique" pas EAC) sont également "bit-perfect" tant que le cd est en état "normal".


Une fois de plus, l'utilité de cela est une question à laquelle chacun répond ...

[haskil]

Le problème Denis, c'est que l'état normal... ne veut rien dire.... d'utile suite à un simple contrôle à l'oeil nu...


Car il n'est parfois pas visible à l'oeil nu : puisque deux CD neufs de référence identique (le même CD donc, même pochette, même pressage)... peuvent déboucher sur des temps d'extraction différents sur le même drive et le même logiciel d'extraction...


Je rippe beaucoup en ce moment et j'ai des surprises très étonnantes : des CD neufs (dépucelés pour l'occasion) rippés à une vitesse variant de X 1,5 à X 4... sur certains passages et n'allant pas au dela de X 6 ou 7 et un autre tout aussi neuf courant comme un lapin à x 20 et plus...


Je dois dire que cela me trouble beaucoup.

[Seb.26]

OK, je comprends pourquoi Alain parle (dans un autre fil) de durées de rip différentes selon l'état du CD, avec EAC.

Justement car si un secteur est corrompu, EAC va réessayer de le lire jusqu'a qu'il y arrive, ou alors qu'il renonce, il va également ralentir pour augmenter ses proba de réussir ... tout cela prend du temps ...

OK, mais en lecture "cd-audio" les erreurs c2 sont corrigées sans interpolation (utilisation des bits de parité), du moins jusqu'a une perte de piste de 2,47mm.
C'est pourquoi un lecteur cd (ou un rip "classique" pas EAC) sont également "bit-perfect" tant que le cd est en état "normal".

Un CD audio utilise du CIRC ( Cross Interleaved Reed-Solomon Code ) lui même composé d'un EDC (Error Detection Code) et d'un ECC (Error Correction Code).

Cela permet de tenter de corriger les erreurs ou au moins de les cacher ... ... mais elles sont probablement là ...

Personnellement, je me tiens le raisonnement suivant : ces erreurs ne sont pas bien graves !
... Mais puisque je peux les éviter simplement et sans aucune contrainte (de mon point de vu), pourquoi ne pas le faire ? ...

[Seb.26]

Le problème Denis, c'est que l'état normal... ne veut rien dire.... d'utile suite à un simple contrôle à l'oeil nu...

Car il n'est parfois pas visible à l'oeil nu : puisque deux CD neufs de référence identique (le même CD donc, même pochette, même pressage)... peuvent déboucher sur des temps d'extraction différents sur le même drive et le même logiciel d'extraction...

C'est pas un hasard si toutes ses corrections sont là : lire un CD n'est pas simple, on sait qu'il y aura forcement des erreurs ... même sur un CD neuf !

[leeperry]

Un CD audio est un CD dans lequel on a une couche pour permettre la lecture sans répétitions, il y a donc pas mal de données en plus ( CRC & co ) ...

Sur un CD, il y a 8 octets de correction pour 24 octets de données ... ces 8 octets permettent de masquer les éventuelles erreurs de lecture ...

d'autant que je sache y'a AUCUNE redondance sur un CDDA, et non plus aucune valeur de CRC....d'ou le gros souci pour les ripper convenablement.

http://www.google.com/search?hl=en&lr=& ... cy&spell=1
"CD-DA sectors have neither EDC redundancy nor ECC parity"

si le CDDA avait l'ECC des CDROM, on aurait pas de probleme