동일한 디스크를 덤프 할 때 CD-ROM 하위 채널이 다른가요? 두 개를 소유하고

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.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

내가 아는 한 게임에는 보호 기능이 없지만 디스크를 두 번 덤프하면 다른 하위 채널 파일 ( .sub)이 생깁니다 . .ccd.img파일 만, 동일 .sub달라, 내가 사용 SHA1 체크섬 및이를 확인하려면 16 진수 편집기. 여기에
두 개의 .sub파일 덤프를 업로드 했습니다 .
이 디스크의 사본 두 개를 소유하고 있으며 두 디스크와 동일한 동작을합니다.

또한 다른 여러 CD-ROM 미디어를 덤프했는데, 때때로이 동작이 발생하는 경우가 있습니다. 때때로 서브 채널이 덤프간에 일관성이 있습니다.

이 행동에 대한 설명은 무엇입니까?


편집하다:

Lite-On iH124-14 드라이브로 동일한 CD-ROM을 다시 덤프했으며 동일한 동작 (다른 .sub파일)이 표시됩니다.
또한 KProbe 2의 오류에 대한 매체를 확인했으며 다음 결과를 얻습니다.

KProbe 2 BLER 스캔


편집하다:

서브 채널에 오류 제어 메커니즘 (Q 채널 제외)이 없다는 사실에 디스크 조건 및 / 또는 드라이브 정밀도 부족이 추가되어 .sub동일한 매체를 여러 번 덤프 할 때 왜 다른 파일을 얻는 지 설명합니다 .

나는 또한 Plextor PX-712A 드라이브 .sub를 가지고 Disc Image Creator 를 사용하여 덤프 전체에서 일관된 파일 을 얻도록 언급했습니다 . 이 소프트웨어는 0xD8지침 대신 0xBE지침을 사용하여 디스크를 읽으며보다 정확한 이미지를 생성합니다. 이 명령은 소수의 드라이브 (대부분 Plextor) 만 지원합니다.

또한 실제로이 CD-ROM의 물리적 사본 2 개를 소유하고 있습니다 (동일한 일련 번호, 동일한 IFPI 코드 및 동일한 레이저 조각 정보). Disc Image Creator로 동일한 디스크를 여러 번 덤프하면 일관된 .sub파일을 얻지 만 첫 번째 디스크를 덤프 한 다음 두 번째 디스크를 덤프하면 그렇지 않습니다.
미디어 조건 중 하나에 약간의 흠집과 더 많은 C1 / C2 오류가 있기 때문에 미디어 조건과 관련이 있다고 생각합니다.



답변

다양한 CD 형식이 약간 포함되어 있으며 공식 사양 (오디오 CD의 경우 “빨간 책”, 데이터 CD의 경우 “노란색 책”)을 자유롭게 사용할 수 없습니다. 그러나 Ecma-130과 같은 사용 가능한 표준에서 일부 세부 정보를 찾을 수 있습니다.

원본 오디오 CD (CD-DA라고도 함)는 비닐 레코드로 모델링되었으므로 연속 오디오 데이터의 나선형 트랙 (DVD는 나중에 원형 트랙을 사용함)을 사용합니다. 이 오디오 데이터 내에 매우 복잡한 방식으로 8 개의 서브 채널 (P ~ W)이 인터리빙되며, 그 중 Q 서브 채널에는 타이밍 정보 (문자 / 분 / 초 / 분수)와 현재 트랙 번호가 포함됩니다. 원래 용도로는 이것으로 충분했습니다. 지속적인 재생을 위해 렌즈가 트랙을 따라 약간 조정되었습니다. 구하기 위해 렌즈는 올바른 트랙을 찾을 때까지 Q 서브 채널을 디코딩하는 동안 움직입니다. 이 포지셔닝은 다소 거칠지 만 음악을 듣기에 완전히 적합합니다.

오늘날에도 많은 컴퓨터 CD 드라이브는 렌즈를 완전히 정확하게 위치시키고 디코딩 회로를 동기화 할 수 없으므로 오디오 샘플의 판독이 정확한 위치에서 시작됩니다. 이것이 많은 CD 리핑 프로그램이 “파라노이아 (paranoia)”모드를 갖는 이유입니다. 오디오 스트림의 일부로, 서브 채널은 또한 지터의 영향을 받기 때문에 정확하게 위치 할 수없는 CD 드라이브에서 추출 할 때 다른 서브 채널 파일을 얻게됩니다.

