Podkanał CD-ROM jest inny, gdy zrzuca ten sam dysk?

Tworzę kopie zapasowe starych gier wideo za pomocą CloneCD 5.3.3.0 na komputerze z systemem Windows 10 x64 z napędem Samsung SH-S223L.

Jednym z nich jest Hellfire na PC (rozszerzenie Diablo 1):

• Płyta ma COMPACT disc DATA STORAGElogo
• Numer seryjny: S0011770
• Fabryczny kod SID: IFPI 1218
• CD-Master SID-Code: IFPI L032
• Data utworzenia ISO 9660 PVD: 1997-11-18 16:30:00.00

Korzystam z rekomendacji profilu 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

O ile mi wiadomo, gra nie ma ochrony, ale kiedy dwa razy zrzucę dysk, kończę na różnych plikach podkanałowych ( .sub). .ccdI .imgpliki są identyczne, tylko .subróżni użyłem kontrolne SHA1 i edytor hex do sprawdzenia tego.
Wysłałem dwa .subzrzuty plików tutaj .
Muszę wspomnieć, że posiadam dwie kopie tego dysku, a zachowanie jest identyczne z obiema dyskami.

Zrzuciłem także kilka innych nośników CD-ROM, czasem dostaję takie zachowanie, czasami podkanał jest spójny na wszystkich zrzutach.

Jakie jest wyjaśnienie tego zachowania?

Edytować:

Zrzuciłem ponownie ten sam dysk CD-ROM z napędem Lite-On iH124-14 i widzę to samo zachowanie (różne .subpliki).
Sprawdziłem również medium pod kątem błędów w KProbe 2 i otrzymałem następujący wynik:

Edytować:

Wygląda na to, że stan dysku i / lub brak precyzji napędu dodały fakt, że podkanał nie ma mechanizmu kontroli błędów (z wyjątkiem kanału Q) wyjaśnia, dlaczego otrzymuję różne .subpliki podczas wielokrotnego zrzutu tego samego nośnika.

Muszę wspomnieć, że dostałem także napęd Plextor PX-712A i udało mi się uzyskać spójne .subpliki między zrzutami za pomocą programu Disc Image Creator . To oprogramowanie wykorzystuje 0xD8instrukcje zamiast 0xBEinstrukcji do odczytu dysku, co zapewnia dokładniejsze obrazy. Tylko kilka napędów (głównie Plextor) obsługuje tę instrukcję.

Ponadto posiadam dwie fizyczne kopie tej płyty CD-ROM, którą zrzucam (ten sam numer seryjny, te same kody IFPI i te same grawerowane laserowo informacje). Jeśli zrzucę ten sam dysk wiele razy za pomocą Disc Image Creator, otrzymam spójne .subpliki, ale nie, jeśli zrzucę pierwszy dysk, a następnie drugi dysk.
Myślę, że jest to związane z warunkami medialnymi, ponieważ jeden z nich ma kilka rys i więcej błędów C1 / C2.

Różne formaty CD są nieco zaangażowane, a oficjalne specyfikacje („czerwona książka” dla płyty audio CD, „żółta książka” dla płyty CD z danymi) nie są dostępne za darmo. Ale niektóre szczegóły można znaleźć w dostępnych standardach, takich jak Ecma-130.

Oryginalna płyta audio CD (zwana także CD-DA) została modelowana na płycie winylowej, co oznacza, że ​​wykorzystuje również spiralną ścieżkę ciągłych danych audio (DVD później wykorzystywało ścieżki okrągłe). Przeplatane w tych danych audio w bardzo złożony sposób jest 8 podkanałów (od P do W), z których podkanał Q zawiera informacje o taktowaniu (dosłownie w minutach / sekundach / ułamkach sekund) i bieżący numer ścieżki. W pierwotnym celu wystarczyło: w celu ciągłej gry obiektyw został lekko wyregulowany, aby podążać śladem. Aby szukać, soczewka poruszałaby się podczas dekodowania podkanału Q, dopóki nie zostanie znaleziona odpowiednia ścieżka. To ustawienie jest nieco zgrubne, ale całkowicie wystarczające do słuchania muzyki.

Do dziś wiele komputerowych napędów CD nie może całkowicie dokładnie ustawić obiektywu i zsynchronizować obwodów dekodujących, tak że odczyt próbek audio zaczyna się od dokładnej pozycji. Dlatego wiele programów do zgrywania płyt CD ma tryb „paranoi”, w którym nakładają się na siebie odczyty i porównują wyniki w celu dostosowania do tego „drgania”. W ramach strumienia audio podkanał również podlega fluktuacjom i dlatego podczas zgrywania na napędzie CD, który nie może dokładnie ustawić, otrzymujesz różne pliki subkanałowe.

