.AIFF ou .WAV, mes Rips sont Parfaits !

[pandème]

Le vinyle était névrogène, le ripping n'est pas mal non plus!

[pandème]

Et le sans perte? lossless et compagnie. je sais que le prix du téra baisse mais quand même, la réduction de place est intéressante. Pour ma part, sur un système correct je ne trouve aucune différence.

[Pio2001]

Bonjour Bruckner,

Les extractions que tu obtiens sont "offsettées" (décalées). Offset est le terme employé pour désigner le décalage de position sur les CD audio.

La première cause d'offset est le lecteur. Chaque mécanique utilise un point de référence différent pour débuter la lecture. Par exemple si le rip iTune a été réalisé sur un lecteur de CD-ROM Plextor, et le rip EAC sur un graveur de DVD Pioneer, au même ordre de lecture envoyé par le programme, l'ensemble mécanique + pilotes répondra par des données décalées. De même si les deux rips sont effectués par le même programme, mais en faisant appel aux deux lecteurs différents.

Mais dans ton cas, tu peux avoir un décalage sur la même mécanique en raison de l'usage d'EAC. EAC a été au départ conçu dans l'optique de faire des copies parfaites. Or, les graveurs comme les lecteurs gravent les données à une position plus ou moins arbitraire. Tous ces offsets entre mécaniques s'étalent en gros dans un intervalle d'un millier d'échantillons.
Andre Wiethoff, l'auteur d'EAC, voulait d'une part que lorsqu'il rippe un CD avec deux mécaniques, s'il en remplace une un jour, par exemple, pouvoir les comparer bit à bit, et surtout, il voulait que lorsqu'il grave un CDR, puis le relise, il obtienne le même wav, sans décalage.
Il s'est alors lancé dans un travail énorme de recensement, avec l'aide de ses utilisateurs, des "read offset" et "write offset" de tous les lecteurs et graveurs possibles, en se basant sur des CD de référence dont le démarrage était connu du logiciel, et en incluant un bouton de soumission des résultats en ligne dans EAC. Le travail a été incroyablement perturbé par le fait que les usines de CD, lorsqu'elles refont un pressage d'un album donné, décalent elles aussi les données ! Le décalage entre deux exemplaires d'un même CD peut atteindre 3000 échantillons. Or pour que la base de données grandisse vite, il fallait utiliser des CD populaires. Mais ce sont justement les CD les plus populaires qui présentent le plus de variations d'un pays à l'autre, d'une usine à l'autre, d'une réédition à l'autre, tandis que les plus petits pressages existent en une seule version.
La communaité d'utilisateurs, majoritairement des geeks et des nerds, a joué le jeu à fond, et une base de donnée a rapidement été construite.