CD-DA 사양을 확장하기 위해 데이터 CD (CD-ROM) 사양을 개발할 때 데이터를 정확하게 주소 지정하고 읽는 중요성을 인식하여 2352 바이트의 오디오 프레임을 12 개의 동기 바이트와 4 개의 헤더 바이트로 세분화했습니다. 섹터 주소), 나머지 2336 바이트의 데이터 및 추가 수준의 오류 수정을 남겨 둡니다. 이 방식을 사용하면 Q 채널 정보에만 의존하지 않고도 섹터를 정확하게 지정할 수 있습니다. 따라서 지터 효과가 적용되지 않으며 CD-ROM을 덤프 할 때 항상 동일한 데이터를 얻을 수 있으며 덤프에 대한 영리함이 필요하지 않습니다.

자세한 내용으로 편집 하십시오.

Ecma-130 에 따르면 데이터는 단계별로 스크램블됩니다. 24 바이트는 F1- 프레임을 구성하고 ,이 프레임의 106 바이트는 106 개의 F2 프레임으로 분배되며 , 8 바이트의 추가 오류 수정이 발생합니다. 이러한 프레임은 차례로 추가 바이트 ( “제어 바이트”)를 가져 와서 F3-Frames로 만듭니다. 여분의 바이트는 서브 채널 정보 (각 비트 위치마다 하나의 서브 채널)를 포함합니다. 98 개의 F3 프레임 그룹을 섹션 이라고하며 98 개의 관련 제어 바이트에는 2 개의 동기 바이트와 96 바이트의 실제 서브 채널 데이터가 포함됩니다. Q 서브 채널은 또한 그 96 비트에서 16 비트의 CRC 오류 정정을 갖는다.

이 아이디어는 스크래치, 먼지 등이 많은 연속적인 비트에 영향을 미치지 않는 방식으로 디스크 표면에 데이터를 배포하는 것이므로 스크래치가없는 한 오류 수정으로 손실 된 데이터를 복구 할 수 있습니다. 너무 큰.

결과적으로 CD 드라이브 하드웨어는 렌즈를 재배치 한 후 데이터 스트림의 위치를 ​​찾기 위해 전체 섹션을 읽어야합니다. 다양한 단계의 디 스크램블링은 하드웨어에 의해 이루어지며, 제어 바이트 스트림에서 2 개의 동기화 바이트와 자체적으로 동기화되어야합니다. 모든 CD 드라이브 모델은 하드웨어 구현 방식에 따라 다른 모델과 동기화하는 데 다른 시간이 필요합니다 (있는 경우 두 개의 다른 드라이브에서 읽음으로써 테스트 할 수 있음). 또한 많은 모델이 동기화하는 데 항상 동일한 시간이 걸리는 것은 아니므로 조금 일찍 또는 늦게 시작하여 항상 동일한 바이트에서 디 스크램블링되지 않은 데이터를 출력 할 수 있습니다.

따라서 리핑 프로그램이 READ CD(0xBE) 명령을 발행하면 전송 길이와 시작 주소 (또는 Q 채널 시간)를 제공합니다. 드라이브는 렌즈를 위치시키고 프레임을 스크램블링하며 Q- 채널을 추출하고 시간을 비교하며 정확한 시간을 찾으면 전송을 시작합니다. 이 전송이 항상 위에서 설명한 것과 동일한 바이트에서 시작되는 것은 아니므로 여러 READ CD명령 의 결과가 서로 바뀔 수 있습니다. 리퍼와 다른 서브 채널 파일이 표시되는 이유가 여기에 있습니다.

하드웨어와 렌즈가 조정되는 환경에 따라 전송이 몇 개의 샘플을 일찍 시작하거나 몇 개의 샘플을 늦게 시작하면 다소 무작위입니다. 결과에서 볼 수있는 유일한 패턴은 시프트가 전송 길이의 배수라는 것입니다.

일부 드라이브 모델에는 실제로 동시에 전송을 시작하는 정확한 하드웨어가 있습니다. 이 표준은 모드 페이지 0x2a ( “CD / DVD 기능 및 기계 상태 페이지”)의 비트를 정의하며, 실제 상황에서는 일부 드라이브가 사실이 아니라고합니다. (리눅스에서, 당신은 사용할 수 있습니다 sg_modes으로부터 sg3-utiles내가 Windows에서 사용하는 어떤 도구 모르는, 모드 페이지를 읽어 패키지).


답변

이 Wikipedia 기사 에 따르면

프레임은 33 바이트로 구성되며이 중 24 바이트는 오디오 또는 사용자 데이터이고 8 바이트는 오류 수정 (CIRC 생성)이며 1 바이트는 서브 코드 용입니다.

이는 서브 채널에 대한 오류 수정이 없음을 나타냅니다.

나는 다른 곳 에서 또 다른 질문을 발견 했다 . 오디오 CD에 관한 것이지만 올바른 문제를 해결한다고 생각합니다.