Gdy specyfikacja CD z danymi (CD-ROM) została opracowana w celu rozszerzenia specyfikacji CD-DA, rozpoznano znaczenie dokładnego adresowania i odczytu danych, więc ramka dźwiękowa 2352 bajtów została podzielona na 12 bajtów synchronizacji i 4 bajty nagłówka (dla adres sektora), pozostawiając pozostałe 2336 bajtów danych i dodatkowy poziom korekcji błędów. Za pomocą tego schematu sektory można adresować dokładnie bez konieczności polegania wyłącznie na informacjach o kanale Q. Dlatego efekt fluktuacji nie ma zastosowania, zawsze dostajesz te same dane, kiedy zrzucasz CD-ROM, i nie jest wymagana dodatkowa sprytność w zrzucaniu.

Edytuj z większą ilością szczegółów:

Według Ecma-130 dane są szyfrowane etapami: 24 bajty tworzą ramkę F1 , bajty 106 z tych ramek są rozdzielane na 106 ramek F2 , które otrzymują 8 dodatkowych bajtów korekcji błędów. Każda z tych ramek z kolei otrzymuje dodatkowy bajt („bajt kontrolny”), aby przekształcić je w ramki F3 . Dodatkowy bajt zawiera informacje o podkanale (jeden podkanał na każdą pozycję bitu). Grupa 98 ramek F3 nazywana jest sekcją , a 98 powiązanych bajtów kontrolnych zawiera dwa bajty synchronizacji i 96 bajtów rzeczywistych danych subkanałowych. Dodatkowo podkanał Q ma 16 bitów korekcji błędów CRC w tych 96 bitach.

Ideą tego jest rozprowadzenie danych na powierzchni dysku w taki sposób, aby zadrapania, brud itp. Nie wpływały na wiele ciągłych bitów, więc korekcja błędów może odzyskać utracone dane, o ile rysy nie są za duży.

W rezultacie sprzęt napędu CD musi przeczytać całą sekcję po zmianie położenia soczewki, aby dowiedzieć się, gdzie jest ona w strumieniu danych. Odszyfrowanie różnych etapów odbywa się przez sprzęt, który musi zsynchronizować się z 2 bajtami synchronizacji w strumieniu bajtów kontrolnych. Wszystkie modele napędów CD potrzebują innego czasu na synchronizację niż inne modele (możesz to przetestować czytając z dwóch różnych napędów, jeśli je masz), w zależności od sposobu implementacji sprzętu. Ponadto wiele modeli nie zawsze synchronizuje się dokładnie w tym samym czasie, więc mogą rozpocząć nieco wcześniej lub później i wyodrębnić rozszyfrowane dane nie zawsze w tym samym bajcie.

Kiedy więc program zgrywający wydaje READ CDpolecenie (0xBE), podaje długość transferu i adres początkowy (a raczej czas kanału Q). Napęd ustawia soczewkę, rozszyfrowuje klatki, wyodrębnia kanał Q, porównuje czas, a gdy znajdzie właściwy czas, zaczyna przesyłać. Transfer ten nie zawsze zaczyna się od tego samego bajtu, jak wyjaśniono powyżej, więc wynik wielu READ CDpoleceń może zostać przesunięty względem siebie. Dlatego widzisz różne pliki subkanałów w swoim ripperie.

W zależności od sprzętu i okoliczności, w których obiektyw jest regulowany, jest mniej lub bardziej losowe, jeśli transfer rozpoczyna kilka próbek wcześniej lub kilka próbek późno. Zatem jedynym wzorem, który zobaczysz w wynikach, jest to, że przesunięcia są wielokrotnością długości transferu.

Niektóre modele napędów faktycznie mają dokładny sprzęt, który zawsze rozpocznie transfer w tym samym czasie. Standard definiuje nieco stronę trybu 0x2a („Możliwości CD / DVD i mechaniczna strona stanu”), która wskazuje, czy tak jest, ale rzeczywiste doświadczenia pokazują, że niektóre napędy, które twierdzą, że są dokładne, w rzeczywistości nie są. (W Linuksie możesz używać sg_modesz sg3-utilespakietu do czytania stron trybu, nie wiem, jakiego narzędzia użyć w systemie Windows).

Zgodnie z tym artykułem z Wikipedii

Ramka zawiera 33 bajty, z czego 24 bajty to dane audio lub dane użytkownika, osiem bajtów to korekcja błędów (generowana przez CIRC), a jeden bajt to kod podrzędny.

Sugeruje to, że nie ma korekcji błędów dla podkanału.

