Je fais des copies de sauvegarde d'anciens jeux vidéo avec CloneCD 5.3.3.0 sur mon ordinateur Windows 10 x64 avec un lecteur Samsung SH-S223L.
L'un d'eux est Hellfire pour PC (extension Diablo 1):
- Le disque a un
COMPACT disc DATA STORAGElogo - Numéro de série:
S0011770 - Code SID d'usine:
IFPI 1218 - CD-Master SID-Code:
IFPI L032 - Date de création du PVD ISO 9660:
1997-11-18 16:30:00.00
J'utilise la recommandation de profil redump.org CloneCD:
[CloneCD ReadPrefs]
ReadSubData=1
RegenerateData=0
ReadSubAudio=1
AbortOnReadError=0
FastErrorSkip=0
ReadSpeedData=8
ReadSpeedAudio=8
IntelligentBadSectorScan=1
SectorSkip=1
NoErrorReport=0
FirstSessionOnly=0
AudioQuality=3
Pour autant que je sache, le jeu n'a aucune protection, mais lorsque je vide le disque deux fois, je me retrouve avec différents fichiers de sous-canal ( .sub). Les fichiers .ccdet .imgsont identiques, seuls les .subdifférences, j'ai utilisé des sommes de contrôle SHA1 et un éditeur hexadécimal pour vérifier cela.
J'ai téléchargé deux .subvidages de fichiers ici .
Je dois mentionner que je possède deux copies de ce disque et que le comportement est identique avec les deux disques.
J'ai également vidé plusieurs autres supports de CD-ROM, parfois j'obtiens ce comportement parfois le sous-canal est cohérent entre les vidages.
Quelle est l'explication de ce comportement?
Éditer:
J'ai de nouveau vidé le même CD-ROM avec un lecteur Lite-On iH124-14 et je vois le même comportement ( .subfichiers différents ).
J'ai également vérifié le support pour les erreurs avec KProbe 2 et j'obtiens le résultat suivant:
Éditer:
Il semble que l'état du disque et / ou le manque de précision du lecteur ajouté au fait que le sous-canal ne dispose pas d'un mécanisme de contrôle des erreurs (sauf le canal Q) explique pourquoi j'obtiens des .subfichiers différents lorsque je vide le même support plusieurs fois.
Je dois mentionner que j'ai également obtenu un lecteur Plextor PX-712A et que j'ai réussi à obtenir des .subfichiers cohérents sur les vidages en utilisant Disc Image Creator . Ce logiciel utilise des 0xD8instructions au lieu d' 0xBEinstructions pour lire le disque, ce qui donne des images plus précises. Seuls quelques lecteurs (principalement Plextor) prennent en charge cette instruction.
Je possède également deux copies physiques de ce CD-ROM que je décharge (même numéro de série, mêmes codes IFPI et mêmes informations gravées au laser). Si je vide le même disque plusieurs fois avec Disc Image Creator, j'obtiens des .subfichiers cohérents , mais pas si je vide le premier disque puis le deuxième disque.
Je suppose que cela est lié aux conditions des médias car l'un d'eux a quelques rayures et plus d'erreurs C1 / C2.
Réponses:
Les différents formats de CD sont un peu impliqués et les spécifications officielles ("livre rouge" pour CD audio, "livre jaune" pour CD de données) ne sont pas librement disponibles. Mais vous pouvez trouver quelques détails dans les normes disponibles comme Ecma-130.
Le CD audio original (également appelé CD-DA) a été modelé sur le disque vinyle, ce qui signifie qu'il utilise également une piste en spirale de données audio continues (le DVD a ensuite utilisé des pistes circulaires). Entrelacé dans ces données audio d'une manière très complexe sont 8 sous-canaux (P à W), dont le sous-canal Q contient des informations de synchronisation (littéralement en minutes / secondes / fractions de secondes) et le numéro de piste actuel. Pour le but d'origine, cela suffisait: pour un jeu continu, l'objectif était juste légèrement ajusté pour suivre la piste. Pour chercher, l'objectif se déplacerait pendant le décodage du sous-canal Q jusqu'à ce que la bonne piste soit trouvée. Ce positionnement est un peu grossier, mais tout à fait suffisant pour écouter de la musique.
Aujourd'hui encore, de nombreux lecteurs de CD d'ordinateur ne peuvent pas positionner complètement l'objectif avec précision et synchroniser les circuits de décodage de sorte que la lecture des échantillons audio commence à une position exacte. C'est pourquoi de nombreux programmes d'extraction de CD ont un mode "paranoïa", où ils effectuent des lectures superposées et comparent les résultats pour ajuster cette "gigue". Dans le cadre du flux audio, le sous-canal est également sujet à la gigue, et c'est pourquoi vous obtenez différents fichiers de sous-canal lorsque vous extrayez sur un lecteur de CD qui ne peut pas se positionner avec précision.
Lorsque la spécification de CD de données (CD-ROM) a été développée pour étendre la spécification CD-DA, l'importance d'adresser et de lire les données avec précision a été reconnue, de sorte que la trame audio de 2352 octets a été subdivisée en 12 octets de synchronisation et 4 octets d'en-tête (pour l'adresse du secteur), laissant les 2336 octets restants pour les données et un niveau supplémentaire de correction d'erreur. En utilisant ce schéma, les secteurs peuvent être adressés exactement sans avoir à se fier uniquement aux informations du canal Q. Par conséquent, l'effet de gigue ne s'applique pas, vous obtenez toujours les mêmes données lorsque vous videz un CD-ROM, et aucune astuce supplémentaire dans le dumping n'est nécessaire.
Modifier avec plus de détails:
Selon Ecma-130 , les données sont brouillées par étapes: 24 octets constituent une trame F1 , les octets de 106 de ces trames sont répartis en 106 trames F2 , qui obtiennent 8 octets supplémentaires de correction d'erreur. Ces trames reçoivent à leur tour un octet supplémentaire ("octet de contrôle") pour en faire des cadres F3 . L'octet supplémentaire contient les informations de sous-canal (un sous-canal pour chaque position de bit). Un groupe de 98 trames F3 est appelé une section , et les 98 octets de contrôle associés contiennent deux octets de synchronisation et 96 octets de données réelles de sous-canal. Le sous-canal Q a en outre 16 bits de correction d'erreur CRC dans ces 96 bits.
L'idée derrière cela est de distribuer les données sur la surface du disque de telle manière que les rayures, la saleté, etc. n'affectent pas beaucoup de bits continus, de sorte que la correction d'erreur peut récupérer les données perdues tant que les rayures ne le sont pas. trop grand.
Par conséquent, le matériel du lecteur de CD doit lire une section complète après avoir repositionné l'objectif pour savoir où il se trouve dans le flux de données. Le désembrouillage des différentes étapes est effectué par le matériel, qui doit se synchroniser avec les 2 octets de synchronisation dans le flux d'octets de contrôle. Tous les modèles de lecteurs de CD ont besoin d'un temps différent pour se synchroniser par rapport aux autres modèles (vous pouvez le tester en lisant à partir de deux lecteurs différents, si vous en avez), selon la façon dont le matériel est implémenté. De plus, de nombreux modèles ne prennent pas toujours exactement le même temps pour se synchroniser, ils peuvent donc démarrer un peu tôt ou tard et produire les données désembrouillées pas toujours au même octet.
Ainsi, lorsque le programme d'extraction émet une
READ CDcommande (0xBE), il fournit une longueur de transfert et une adresse de début (ou plutôt, l'heure du canal Q). Le lecteur positionne l'objectif, désembrouille les images, extrait le canal Q, compare l'heure et lorsqu'il trouve l'heure correcte, il commence à transférer. Ce transfert ne commence pas toujours au même octet comme expliqué ci-dessus, donc le résultat de plusieursREAD CDcommandes peut être décalé les uns contre les autres. C'est pourquoi vous voyez différents fichiers de sous-canal de votre ripper.Selon le matériel et les circonstances où l'objectif est ajusté, il est plus ou moins aléatoire si le transfert démarre quelques échantillons plus tôt ou quelques échantillons plus tard. Ainsi, le seul motif que vous verrez dans les résultats est que les décalages sont un multiple de la longueur de transfert.
Certains modèles de disques ont en fait un matériel précis qui commencera toujours le transfert en même temps. La norme définit un bit dans la page de mode 0x2a ("Capacités CD / DVD et page d'état mécanique") qui indique si c'est le cas, mais l'expérience du monde réel montre que certains lecteurs prétendant être exacts ne le sont en fait pas. (Sous Linux, vous pouvez utiliser à
sg_modespartir dusg3-utilespackage pour lire les pages de mode, je ne sais pas quel outil utiliser sous Windows).la source
.subfichiers dans ma question. Je l'ai comparé avec un éditeur hexadécimal et vous avez raison, les données sont décalées, je ne trouve cependant aucun motif évident.sg_modes. J'ai0x2adans la section "Capacités MM et état mécanique (obsolète)". Je vais recevoir un nouveau lecteur Liteon demain et tester à nouveau pour voir si je reçois un sous-canal consisten à travers les décharges.Selon cet article Wikipedia
Cela suggère qu'il n'y a pas de correction d'erreur pour le sous-canal.
J'ai également trouvé une autre question ailleurs . Il s'agit de CD audio mais je pense que cela résout le bon problème:
La réponse là-bas:
Alors que dirkt peut avoir raison dans une autre réponse à votre question selon laquelle vous n'avez peut-être pas besoin de
.subfichiers, la réponse ne répond pas explicitement à votre question:Ma réponse: vous obtenez des
.subfichiers différents car les sous-canaux n'ont pas de correction d'erreur. Les erreurs de lecture sont corrigées (ou au moins détectées) lors de la lecture des données audio ou utilisateur, mais une erreur de lecture peut se produire telle quelle lorsqu'elle se produit au niveau du bit de sous-canal. Des erreurs particulières dues à des rayures ou à de la poussière peuvent apparaître au cours d'une session de lecture, ne pas apparaître au cours d'une autre, etc. - d'où des.subfichiers différents.Réponse développée pour répondre au commentaire:
Je soupçonne (malheureusement sans preuves tangibles) que différents CD peuvent avoir été fabriqués avec une qualité différente. Dans un cas où les sous-canaux n'ont pas d'importance, le disque de qualité inférieure peut toujours passer des tests de qualité conçus pour détecter uniquement l'incohérence des données. Ou cela peut être simplement une question probabiliste: un disque a ses points faibles (un bit qui donne des lectures incohérentes) où la correction d'erreurs peut le corriger; un autre arrive à l'avoir dans la zone sous-canal.
Un tel bit de sous-canal est suffisant pour vous donner différentes sommes de contrôle, tandis que même des milliers de bits "indécis" dans la zone de données utilisateur peuvent être corrigés en silence quand cela est nécessaire, si seulement ils sont suffisamment distribués, de sorte que l'algorithme de correction d'erreur traite pas trop - beaucoup d'entre eux à la fois.
Réponse développée en réaction aux résultats de KProbe 2.
Autant que je sache, les erreurs C1 sont autorisées (dans une certaine mesure) car elles sont corrigées silencieusement ( plus ici ). Cette correction fonctionne en raison des bits de correction d'erreur. Comme je l'ai déjà dit, les sous-canaux n'ont pas une telle redondance en général ( dirkt mentionne la correction d'erreur CRC du sous-canal Q mais cela ne change pas grand-chose dans ma conclusion). De plus, si l'erreur s'y produit, il n'y a aucun moyen de la connaître, sauf si vous savez à l'avance quelles sont les données de sous-canal correctes.
Vous avez donc eu un total de 1855 erreurs que vous connaissez. Répétez le test (sérieusement, faites-le!) Et vous pourriez avoir par exemple des erreurs 1790; ou 1892. Pourtant, la sortie corrigée est la même à chaque lecture.
S'il y a un bit de sous-canal pour 32 bits de données, je dis que vous avez probablement environ 1855/32 bits de sous-canal qui ont été lus avec une erreur non détectée. C'est environ 58 bits. Eh bien, presque, car grâce au CRC sous-canal Q, certaines de ces erreurs peuvent être détectées au moins. Étant donné que Q est l'un des huit sous-canaux, j'estime qu'il vous reste environ 50 bits erronés dans d'autres sous-canaux. La prochaine fois que vous lirez, vous obtiendrez peut-être quelques-uns de ces bits sans erreur et quelques nouvelles erreurs de sous-canal ailleurs. Vous obtiendrez donc un
.subfichier différent . Et vous ne saurez toujours pas avec certitude lesquels de ces bits ont été lus correctement la première ou la deuxième fois.la source
.subfichier cohérent sur plusieurs vidages. Je suis conscient que je n'ai pas besoin du sous-canal étant donné que le jeu n'est pas protégé, je pose cette question par curiosité technique :).