내가 말할 수있는 것은 동일한 CD-DA / CD-TEXT에서 읽을 때 두 개의 동일한 서브 채널 판독 값 (* .SUB 파일)을 얻지 못했다는 것입니다. CD-DA / CD-TEXT 형식이 모든 서브 채널에서 EDC / ECC를 전달하지 않기 때문에 데이터가 수정되지 않기 때문에 RAW 모드에서 읽을 때 이것이 정상입니까?

거기에 대한 답변 :

오디오 데이터에만 리드 솔로몬 코딩 (C1 및 C2)이 적용됩니다. 서브 코드 채널 데이터 (채널 P … W)는 인터리빙 또는 오류 보호를받지 않습니다.

하지만 dirkt이 바로 수 있습니다 귀하의 질문에 다른 대답은 당신이 필요하지 않을 수 .sub파일을, 대답은 명시 적으로 문제를 해결하지 않습니다

이 동작에 대한 설명은 무엇입니까?

내 대답 : .sub하위 채널에는 오류 수정이 없으므로 다른 파일 을 얻습니다 . 오디오 또는 사용자 데이터를 읽는 동안 읽기 오류가 수정되거나 최소한 감지되지만 하위 채널 비트에서 발생하면 읽기 오류가 그대로 전달 될 수 있습니다. 한 번의 읽기 세션 중에는 긁힘이나 먼지로 인한 특정 오류가 나타날 수 있지만 다른 세션에서는 나타나지 않을 수 .sub있습니다. 따라서 파일이 다릅니다.


댓글을 해결하기 위해 답변이 확장되었습니다.

이 디스크의 사본 두 개가 최상의 상태에 있고 (눈에 보이는 스크래치가 없음) 동작은 여전히 ​​동일합니다. 또한 .sub여러 덤프에서 일관된 파일 을 갖는 최악의 상태의 다른 오래된 게임 CD-ROM도 있습니다 .

다른 CD가 다른 품질로 제조 된 것 같습니다 (아쉽게도 확실한 증거는 없지만). 하위 채널이 중요하지 않은 경우, 품질이 낮은 디스크는 여전히 데이터 불일치 만 감지하도록 설계된 품질 테스트를 통과 할 수 있습니다. 또는 단순히 확률적인 문제 일 수 있습니다. 하나의 디스크에는 오류 수정으로 해결할 수있는 약한 지점 (일관되지 않은 판독 값을 제공하는 비트)이 있습니다. 다른 하나는 서브 채널 영역에 있습니다.

하나의 이러한 서브 채널 비트는 다른 체크섬을 제공하기에 충분하지만, 사용자 데이터 영역에서 수천 개의 “미결정 된”비트조차 필요할 때 자동으로 정정 될 수 있습니다. 한 번에 많은 것.


KProbe 2 결과에 대한 응답으로 답변이 확대되었습니다.

내가 아는 한 C1 오류는 자동으로 수정되기 때문에 (일부 수량까지) 허용됩니다 ( 더 여기 ). 이 수정은 오류 수정 비트로 인해 작동합니다. 앞에서 말했듯이, 서브 채널은 일반적으로 이러한 중복성을 갖지 않습니다 ( dirkt 는 Q- 서브 채널 CRC 오류 수정을 언급하지만 제 결론에는 그다지 바뀌지 않습니다). 또한 오류가 발생하면 올바른 서브 채널 데이터가 무엇인지 미리 알고 있지 않으면이를 알 수있는 방법이 없습니다.

그래서 당신은 총 1855 오류를 알고있었습니다. 테스트를 반복하십시오 (심각하게 수행하십시오!). 예를 들어 1790 오류가있을 수 있습니다. 또는 수정 된 출력은 읽을 때마다 동일합니다.

32 개의 데이터 비트마다 하나의 서브 채널 비트가 있다면 감지되지 않은 오류로 읽은 약 1855/32 개의 서브 채널 비트가 있다고 생각합니다. 약 58 비트입니다. 거의 Q- 서브 채널 CRC 덕분에 이러한 오류 중 일부가 감지 될 수 있습니다. Q는 8 개의 서브 채널 중 하나이므로 다른 서브 채널에 약 50 개의 잘못된 비트가 남아있는 것으로 추정됩니다. 다음에 읽을 때 오류없이이 비트들 중 몇 개만, 다른 곳에서는 새로운 서브 채널 오류가 거의 없을 수 있습니다. 그래서 당신은 다른 .sub파일 을 얻을 것 입니다. 그리고 여전히 어떤 비트가 처음 또는 두 번째로 올바르게 읽혔는지 확실하지 않습니다.