Après quelques années, lorsque le mécanisme était bien rodé, Andre a inclus un wizard dans le package d'installation d'EAC. C'est-à-dire une série de boîtes de dialogue qui guident l'utiliateur lors de l'installation. Le programme, depuis lors, cherche à identifier le lecteur présent dans l'ordinateur et recherche son offset dans sa base de donnée. Je ne sais plus s'il le corrige automatiquement dans la version de base d'EAC ou s'il le fait seulement avec l'extension AccurateRip. Comme j'ai toujours utilisé cette extension, quand j'installe EAC, si le lecteur est dans sa base de donnée, l'offset est corrigé après la reconnaissance d'un CD de référence (pour vérifier si le constructeur du lecteur n'a pas changé de mécanique entre deux séries du même modèle), et si le lecteur n'est pas dans la base de données, après la reconnaissance de trois CD de référence concordants (pour être sûr de ne pas tomber sur des pressages d'offset différents de ceux de la base de données).

Par conséquent, ton EAC corrige peut-être automatiquement un offset de la mécanqiue, ce qu'iTunes ne sait pas faire.
Pour le savoir, dans EAC, en mode expert (les options sont cachées en mode beginner), va dans le menu EAC / Drive options, dans l'onglet offset/speed, et regarde si la case à cocher "Use read sample offset correction" est activée, et si justement tu n'as pas la valeur +6 renseignée dans le champ correspondant.

Si la valeur est présente, mais grisée, c'est probablement que tu as l'extension AccurateRip d'installée. Elle requiert impérativement la correction d'offset, car elle génère la signature CRC des plages extraites et la compare avec une base de donnée en ligne de toutes les signatures obtenues par les utilisateurs d'AccurateRip (extension qui se greffe également sur dbPowerAmp et quelques autres logiciels). Elle permet de vérifier qu'il n'y a pas un seul bit de différence entre le wav que tu obtiens, et celui obtenu par les autres utilisateurs dans le monde qui ont rippé la même plage sur le même CD.
S'il n'y a pas concordance, on ne peut rien en déduire. Cela peut être une erreur de lecture, mais c'est beaucoup plus probablement que les pressages ne concordent pas. S'il y a correspondance, il est quasiment certain que les deux rips sont parfaits. Mais pour cela, tous les utilisateurs d'AccurateRip doivent ripper avec le même offset exactement, et comme ils n'ont pas tous les mêmes mécaniques, la correction est forcée par le logiciel.

La raison pour laquelle les mécaniques ne lisent pas à partir du même endroit est obscure. On a eu dit que dans le passé, les mécaniques n'étaient pas fiables et lisaient en ne partant pas toujours du même endroit. J'ai constaté cela sur un graveur Yamaha 6416s, mais c'était exceptionnel. Dans la base de données de SatCP, sur plusieurs dizaines de drives, seuls un ou deux Yamaha présentaient un offset variable d'une lecture à l'autre du même CD.
On a dit aussi que la norme Red Book qui définit le format de donnée du CD n'était pas explicite sur ce point, et qu'il y avait une ambiguïté sur l'endroit exact où enregistrer le premier octet du premier échantillon. De sorte que les constructeurs, dans le doute, auraient chacun décidé de prendre plus ou moins d'avance lors de la lecture pour être sûrs de ne rien rater.
Il faut savoir que les données audio sont entrelacées dans le sillon du CD. Mélangées, en quelque sorte, afin, en cas de zone illisible, de disperser les données illisibles dans plusieurs blocs de données audio, chacun pouvant s'auto-réparer si un seul, voire deux octets sont manquants. Or, les index indiquant le démarrage de chaque page ne sont pas entrelacés, eux ! D'où une écriture assez folklorique dans le flux de donnée, avec un bloc de données contenant des informations audio en provenance d'emplacements divers, et portant l'indication "début de la plage 1". Toutefois, si on réfléchit un peu, il n'y a guère d'autre façon de procéder que de partir du principe que c'est le premier octet du bloc portant l'indication plage 1 qui appartient au premier échantillon du flux audio de la plage 1.

Il est amusant de noter que lorsqu'EAC corrige l'offset, ce n'est pas le résultat obtenu ! Andre n'avait en effet aucun moyen de savoir quelle mécanique donne une bonne référence. Quand il a conçu EAC, il a utilisé une autre astuce. Il avait trouvé des commandes logicielles qui ordonnent au lecteur de lire au-delà de la dernière plage, ou en amont de la première (option overread into lead-in / lead-out dans EAC). Il était obligé de faire cela pour ne perdre aucune donnée lorsqu'il corrige l'offset, et obtenir des copies parfaites. Pour la petite histoire, EAC a été le seul logiciel jamais capable d'utiliser des commandes d'overwrite lors de la gravure, pour graver au-delà de la dernière plage, ou en amont de la première (car rappelez-vous, les graveurs sont décalés aussi. Il faut donc corriger la gravure si on veut un résultat parfait, et ordonner au graveur de déborder de ce qu'il croît être le bout du CD si on ne veut pas tronquer un petit morceau. Rappelez-vous aussi qu'EAC permet non seulement de ripper, mais de graver). Et EAC ne les active effectivement que pour un antique modèle de graveur 4x de marque Teac.
Les mécaniques réagissent assez diversement à ces commandes d'overread. Certaines acceptent jusqu'à un certain point, puis renvoient des données nulles au-delà. Certaines ne renvoient que des données nulles.
Andre a donc utilisé un lecteur capable d'overread pour examiner les données audio qui se trouvent au-delà de la dernière plage. Il a fini par trouver des CD enregistrés depuis des sources analogiques, avec un bruit de fond visible en numérique, et qui s'arrêtait net un certain nombre d'échantillons après la fin de la dernière plage, ou du moins la fin de ce que son lecteur croyait être l'emplacement de la dernière plage. Il a cependant trouvé plusieurs emplacements différents selon la provenance des CD, ce qui tend à indiquer que les machines à graver les CD en usine ont de l'offset, elles aussi. Il a donc retenu comme valeur de référence celle qui revenait le plus souvent parmi ses CD.

On a su beaucoup plus tard que cette valeur n'était pas la bonne, et qu'elle était en fait à 30 échantillons de la valeur exacte. Plextor avait entre-temps sorti des graveurs de DVD sans offset, qui, par ironie du sort, se sont retrouvés affublés d'une read offset correction de +30 et d'un write offset de -30 dans EAC.
Mais Spoon disposait déjà de dizaines de milliers de CRC dans sa base de données AccurateRip. Il aurait fallu les détruire et reprendre la génération de la base à zéro avec le nouvel offset. De sorte qu'EAC est finalement resté réglé sur cet offset.

L'offset exact a été vérifié par une équipe de joyeux drilles du forum CD Freaks. Je ne sais plus s'ils ont utilisé le projet fou de l'un d'entre eux qui avait fabriqué un lecteur de CD virtuel en reliant la cellule optique d'un lecteur de CD à une carte d'acquisition haute fréquence, qui enregistrait les creux et les bosses du sillon, et avait écrit un logiciel qui effectuait tout le décodage NRZ, puis EFM, puis C1, puis C2 à partir de la succession de creux et de bosses. Il pouvait voir directement quelle donnée correspondait à l'index de plage 1 (en admettant que c'est le premier octet du bloc qui sert de référence). Ou s'ils ont eu accès aux encodeurs EFM des machines à graver dans les usines, et ont pu ainsi analyser l'emplacement des données pressées sur CD. Je me rappelle qu'ils ont travaillé sur les deux, mais je ne sais plus si leur vérification de l'offset absolu vient d'une des deux méthodes ou des deux.

[haskil]

Pio 2001 ecrit : Andre a donc utilisé un lecteur capable d'overread pour examiner les données audio qui se trouvent au-delà de la dernière plage. Il a fini par trouver des CD enregistrés depuis des sources analogiques, avec un bruit de fond visible en numérique, et qui s'arrêtait net un certain nombre d'échantillons après la fin de la dernière plage, ou du moins la fin de ce que son lecteur croyait être l'emplacement de la dernière plage. Il a cependant trouvé plusieurs emplacements différents selon la provenance des CD, ce qui tend à indiquer que les machines à graver les CD en usine ont de l'offset, elles aussi. Il a donc retenu comme valeur de référence celle qui revenait le plus souvent parmi ses CD.

Ils n'ont pas dû être bien difficiles à trouver ces CD d'origine analogique avec un bruit de fond visible : les rééditions de 78 tours sont légions !

Plus sérieusement : un grand merci pour ces propos remarquablement instructifs.

Ces histoires de débuts et fins de plages me titillent : quand je fais mes minutages à la maison en utilisant la fonction program de mon lecteur CD ou en regardant sous Itunes la durée des plages des CD que j'ai rippés.... pour certains CD j'ai des différences qui vont d'une seconde ou plusieurs secondes quand je vérifie les minutages dans les studios de la radio... pour d'autres... aucune différence...


PS Quand tu parles des machines à graver dans les usines : tu parles bien des machines servant à faire père et mère servant à produire les matrices servant à presser ensuite les CD. Car les CD du commerce ne sont pas gravés mais pressés.

[Igor Kirkwood]

+ 1 pour la qualité des renseignements de Pio .

En Mastering de CD L'offset n'est pas normé précisément, mais comprit entre une valeur maximum et une valeur minimum. Les choix peuvent varier d'un Studio de Mastering à l'autre, selon les rééditions.

Influence sur Rips ?

Igor Kirkwood.

[Pio2001]

Ils n'ont pas dû être bien difficiles à trouver ces CD d'origine analogique avec un bruit de fond visible : les rééditions de 78 tours sont légions !

Ce n'a pas été si simple. Moi aussi, j'avais fait cette démarche. J'avais trouvé 3 CD qui concordaient sur une troisième valeur, à 6 échantillons de celle d'Andre, et qui venaient tous de chez Sonopress.

Mais le problème, c'est que la majorité des CD ont le bruit de fond géré au mastering. Il est alors fondu dans du silence numérique avant la fin de la dernière plage. Pour les CD au bruit de fond assez discret pour avoir échappé au mastering, il se prolonge souvent loin au-delà de la dernière plage, dans le lead-out, qui est constitué de blocs de données audio.
Il faut tomber sur les rares CD où le bruit de fond a été coupé par la machine ou par l'outil de mastering pile en fin de plage.

En Mastering de CD L'offset n'est pas normé précisément, mais comprit entre une valeur maximum et une valeur minimum. Les choix peuvent varier d'un Studio de Mastering à l'autre, selon les rééditions.

Influence sur Rips ?

Tant que l'opérateur qui fait le mastering prévoit une petite marge d'un dixième de seconde au démarrage de chaque plage, cela ne pose aucun problème. Les offsets entre CD ne dépassent pas 4000 échantillons, et ceux entre mécaniques sont entre -600 et +1200 à peu près. Il y en a pas mal vers +600, selon la convention de signe d'Andre. Cela signifie qu'ils commencent la lecture juste avant la plage 1.
Il faut bien le faire à chaque plage, car l'offset reste le même entre le marqueur de plage 1 et les données de la plage 1, et entre le marqueur de plage 10 et les données de la plage 10.

Manger le début d'une plage, même d'un centième de seconde peut être gênant à l'écoute. Typiquement si c'est l'attaque d'une corde de guitare. Par contre en fin de dernière plage, aucun souci.

J'ai eu un cas de CD gravement offsetté. Il avait le marqueur de chaque plage une demi-seconde après le début de la musique. Très gênant quand on zappe d'une plage à l'autre (un CD du groupe AmGod). Et deux cas de CD sans offset sur les marqueurs de plage, sauf la première (Black - Wonderful Life, première édition, et Mike Oldfield - Discovery). La première note de la première plage était en partie gravée dans le pre-gap de la session audio, avant la première plage. Pour des raisons assez confuses et complexes de temps absolu, de numéro de secteur et de distinction entre gap et prégap, ces données, contrairement aux amusantes plages cachées qu'on peut écouter en faisait retour arrière sur le lecteur, étaient complètement inaccessibles. Je n'ai pu les extraire qu'en trafiquant le registre Windows pour imposer à EAC un "overread into lead-in" énorme, que son interface refuse (astuce donnée par Andre).

Donc si vous tombez un jour sur des mp3 ou des compilations avec Mike Oldfield - To France, ou Black - Wonderful Life, qui semblent tronqués au début, vous savez maintenant pourquoi

J'ai aussi noté que les plages cachées avant la plage 1, sur certains CD, n'étaient pas masterisées correctement (typiquement chez F Communications, le label de Laurent Garnier). L'audio, comme pour ces deux CD, démarre dans le prégap, qui est inaccessible. Le lecteur de salon "rembobine" en arrière jusqu'au milieu de la première note, mais pas jusqu'au début. J'ai dû utiliser la même astuce pour extraire l'intégralité des plages cachées.

[bruckner]

Pio2001 a écrit

Par conséquent, ton EAC corrige peut-être automatiquement un offset de la mécanqiue, ce qu'iTunes ne sait pas faire.
Pour le savoir, dans EAC, en mode expert (les options sont cachées en mode beginner), va dans le menu EAC / Drive options, dans l'onglet offset/speed, et regarde si la case à cocher "Use read sample offset correction" est activée, et si justement tu n'as pas la valeur +6 renseignée dans le champ correspondant.

Si la valeur est présente, mais grisée, c'est probablement que tu as l'extension AccurateRip d'installée.

Merci - Pio2001 - pour cette foule de précisions (même si le non spécialiste que je suis est parfois un peu largué...)

Je n'ai pas trouvé dans EAC la rubrique "Use read sample offset correction" mais "Use AccurateRip with this drive" coché

Si j'ai bien compris, le fait que iTunes ait correctement géré l'inter-plage résulte du fait que mon CD avait un "bon" offset. Si mon CD avait présenté un offset "exotique", alors seul EAC aurait été capable de gérer correctement les transitions entre plages. C'est bien ça ?

[Pio2001]

Non, la transition entre plages se fait toujours sans douleur. La configuration spéciale d'EAC explique le décalage de six échantillons que tu observes entre les deux programmes. C'est fait exprès.

[ToniOsX]

Salut,
je profite de ce post (qui vole un poil trop haut pour que je comprenne tout, mais chapeau bas les gars !) pour poser 2 questions "qui m'interrogent" :

1 - on lit souvent que certains graveurs sont meilleurs que d'autres (notamment Yam et Sony en graveur CD), mais pour un RIP parfait vaut-il mieux passer par un de ces graveurs ou un lecteur de portable par ex. fait-il aussi bien s'il est piloté par un bon soft (EAC sur PC ou MAX sur Mac par ex.) ?

2 - bruckner, tu laisse l'option d'extraction avec correction d'erreurs cochée sur iTunes ou pas ?
Là pareil, rien que sur ce post on lit tout et son contraire. Je dois dire que moi depuis des années j'utilise iTunes avec l'option cochée en me disant que si le CD est propre ben ça passe sans en avoir besoin, mais à priori il y en a qui trouvent des erreurs avec...

Enfin certains diraient qu'à ce niveau il faut laisser les drosophiles tranquilles, moi j'aime bien quand des gens poussent le truc jusqu'au bout comme vous.

[Pio2001]

1 - on lit souvent que certains graveurs sont meilleurs que d'autres (notamment Yam et Sony en graveur CD), mais pour un RIP parfait vaut-il mieux passer par un de ces graveurs ou un lecteur de portable par ex. fait-il aussi bien s'il est piloté par un bon soft (EAC sur PC ou MAX sur Mac par ex.) ?

Faut voir au cas par cas. Personnellement, après avoir suivi le développement d'EAC pendant quelques années, avec ses différents secure modes (C2, re-read), actuellement, j'ai bloqué mon lecteur en 8x pour ne pas trop l'user et avoir une lecture assez stable (j'en ai eu un qui se plantait à chaque fois qu'il dépassait 34x). Un vrai Plextor (certains Plextor sont des mécanques Pioneer) pour pouvoir faire des scan de bas niveau et contrôler la qualité de mes gravures avec Plextools Pro, pour pouvoir faire de l'overread dans tous les sens au besoin, et ne pas être bloqué par les anciens CD "protégés contre la copie".
J'utilise EAC, mais en burst mode au lieu de secure. J'utilise AccurateRip, et je fais l'extraction par plages en "test and copy", ce qui me permet de vérifier les CRC lorsque le CD n'est pas référencé dans AccurateRip.
Le test and copy en burst mode est plus fiable que le secure mode (attention, il ne faut pas tenir compte du message "extraction sans erreur", qui est faux, mais vérifier les CRC plage par plage). En contrepartie, s'il y a une erreur, il n'y a pas de correction. Il faut recommencer.

Donc pour moi, la mécanique n'a guère d'importance. Aucune n'est conçue pour être fiable. C'est la configuration du logiciel qui compte.

2 - bruckner, tu laisse l'option d'extraction avec correction d'erreurs cochée sur iTunes ou pas ?
Là pareil, rien que sur ce post on lit tout et son contraire.

Je ne connais pas cette option. Est-ce qu'elle est documentée par Apple ?

Par défaut, le mode standard de lecture audio avec correction d'erreur est un mode sans correction d'erreurs, mais avec recouvrement des bursts. Le programme lit 27 secteurs (environ un tiers de seconde d'audio), revient trois secteurs en arrière, lit 27 secteurs, compare les trois qui ont été lus deux fois, et ainsi de suite. Il contrôle trois secteurs tous les 24 afin de vérifier que chaque groupe de 27 qu'il lit commence bien là où le précédent se termine. Cela s'appelle aussi le "sync mode", ou correction de jitter, car en extraction audio, le fait de lire par erreur un groupe de 27 qui n'est pas collé au précédent est appelé jitter !
Rien à voir avec les vérifications soigneuses d'EAC ou les comparaisons d'AccurateRip, qui visent à détecter toute erreur lors de la lecture.

Pour les logiciels de gravure, comme Nero, l'option de correction d'erreur ne concerne que la lecture de CD-ROM. Elle est ignorée lors de la lecture de CD audio.

Les vrais algorithmes de correction d'erreur en audio sont rares. Leur développement est complexe en raison de la diversité des mécaniques existantes (le secure mode de Plextools pro ne fonctionne qu'avec certains modèles Plextor). On les appelle "secure mode" plutôt que "correction d'erreur", et il y a en général une page entière de pub à leur sujet sur le site du logiciel, tant les concepteurs y ont investi du temps, de l'argent, et en sont fiers.

[bruckner]

ToniOsX a écrit

2 - bruckner, tu laisses l'option d'extraction avec correction d'erreurs cochée sur iTunes ou pas ?
Là pareil, rien que sur ce post on lit tout et son contraire. Je dois dire que moi depuis des années j'utilise iTunes avec l'option cochée en me disant que si le CD est propre ben ça passe sans en avoir besoin, mais à priori il y en a qui trouvent des erreurs avec...

Non je n'ai pas activé la "correction d'erreur" de iTunes, car c'est ce qui est préconisé dans la notice du serveur musical que j'utilise pour écouter mes rips (La Rosita de chez Apertura).
Les raisons que tu donnes de l'utiliser quand même paraissent logiques, mais tout dépend de la façon dont iTunes est codé. J'ai par exemple constaté que le rip WAV d'iTunes et le rip AIF du même iTunes ne sonnaient pas tout à fait pareil ! (différence subtile mais différence objective - connue d'ailleurs par Apertura, qui conseille de ripper au format AIF). Comme on a pu démontrer par ailleurs (j'ai moi-même fait la manip) que les deux rips étaient rigoureusement identiques au niveau du signal, c'est que iTunes ne "traite" pas de la même façon la lecture des 2 sortes de rip (en l'occurrence la lecture des .WAV, comporte probablement un défaut).

[bruckner]

Pio2001 a écrit :

Non, la transition entre plages se fait toujours sans douleur.

L'intérêt de EAC (par rapport à iTunes) est donc de bien lire le début du CD ? Si donc il y a une bonne seconde de silence introductif (comme c'est le cas de la majorité des CD - du moins dans la musique dite Classique) alors EAC n'apporte rien de plus que iTunes. Ai-je bien compris ?

[ToniOsX]

2 - bruckner, tu laisse l'option d'extraction avec correction d'erreurs cochée sur iTunes ou pas ?
Là pareil, rien que sur ce post on lit tout et son contraire.

Je ne connais pas cette option. Est-ce qu'elle est documentée par Apple ?...

Je ne crois pas non, vu la "légendaire" transparence d'Apple en général...

En tout cas, pour l'avoir utilisé une fois sur un CD très rayé (d'un collègue, moi le jour où j'en ai un comme ça je le met au feu ), il y a bien une ≠ entre l'extraction avec la case cochée ou non :

- sans, c'est un peu plus rapide mais il y avait carrément des "sauts" dans les morceaux,
- avec, ce fut très long (parfois ça descendait à 0,2 X), plus de sauts mais certainement une "reconstruction au possible" des rayures les plus grosses, il y avait des artefacts audio assez audibles sur les morceaux...

Attention, il s'agissait d'un CD TRÈS rayé (gamins qui ont joué avec), que j'ai essayé de polir un peu au dentifrice, mais sans trop forcer.
Il va sans dire que moi je n'aurai gardé aucune des 2 versions...

Sur mes Cds (propres), ben je n'arrive pas à entendre de ≠, d'ailleurs l'extraction se fait (quasi) à la même vitesse case cochée ou non, c'est ce qui me fait penser que s'il n'en a pas besoin il continue sa vie sans ralentir.

Non je n'ai pas activé la "correction d'erreur" de iTunes, car c'est ce qui est préconisé dans la notice du serveur musical que j'utilise pour écouter mes rips (La Rosita de chez Apertura).

Donc il y a une notice (même si pas Apple) qui conseille de ne pas cocher...

Les raisons que tu donnes de l'utiliser quand même paraissent logiques, mais tout dépend de la façon dont iTunes est codé. J'ai par exemple constaté que le rip WAV d'iTunes et le rip AIF du même iTunes ne sonnaient pas tout à fait pareil ! (différence subtile mais différence objective - connue d'ailleurs par Apertura, qui conseille de ripper au format AIF).

