
Samsung SH-S223L 드라이브가 장착된 Windows 10 x64 컴퓨터에서 CloneCD 5.3.3.0을 사용하여 오래된 비디오 게임의 백업 복사본을 만들고 있습니다.
그 중 하나가 PC용 Hellfire입니다(Diablo 1 확장팩).
- 디스크에
COMPACT disc DATA STORAGE
로고 가 있습니다. - 일련번호:
S0011770
- 공장 SID 코드:
IFPI 1218
- CD-마스터 SID 코드:
IFPI L032
- ISO 9660 PVD 생성 날짜:
1997-11-18 16:30:00.00
나는redump.orgCloneCD 프로필 권장 사항:
[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
내가 아는 한 게임에는 보호 기능이 없지만 디스크를 두 번 덤프하면 결국 다른 하위 채널 파일( .sub
)이 생성됩니다. 및 파일 .ccd
은 .img
동일하고 .sub
차이점만 있습니다. 이를 확인하기 위해 SHA1 체크섬과 16진수 편집기를 사용했습니다. 두 개의 파일 덤프를
업로드했습니다..sub
여기.
저는 이 디스크 사본 두 개를 소유하고 있으며 동작이 두 디스크 모두 동일하다는 점을 언급해야 합니다.
나는 또한 여러 다른 CD-ROM 미디어를 덤프했는데, 때때로 이 동작이 발생하고 때로는 하위 채널이 덤프 전체에서 일관됩니다.
이 행동에 대한 설명은 무엇입니까?
편집하다:
Lite-On iH124-14 드라이브를 사용하여 동일한 CD-ROM을 다시 덤프했는데 동일한 동작(다른 .sub
파일)이 나타납니다.
또한 KProbe 2를 사용하여 매체에 오류가 있는지 확인했는데 다음과 같은 결과를 얻었습니다.
편집하다:
하위 채널에 오류 제어 메커니즘(Q 채널 제외)이 없다는 사실에 추가된 디스크 상태 및/또는 드라이브의 정밀도 부족이 .sub
동일한 매체를 여러 번 덤프할 때 다른 파일을 얻는 이유를 설명하는 것 같습니다.
또한 Plextor PX-712A 드라이브도 가지고 있으며 다음을 .sub
사용하여 덤프 전체에서 일관된 파일을 얻을 수 있었습니다.디스크 이미지 생성기. 이 소프트웨어는 0xD8
지침 대신 0xBE
지침을 활용하여 디스크를 읽으므로 이미지가 더 정확해집니다. 소수의 드라이브(주로 Plextor)만이 이 명령을 지원합니다.
또한 나는 실제로 내가 버리는 이 CD-ROM의 실제 사본 두 개를 소유하고 있습니다(동일한 일련 번호, 동일한 IFPI 코드 및 동일한 레이저 각인 정보). Disc Image Creator를 사용하여 동일한 디스크를 여러 번 덤프하면 일관된 .sub
파일을 얻을 수 있지만 첫 번째 디스크를 덤프한 다음 두 번째 디스크를 덤프하는 경우에는 그렇지 않습니다.
그 중 하나에 스크래치가 몇 개 있고 C1/C2 오류가 더 많기 때문에 미디어 상태와 관련이 있는 것 같습니다.
답변1
다양한 CD 형식이 약간 관련되어 있으며 공식 사양(오디오 CD의 경우 "red book", 데이터 CD의 경우 "yellow book")은 자유롭게 사용할 수 없습니다. 그러나 Ecma-130과 같은 사용 가능한 표준에서 일부 세부 정보를 찾을 수 있습니다.
원본 오디오 CD(CD-DA라고도 함)는 비닐 레코드를 모델로 하여 연속 오디오 데이터의 나선형 트랙을 사용한다는 의미입니다(나중에 DVD에서는 원형 트랙을 사용함). 이 오디오 데이터 내에는 매우 복잡한 방식으로 인터리브된 8개의 하위 채널(P ~ W)이 있으며, 그 중 Q 하위 채널에는 타이밍 정보(말 그대로 분/초/분할 초 단위)와 현재 트랙 번호가 포함되어 있습니다. 원래 목적으로는 이것으로 충분했습니다. 지속적인 플레이를 위해 렌즈는 트랙을 따르도록 약간 조정되었습니다. 탐색하려면 올바른 트랙을 찾을 때까지 Q 하위 채널을 디코딩하는 동안 렌즈가 이동합니다. 이 위치는 약간 거칠지만 음악을 듣기에는 완전히 적합합니다.
오늘날에도 많은 컴퓨터 CD 드라이브는 오디오 샘플 읽기가 정확한 위치에서 시작되도록 렌즈 위치를 완전히 정확하게 지정하고 디코딩 회로를 동기화할 수 없습니다. 이것이 바로 많은 CD 리핑 프로그램이 중복 읽기를 수행하고 결과를 비교하여 이 "지터"를 조정하는 "편집증" 모드를 가지고 있는 이유입니다. 오디오 스트림의 일부로 하위 채널도 지터의 영향을 받기 때문에 정확한 위치를 지정할 수 없는 CD 드라이브에서 리핑할 때 다른 하위 채널 파일을 얻게 됩니다.
CD-DA 사양을 확장하기 위해 데이터 CD(CD-ROM) 사양이 개발되었을 때 데이터를 정확하게 주소 지정하고 읽는 것이 중요하다는 점을 인식하여 2352바이트의 오디오 프레임을 12개의 싱크 바이트와 4개의 헤더 바이트로 세분화했습니다. 섹터 주소), 나머지 2336바이트는 데이터와 추가 오류 수정 수준으로 남겨둡니다. 이 방식을 사용하면 Q 채널 정보에만 의존하지 않고도 섹터를 정확하게 처리할 수 있습니다. 따라서 지터 효과가 적용되지 않고 CD-ROM을 덤프할 때 항상 동일한 데이터를 얻게 되며 덤프에 추가적인 영리함이 필요하지 않습니다.
편집하다자세한 내용은 다음과 같습니다.
에 따르면Ecma-130, 데이터는 단계적으로 스크램블됩니다. 24바이트가 하나의F1-프레임, 이 프레임 중 106바이트는 106바이트로 분산됩니다.F2-프레임, 이는 8바이트의 추가 오류 수정을 가져옵니다. 해당 프레임은 차례로 추가 바이트("제어 바이트")를 가져옵니다.F3-프레임. 추가 바이트에는 하위 채널 정보(각 비트 위치에 대해 하나의 하위 채널)가 포함됩니다. 98개의 F3 프레임 그룹을부분98개의 관련 제어 바이트에는 2개의 동기화 바이트와 96바이트의 실제 하위 채널 데이터가 포함됩니다. 또한 Q 서브채널에는 해당 96비트에 16비트의 CRC 오류 정정 기능이 있습니다.
그 뒤에 있는 아이디어는 긁힘, 먼지 등이 많은 연속 비트에 영향을 주지 않는 방식으로 디스크 표면에 데이터를 배포하여 긁힘이 없는 한 오류 수정을 통해 손실된 데이터를 복구할 수 있다는 것입니다. 너무 큰.
결과적으로 CD 드라이브 하드웨어는 렌즈 위치를 변경한 후 전체 섹션을 읽어 데이터 스트림의 어디에 있는지 알아내야 합니다. 다양한 단계의 디스크램블링은 하드웨어에 의해 수행되며 제어 바이트 스트림의 2개 동기화 바이트에 자체적으로 동기화되어야 합니다. 모든 CD 드라이브 모델은 하드웨어 구현 방식에 따라 다른 모델과 비교하여 동기화하는 데 다른 시간이 필요합니다(두 개의 다른 드라이브가 있는 경우 이를 읽어 테스트할 수 있음). 또한 많은 모델이 동기화하는 데 항상 정확히 동일한 시간이 걸리지 않으므로 조금 일찍 또는 늦게 시작할 수 있으며 디스크램블된 데이터가 항상 동일한 바이트에 출력되지는 않습니다.
따라서 리핑 프로그램이 READ CD
(0xBE) 명령을 발행하면 전송 길이와 시작 주소(또는 Q 채널 시간)를 제공합니다. 드라이브는 렌즈 위치를 지정하고, 프레임을 디스크램블하고, Q 채널을 추출하고, 시간을 비교하고, 정확한 시간을 찾으면 전송을 시작합니다. 이 전송은 위에서 설명한 것처럼 항상 동일한 바이트에서 시작되지 않으므로 여러 READ CD
명령의 결과가 서로 바뀔 수 있습니다. 그렇기 때문에 리퍼에서 다른 하위 채널 파일을 볼 수 있습니다.
하드웨어와 렌즈가 조정되는 상황에 따라 전송이 몇 개의 샘플을 일찍 시작하거나 몇 개의 샘플을 늦게 시작하는지 여부는 다소 무작위입니다. 따라서 결과에서 볼 수 있는 유일한 패턴은 교대 근무가 전송 길이의 배수라는 것입니다.
일부 드라이브 모델에는 실제로 항상 동시에 전송을 시작하는 정확한 하드웨어가 있습니다. 표준에서는 해당 여부를 나타내는 모드 페이지 0x2a("CD/DVD 기능 및 기계적 상태 페이지")의 비트를 정의하지만 실제 경험에 따르면 정확하다고 주장하는 일부 드라이브는 실제로 그렇지 않습니다. (Linux에서는 패키지 sg_modes
에서 모드 페이지를 읽을 수 있습니다 sg3-utiles
. Windows에서는 어떤 도구를 사용해야 할지 모르겠습니다.)
답변2
에 따르면이 위키피디아 기사
프레임은 33바이트로 구성되며, 그 중 24바이트는 오디오 또는 사용자 데이터, 8바이트는 오류 수정(CIRC 생성), 1바이트는 하위 코드용입니다.
이는 하위 채널에 대한 오류 수정이 없음을 의미합니다.
나도 찾았어다른 곳에서 또 다른 질문. 오디오 CD에 관한 것이지만 올바른 문제를 해결한다고 생각합니다.
내가 말할 수 있는 것은 동일한 CD-DA/CD-TEXT에서 읽을 때 두 개의 동일한 하위 채널 판독값(*.SUB 파일)을 얻은 적이 없다는 것입니다. CD-DA/CD-TEXT 형식은 모든 하위 채널에서 EDC/ECC를 전달하지 않기 때문에 데이터가 수정되지 않기 때문에 RAW 모드에서 읽을 때 이것이 정상입니까?
거기에 대한 대답은 다음과 같습니다.
오디오 데이터만 Reed-Solomon 코딩(C1 및 C2)을 따릅니다. 서브코드 채널 데이터(채널 P...W)에는 인터리빙 또는 오류 보호가 적용되지 않습니다.
하는 동안더크트바로 안에 있을지도 몰라귀하의 질문에 대한 또 다른 답변파일이 필요하지 않을 수도 있으므로 .sub
답변이 귀하의 질문을 명시적으로 다루지 않습니다.
이 행동에 대한 설명은 무엇입니까?
.sub
내 대답: 하위 채널에 오류 수정 기능이 없기 때문에 다른 파일을 얻게 됩니다 . 오디오 또는 사용자 데이터를 읽는 동안 읽기 오류가 수정(또는 적어도 감지)되지만, 하위 채널 비트에서 읽기 오류가 발생하면 그대로 통과될 수 있습니다. 긁힘이나 먼지로 인한 특정 오류는 한 읽기 세션 중에 나타날 수 있지만 다른 읽기 세션에서는 나타나지 않을 수 있습니다. 따라서 .sub
파일이 다릅니다.
댓글을 해결하기 위해 답변을 확장했습니다.
나는 이 디스크의 복사본을 두 개 가지고 있는데 그 중 하나는 최상의 상태(눈에 띄는 긁힘 없음)이며 동작은 여전히 동일합니다. 또한
.sub
여러 덤프에 걸쳐 일관된 파일이 있는 최악의 상태의 다른 오래된 게임 CD-ROM도 있습니다 .
나는 (아쉽게도 확실한 증거는 없지만) 다른 CD가 다른 품질로 제조되었을 수 있다고 생각합니다. 하위 채널이 중요하지 않은 경우에는 품질이 낮은 디스크라도 데이터 불일치만 감지하도록 설계된 품질 테스트를 통과할 수 있습니다. 또는 단순히 확률적인 문제일 수도 있습니다. 하나의 디스크에는 오류 수정을 통해 문제를 해결할 수 있는 약점(일관되지 않은 판독값을 제공하는 비트)이 있습니다. 다른 하나는 하위 채널 영역에 있는 경우입니다.
이러한 하위 채널 비트 하나는 다양한 체크섬을 제공하는 데 충분하며, 사용자 데이터 영역의 "미정" 비트 수천 개라도 충분히 배포된 경우 필요할 때 자동으로 수정될 수 있으므로 오류 수정 알고리즘은 너무 많지 않은 문제를 처리합니다. 한 번에 많은 것.
KProbe 2 결과에 대한 반응으로 답변이 확장되었습니다.
내가 아는 한 C1 오류는 자동으로 수정되기 때문에 어느 정도 허용됩니다(여기에 더). 이 수정은 오류 수정 비트 때문에 작동합니다. 이전에 말했듯이 하위 채널에는 일반적으로 이러한 중복성이 없습니다(더크트Q-하위 채널 CRC 오류 수정에 대해 언급했지만 결론적으로는 크게 변하지 않습니다.) 더욱이 거기에서 오류가 발생하는 경우 올바른 하위 채널 데이터가 무엇인지 미리 알지 않는 한 이를 알 수 있는 방법이 없습니다.
따라서 여러분이 알고 있는 총 1,855개의 오류가 있었습니다. 테스트를 반복하면(정말로 해보세요!) 예를 들어 1790 오류가 발생할 수 있습니다. 또는 1892. 그러나 수정된 출력은 읽을 때마다 동일합니다.
32개의 데이터 비트마다 하나의 하위 채널 비트가 있는 경우 감지되지 않은 오류로 읽혀진 약 1855/32개의 하위 채널 비트가 있을 것입니다. 그것은 약 58 비트입니다. 글쎄요, 거의 Q-subchannel CRC 덕분에 이러한 오류 중 일부는 적어도 감지될 수 있기 때문입니다. Q는 8개의 하위 채널 중 하나이므로 다른 하위 채널에는 약 50개의 잘못된 비트가 남아 있는 것으로 추정됩니다. 다음에 읽을 때 오류 없이 이러한 비트 중 일부가 발생할 수 있으며 다른 곳에서는 새로운 하위 채널 오류가 거의 발생하지 않을 수 있습니다. 그래서 당신은 다른 파일을 얻을 것입니다 .sub
. 그리고 여전히 해당 비트 중 어느 비트가 처음에 올바르게 읽혔는지, 아니면 두 번째에 올바르게 읽혔는지 확실히 알 수 없습니다.