Znalazłem też inne pytanie gdzie indziej . Chodzi o płyty audio CD, ale myślę, że rozwiązuje to właściwy problem:

Wszystko, co mogę powiedzieć, to to, że nigdy nie udało mi się uzyskać dwóch identycznych odczytów w podkanałach (plik * .SUB) podczas odczytu z tej samej płyty CD-DA / CD-TEXT. Czy jest to normalne podczas czytania w trybie RAW, ponieważ dane nie są korygowane, ponieważ format CD-DA / CD-TEXT nie zawiera EDC / ECC we wszystkich podkanałach?

Odpowiedź tam:

Tylko dane audio podlegają kodowaniu Reeda-Solomona (C1 i C2). Dane kanału subkodu (kanały P ... W) nie podlegają przeplataniu ani ochronie przed błędami.

Chociaż dirkt może mieć rację w innej odpowiedzi na twoje pytanie, że możesz nie potrzebować .subplików, odpowiedź nie odnosi się wprost do twojego pytania:

Jakie jest wyjaśnienie tego zachowania?

Moja odpowiedź: otrzymujesz różne .subpliki, ponieważ podkanały nie mają korekcji błędów. Błędy odczytu są korygowane (lub przynajmniej wykrywane) podczas odczytu danych audio lub danych użytkownika, ale błąd odczytu może przejść tak jak jest, gdy wystąpi w bicie subkanałowym. Poszczególne błędy spowodowane zadrapaniami lub kurzem mogą pojawić się podczas jednej sesji czytania, nie pojawić się podczas innej itp. - stąd .subróżne pliki.

Odpowiedź została poszerzona, aby uwzględnić komentarz:

Mam dwie kopie tego dysku, jeden w doskonałym stanie (bez widocznej rysy), a zachowanie jest takie samo. Mam też inne starsze dyski CD-ROM w najgorszym stanie, które mają spójny .subplik na wielu zrzutach.

Podejrzewam (niestety bez dowodów), że różne płyty CD mogły zostać wyprodukowane z różną jakością. W przypadku, gdy podkanały nie mają znaczenia, dysk o niższej jakości może nadal przejść testy jakości zaprojektowane wyłącznie w celu wykrycia niespójności danych. Lub może to być po prostu kwestia probabilistyczna: jeden dysk ma słabe punkty (fragment, który daje niespójne odczyty), w których korekta błędów może to naprawić; inny zdarza się, że ma go w obszarze subkanałowym.

Jeden taki bit podkanałowy wystarcza, aby dać różne sumy kontrolne, podczas gdy nawet tysiące „niezdecydowanych” bitów w obszarze danych użytkownika można cicho skorygować, gdy jest to potrzebne, jeśli tylko są wystarczająco rozproszone, więc algorytm korekcji błędów zajmuje się niezbyt zbyt- wielu z nich na raz.

Odpowiedź rozszerzona w reakcji na wyniki KProbe 2.

O ile wiem, błędy C1 są dozwolone (do pewnej ilości), ponieważ są one dyskretnie korygowane ( więcej tutaj ). Ta korekcja działa z powodu bitów korekcji błędów. Jak powiedziałem wcześniej, podkanały w ogóle nie mają takiej redundancji ( dirkt wspomina o korekcji błędów CRC w podkanałach Q, ale to niewiele zmienia w moim wniosku). Co więcej, jeśli błąd wystąpi tam, nie ma sposobu, aby go poznać, chyba że wcześniej wiesz, jakie są prawidłowe dane subkanałowe.

Więc miałeś w sumie 1855 błędów, o których wiesz. Powtórz test (poważnie, zrób to!) I możesz mieć np. 1790 błędów; lub 1892. Jednak poprawione dane wyjściowe są takie same za każdym razem, gdy czytasz.

Jeśli jest jeden bit subkanałowy na każde 32 bity danych, to mówię, że prawdopodobnie masz około 1855/32 bitów subkanałowych, które zostały odczytane z niewykrytym błędem. To około 58 bitów. Cóż, prawie dlatego, że dzięki Q-subkanałowi CRC niektóre z tych błędów mogą zostać wykryte przynajmniej. Ponieważ Q jest jednym z ośmiu podkanałów, szacuję, że pozostało ci około 50 błędnych bitów w innych podkanałach. Następnym razem, gdy będziesz czytać, możesz dostać kilka takich bitów bez błędu i kilka nowych błędów podkanałów w innym miejscu. Otrzymasz inny .subplik. I nadal nie będziesz mieć pewności, które z tych bitów zostały odczytane poprawnie za pierwszym razem czy za drugim razem.