Comme on a pu démontrer par ailleurs (j'ai moi-même fait la manip) que les deux rips étaient rigoureusement identiques au niveau du signal, c'est que iTunes ne "traite" pas de la même façon la lecture des 2 sortes de rip (en l'occurrence la lecture des .WAV, comporte probablement un défaut).

J'ai eu peur, 1/4 de seconde...

De toute façons sur Mac depuis de nombreuses années, j'ai pris l'habitude du AIFF pour tout ce qui concerne l'audio (pris en charge par tous les softs bien avant le WAVE, même si aujourd'hui ce n'est plus aussi discriminant).

[bruckner]

ToniOsX a écrit

J'ai eu peur, 1/4 de seconde...

Pandème avait bien raison d'écrire :

Le vinyle était névrogène, le ripping n'est pas mal non plus!

[Pio2001]

L'intérêt de EAC (par rapport à iTunes) est donc de bien lire le début du CD ? Si donc il y a une bonne seconde de silence introductif (comme c'est le cas de la majorité des CD - du moins dans la musique dite Classique) alors EAC n'apporte rien de plus que EAC. Ai-je bien compris ?

Non, mais rassure-toi, tu n'est pas le seul à t'être cassé les dents sur l'interprétation de la notion d'offset.

Deux points importants :

-Les lecteurs, ainsi que les CD eux-mêmes, fournissent des données arbitrairement décalées. Il est donc inutile de rechercher plus de "vérité" en respectant la norme officielle. Le résultat sur le rip lui-même sera de réduire la marge de manoeuvre initialement prévue par le lecteur en se décalant exprès en arrière pour prendre en compte le fait que les CD sont plus ou moins offsettés (cas d'un lecteur à "read offset correction" positive). Rien ne sert de vouloir à tout prix respecter au bit près les erreurs d'alignement du mastering. S'il y a une perfection à rechercher, il faut refaire soi-même le mastering en redécoupant les plages.

-Hors la consultation de la base de lecteurs d'EAC et d'Accuraterip, il n'existe aucun moyen pour un utilisateur (en dehors de l'oscilloscope connecté directement à la cellule photoélectrique de la mécanique) de se rendre compte de l'existence d'un offset sur son lecteur ou son CD par rapport à la norme d'alignement EAC / AR ou à la norme officielle. Seule la comparaison de deux mécanquies ou de deux CD peut lui indiquer que l'un des deux au moins présente un décalage, mais il n'existe absolument aucun moyen pour lui de savoir lequel est décalé par rapport aux normes, ou si les deux le sont.

EAC présente de mutliples intérêts. Le plus spécifique est l'existence de "secure modes" qui vérifient s'il y a des erreurs pendant le rip (et qui tentent de les corriger, mais il ne faut pas trop rêver de ce côté ci).
La correction d'offset présente les intérêts suivants :
-Les décalages de s'accumulent pas lors de copies de copies. Si un échantillon donné se trouve 100 positions à l'intérieur d'une plage, pas de risque qu'il finisse par glisser en arrière dans la plage précédente à force de se décaler quand le CD est copié.
-Le CRC d'une plage d'un pressage donné d'un CD donné (hors première et dernière plage) est le même sur tout ordinateur, toute mécanique. Ce qui permet l'existence d'AccurateRip, qui rassemble la signature numérique binaire de toutes les plages rippées par tous les utilisateurs du monde.