Ich erstelle Sicherungskopien alter Videospiele mit CloneCD 5.3.3.0 auf meinem Windows 10 x64-Computer mit einem Samsung SH-S223L-Laufwerk.
Eines davon ist Hellfire für PC (Diablo 1-Erweiterung):
- Die Scheibe hat ein
COMPACT disc DATA STORAGELogo - Seriennummer:
S0011770 - Werks-SID-Code:
IFPI 1218 - CD-Master SID-Code:
IFPI L032 - ISO 9660 PVD-Erstellungsdatum:
1997-11-18 16:30:00.00
Ich verwende dasredump.orgCloneCD-Profil-Empfehlung:
[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
Soweit ich weiß, ist das Spiel nicht geschützt, aber wenn ich die CD zweimal dumpe, habe ich unterschiedliche Subchannel-Dateien ( .sub). Die .ccdund .imgDateien sind identisch, nur die .subunterscheiden sich. Ich habe SHA1-Prüfsummen und einen Hex-Editor verwendet, um dies zu überprüfen.
Ich habe zwei .subDateidumps hochgeladenHier.
Ich muss erwähnen, dass ich zwei Kopien dieser CD besitze und das Verhalten bei beiden CDs identisch ist.
Ich habe auch mehrere andere CD-ROM-Medien gesichert, manchmal tritt dieses Verhalten auf, manchmal ist der Subkanal über alle Sicherungen hinweg konsistent.
Was ist die Erklärung für dieses Verhalten?
Bearbeiten:
Ich habe dieselbe CD-ROM noch einmal mit einem Lite-On iH124-14-Laufwerk gedumpt und sehe das gleiche Verhalten (andere .subDateien).
Ich habe das Medium auch mit KProbe 2 auf Fehler überprüft und erhalte das folgende Ergebnis:
Bearbeiten:
Es scheint, dass der Zustand der Disc und/oder die mangelnde Präzision des Laufwerks zusammen mit der Tatsache, dass der Subkanal über keinen Fehlerkontrollmechanismus verfügt (außer dem Q-Kanal), erklären, warum ich unterschiedliche .subDateien erhalte, wenn ich dasselbe Medium mehrere Male dumpe.
Ich muss erwähnen, dass ich auch ein Plextor PX-712A-Laufwerk habe und es geschafft habe, konsistente .subDateien über Dumps hinweg zu erhalten, indem ichDisc-Image-Ersteller. Diese Software verwendet 0xD8Anweisungen anstelle von 0xBEAnweisungen, um die Disc zu lesen, was zu genaueren Bildern führt. Nur wenige Laufwerke (hauptsächlich Plextor) unterstützen diese Anweisung.
Außerdem besitze ich tatsächlich zwei physische Kopien dieser CD-ROM, die ich dumpe (dieselbe Seriennummer, dieselben IFPI-Codes und dieselben lasergravierten Informationen). Wenn ich dieselbe CD mehrmals mit Disc Image Creator dumpe, erhalte ich konsistente .subDateien, aber nicht, wenn ich die erste CD und dann die zweite CD dumpe.
Ich vermute, es hängt mit dem Zustand des Mediums zusammen, da eines davon ein paar Kratzer und mehr C1/C2-Fehler aufweist.
Antwort1
Die verschiedenen CD-Formate sind etwas kompliziert und die offiziellen Spezifikationen („Red Book“ für Audio-CD, „Yellow Book“ für Daten-CD) sind nicht frei verfügbar. Einige Details finden Sie jedoch in verfügbaren Standards wie Ecma-130.
Die ursprüngliche Audio-CD (auch CD-DA genannt) war der Vinyl-Schallplatte nachempfunden, d. h. sie verwendet ebenfalls eine spiralförmige Spur mit kontinuierlichen Audiodaten (die DVD verwendete später kreisförmige Spuren). In diese Audiodaten sind auf sehr komplexe Weise 8 Unterkanäle (P bis W) eingeflochten, von denen der Q-Unterkanal Zeitinformationen (buchstäblich in Minuten/Sekunden/Sekundenbruchteilen) und die aktuelle Titelnummer enthält. Für den ursprünglichen Zweck war dies ausreichend: Für die kontinuierliche Wiedergabe wurde die Linse nur leicht angepasst, um der Spur zu folgen. Zum Suchen bewegte sich die Linse beim Dekodieren des Q-Unterkanals, bis die richtige Spur gefunden war. Diese Positionierung ist etwas grob, aber zum Musikhören völlig ausreichend.
Noch heute können viele Computer-CD-Laufwerke die Linse nicht ganz genau positionieren und die Dekodierungsschaltung nicht synchronisieren, sodass das Lesen der Audio-Samples an einer exakten Position beginnt. Aus diesem Grund verfügen viele CD-Ripping-Programme über einen „Paranoia“-Modus, in dem sie überlappende Lesevorgänge durchführen und die Ergebnisse vergleichen, um dieses „Jitter“ auszugleichen. Als Teil des Audiostreams ist auch der Subkanal Jitter unterworfen, und deshalb erhalten Sie unterschiedliche Subkanaldateien, wenn Sie auf einem CD-Laufwerk rippen, das nicht genau positionieren kann.
Als die Daten-CD-Spezifikation (CD-ROM) als Erweiterung der CD-DA-Spezifikation entwickelt wurde, erkannte man, wie wichtig es ist, Daten genau zu adressieren und zu lesen. Daher wurde der Audio-Frame von 2352 Bytes in 12 Synchronisationsbytes und 4 Header-Bytes (für die Sektoradresse) unterteilt, sodass die restlichen 2336 Bytes für Daten und eine zusätzliche Ebene der Fehlerkorrektur übrig blieben. Mit diesem Schema können Sektoren genau adressiert werden, ohne sich nur auf die Q-Kanal-Informationen verlassen zu müssen. Daher tritt der Jitter-Effekt nicht auf, Sie erhalten beim Dumpen einer CD-ROM immer dieselben Daten und es ist keine zusätzliche Intelligenz beim Dumpen erforderlich.
Bearbeitenmit weiteren Details:
EntsprechendEcma-130werden die Daten stufenweise verschlüsselt: 24 Bytes ergeben einF1-Rahmen, die Bytes von 106 dieser Frames werden in 106F2-Rahmen, die 8 zusätzliche Bytes zur Fehlerkorrektur erhalten. Diese Frames erhalten wiederum jeweils ein zusätzliches Byte („Steuerbyte“), um sie inF3-Rahmen. Das zusätzliche Byte enthält die Subchannel-Informationen (ein Subchannel für jede Bitposition). Eine Gruppe von 98 F3-Frames wird alsAbschnitt, und die 98 zugehörigen Steuerbytes enthalten zwei Synchronisationsbytes und 96 Bytes echte Subkanaldaten. Der Q-Subkanal verfügt in diesen 96 Bits zusätzlich über 16 Bits CRC-Fehlerkorrektur.
Die Idee dahinter besteht darin, die Daten so auf der Oberfläche der Festplatte zu verteilen, dass Kratzer, Schmutz usw. nicht viele zusammenhängende Bits beeinträchtigen, sodass die Fehlerkorrektur die verlorenen Daten wiederherstellen kann, sofern die Kratzer nicht zu groß sind.
Folglich muss die Hardware des CD-Laufwerks nach der Neupositionierung der Linse einen vollständigen Abschnitt lesen, um herauszufinden, wo sie sich im Datenstrom befindet. Die Entschlüsselung der verschiedenen Stufen wird von der Hardware durchgeführt, die sich selbst mit den 2 Synchronisierungsbytes im Steuerbytestrom synchronisieren muss. Alle CD-Laufwerkmodelle benötigen im Vergleich zu anderen Modellen eine unterschiedliche Zeit zum Synchronisieren (Sie können dies testen, indem Sie von zwei verschiedenen Laufwerken lesen, falls Sie welche haben), je nachdem, wie die Hardware implementiert ist. Außerdem benötigen viele Modelle nicht immer genau dieselbe Zeit zum Synchronisieren, sodass sie etwas früher oder später beginnen und die entschlüsselten Daten nicht immer im selben Byte ausgeben können.
Wenn das Ripping-Programm also einen READ CD(0xBE)-Befehl ausgibt, liefert es eine Übertragungslänge und eine Startadresse (oder besser gesagt, die Q-Kanal-Zeit). Das Laufwerk positioniert das Objektiv, entschlüsselt die Frames, extrahiert den Q-Kanal, vergleicht die Zeit und beginnt mit der Übertragung, wenn es die richtige Zeit gefunden hat. Diese Übertragung beginnt nicht immer beim gleichen Byte, wie oben erklärt, daher READ CDkann das Ergebnis mehrerer Befehle gegeneinander verschoben sein. Aus diesem Grund sehen Sie von Ihrem Ripper unterschiedliche Subkanaldateien.
Je nach Hardware und den Umständen, unter denen das Objektiv eingestellt wird, ist es mehr oder weniger zufällig, ob die Übertragung einige Samples früher oder später beginnt. Das einzige Muster, das Sie in den Ergebnissen sehen werden, ist also, dass die Verschiebungen ein Vielfaches der Übertragungslänge betragen.
Einige Laufwerksmodelle verfügen tatsächlich über präzise Hardware, die die Übertragung immer zur gleichen Zeit startet. Der Standard definiert ein Bit in der Modusseite 0x2a („CD/DVD Capabilities and Mechanical Status Page“), das angibt, ob dies der Fall ist, aber die Praxis zeigt, dass einige Laufwerke, die behaupten, exakt zu sein, dies in Wirklichkeit nicht sind. (Unter Linux können Sie sg_modesaus dem sg3-utilesPaket verwenden, um die Modusseiten zu lesen, ich weiß nicht, welches Tool ich unter Windows verwenden soll).
Antwort2
Entsprechenddieser Wikipedia-Artikel
Ein Frame besteht aus 33 Bytes, davon sind 24 Bytes Audio- bzw. Benutzerdaten, acht Bytes Fehlerkorrektur (CIRC-generiert) und ein Byte ist für den Subcode vorgesehen.
Dies lässt darauf schließen, dass für den Unterkanal keine Fehlerkorrektur vorhanden ist.
Ich habe auch gefundennoch eine Frage woanders. Es geht um Audio-CDs, aber ich denke, es spricht das richtige Thema an:
Ich kann nur sagen, dass es mir nie gelungen ist, zwei identische Subchannel-Messwerte (*.SUB-Datei) zu erhalten, wenn ich von derselben CD-DA/CD-TEXT lese. Ist das beim Lesen im RAW-Modus normal, weil die Daten nicht korrigiert werden, weil das CD-DA/CD-TEXT-Format nicht in allen Subchannels EDC/ECC enthält?
Die Antwort dort:
Nur Audiodaten werden einer Reed-Solomon-Kodierung unterzogen (C1 und C2). Subcode-Kanaldaten (Kanäle P...W) unterliegen weder Interleaving noch Fehlerschutz.
Währenddirktkann richtig sein innoch eine Antwort auf deine Fragedass Sie möglicherweise keine .subDateien benötigen, die Antwort geht nicht explizit auf Ihre Frage ein:
Was ist die Erklärung für dieses Verhalten?
Meine Antwort: Sie erhalten unterschiedliche .subDateien, da Subchannels keine Fehlerkorrektur haben. Lesefehler werden beim Lesen von Audio- oder Benutzerdaten korrigiert (oder zumindest erkannt), aber ein Lesefehler kann unverändert bleiben, wenn er am Subchannel-Bit auftritt. Bestimmte Fehler aufgrund von Kratzern oder Staub können während einer Lesesitzung auftreten, während einer anderen nicht usw. – daher die .subunterschiedlichen Dateien.
Antwort erweitert, um auf den Kommentar einzugehen:
Ich habe zwei Kopien dieser CD, eine davon in ausgezeichnetem Zustand (keine sichtbaren Kratzer) und das Verhalten ist immer noch das gleiche. Ich habe auch andere ältere Spiele-CD-ROMs in schlechterem Zustand, die
.subüber mehrere Dumps hinweg konsistente Dateien aufweisen.
Ich vermute (leider ohne handfeste Beweise), dass verschiedene CDs mit unterschiedlicher Qualität hergestellt wurden. In einem Fall, in dem Subkanäle keine Rolle spielen, besteht die CD mit der niedrigeren Qualität möglicherweise trotzdem Qualitätstests, die nur zur Erkennung von Dateninkonsistenzen entwickelt wurden. Oder es handelt sich einfach um eine Wahrscheinlichkeitssache: Eine CD hat ihre Schwachstelle(n) (ein Bit, das inkonsistente Messwerte liefert), wo sie durch eine Fehlerkorrektur behoben werden kann; eine andere hat sie zufällig im Subkanalbereich.
Ein solches Subchannel-Bit reicht aus, um unterschiedliche Prüfsummen zu erhalten, während sogar Tausende „unentschiedene“ Bits im Benutzerdatenbereich bei Bedarf stillschweigend korrigiert werden können, sofern sie nur ausreichend verteilt sind, sodass der Fehlerkorrekturalgorithmus nicht zu viele davon gleichzeitig verarbeiten muss.
Antwort als Reaktion auf die Ergebnisse von KProbe 2 erweitert.
Soweit ich weiß, sind C1-Fehler (bis zu einem gewissen Grad) zulässig, da sie stillschweigend korrigiert werden (mehr hier). Diese Korrektur funktioniert dank Fehlerkorrekturbits. Wie ich bereits sagte, haben Subkanäle im Allgemeinen keine solche Redundanz (dirkterwähnt die Q-Subchannel-CRC-Fehlerkorrektur, aber das ändert nicht viel an meiner Schlussfolgerung). Außerdem gibt es keine Möglichkeit, den Fehler festzustellen, wenn er dort auftritt, es sei denn, man weiß vorher, was die richtigen Subchannel-Daten sind.
Sie haben also insgesamt 1855 bekannte Fehler. Wiederholen Sie den Test (im Ernst, machen Sie es!) und Sie erhalten möglicherweise beispielsweise 1790 Fehler oder 1892. Die korrigierte Ausgabe ist jedoch bei jedem Lesen dieselbe.
Wenn es für alle 32 Datenbits ein Subchannel-Bit gibt, dann haben Sie wahrscheinlich ungefähr 1855/32 Subchannel-Bits, die mit unerkanntem Fehler gelesen wurden. Das sind ungefähr 58 Bits. Naja, fast, denn dank Q-Subchannel-CRC können zumindest einige dieser Fehler erkannt werden. Da Q einer von acht Subchannels ist, schätze ich, dass Sie in anderen Subchannels ungefähr 50 fehlerhafte Bits haben. Beim nächsten Lesen erhalten Sie möglicherweise einige dieser Bits ohne Fehler und an anderer Stelle einige neue Subchannel-Fehler. Sie erhalten also eine andere .subDatei. Und Sie wissen trotzdem nicht sicher, welche dieser Bits beim ersten oder zweiten Mal korrekt gelesen wurden.