Kênh con CD-ROM có khác nhau khi đổ cùng một đĩa không?

Tôi đang tạo bản sao dự phòng các trò chơi video cũ bằng CloneCD 5.3.3.0 trên máy tính Windows 10 x64 bằng ổ Samsung SH-S223L.

Một trong số đó là Hellfire cho PC (bản mở rộng Diablo 1):

• Đĩa có COMPACT disc DATA STORAGElogo
• Số sê-ri: S0011770
• Mã nhà máy SID: IFPI 1218
• Mã SID CD-Master: IFPI L032
• Ngày tạo ISO ISO 9660: 1997-11-18 16:30:00.00

Tôi sử dụng đề xuất hồ sơ 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

Theo như tôi biết thì trò chơi không có sự bảo vệ nào nhưng khi tôi đổ đĩa hai lần thì tôi kết thúc với các tệp kênh con khác nhau ( .sub). Các tệp .ccdvà .imgtệp giống hệt nhau, chỉ .subkhác nhau, tôi đã sử dụng tổng kiểm tra SHA1 và trình soạn thảo hex để xác minh điều này.
Tôi đã tải lên hai .subbãi tập tin ở đây .
Tôi phải đề cập rằng tôi sở hữu hai bản sao của đĩa này và hành vi giống hệt với cả hai đĩa.

Tôi cũng đã bỏ một số phương tiện CD-ROM khác, đôi khi tôi gặp hành vi này đôi khi kênh con nhất quán trên các bãi.

Giải thích về hành vi này là gì?

Biên tập:

Tôi đã kết xuất cùng một đĩa CD-ROM một lần nữa với ổ đĩa Lite-On iH124-14 và tôi thấy hành vi tương tự (các .subtệp khác nhau ).
Tôi cũng đã kiểm tra lỗi trung bình với KProbe 2 và tôi nhận được kết quả như sau:

Biên tập:

Có vẻ như tình trạng đĩa và / hoặc sự thiếu chính xác của ổ đĩa được thêm vào thực tế là kênh con không có cơ chế kiểm soát lỗi (ngoại trừ kênh Q) giải thích lý do tại sao tôi nhận được các .subtệp khác nhau khi đổ cùng một phương tiện nhiều lần.

Tôi phải đề cập đến việc tôi cũng có một ổ đĩa Plextor PX-712A và quản lý để có được .subcác tệp nhất quán trên các bãi chứa bằng cách sử dụng Disc Image Creator . Phần mềm này tận dụng các 0xD8hướng dẫn thay vì 0xBEhướng dẫn để đọc đĩa, dẫn đến hình ảnh chính xác hơn. Chỉ có một vài ổ đĩa (chủ yếu là Plextor) hỗ trợ hướng dẫn này.

Ngoài ra, tôi thực sự sở hữu hai bản sao vật lý của CD-ROM này mà tôi đang bán (cùng số sê-ri, cùng mã IFPI và cùng thông tin khắc laser). Nếu tôi đổ cùng một đĩa nhiều lần với Trình tạo ảnh đĩa, tôi sẽ nhận được .subcác tệp nhất quán nhưng không phải nếu tôi đổ đĩa thứ nhất và sau đó là đĩa thứ hai.
Tôi đoán nó liên quan đến các điều kiện truyền thông vì một trong số chúng có một vài vết xước và nhiều lỗi C1 / C2 hơn.

Các định dạng CD khác nhau có một chút liên quan và thông số kỹ thuật chính thức ("sách đỏ" cho CD âm thanh, "sách vàng" cho CD dữ liệu) không có sẵn miễn phí. Nhưng bạn có thể tìm thấy một số chi tiết trong các tiêu chuẩn có sẵn như Ecma-130.

CD âm thanh gốc (còn được gọi là CD-DA) được mô hình hóa trên bản ghi vinyl, có nghĩa là nó cũng sử dụng là một bản nhạc xoắn ốc của dữ liệu âm thanh liên tục (DVD sau này được sử dụng các bản nhạc tròn). Xen kẽ trong dữ liệu âm thanh này theo một cách rất phức tạp là 8 kênh con (P đến W), trong đó kênh con Q chứa thông tin về thời gian (nghĩa là tính bằng phút / giây / phân số của giây) và số lượng bản nhạc hiện tại. Đối với mục đích ban đầu, điều này là đủ: Đối với trò chơi liên tục, ống kính chỉ được điều chỉnh một chút để theo dõi. Để tìm kiếm, ống kính sẽ di chuyển trong khi giải mã kênh con Q cho đến khi tìm thấy đúng rãnh. Định vị này hơi thô, nhưng hoàn toàn đủ để nghe nhạc.

Ngày nay, nhiều ổ đĩa CD máy tính không thể định vị chính xác hoàn toàn ống kính và đồng bộ hóa mạch giải mã để việc đọc các mẫu âm thanh bắt đầu ở một vị trí chính xác. Đây là lý do tại sao nhiều chương trình trích xuất CD có chế độ "hoang tưởng", trong đó chúng đọc chồng chéo và so sánh kết quả để điều chỉnh cho "jitter" này. Là một phần của luồng âm thanh, kênh con cũng bị jitter và đó là lý do tại sao bạn nhận được các tệp kênh con khác nhau khi bạn trích xuất trên ổ đĩa CD không thể định vị chính xác.

Khi đặc tả CD dữ liệu (CD-ROM) được phát triển để mở rộng đặc tả CD-DA, tầm quan trọng của việc xử lý và đọc dữ liệu chính xác được nhận ra, do đó, khung âm thanh của 2352 byte được chia thành 12 byte đồng bộ hóa và 4 byte tiêu đề (cho địa chỉ sector), để lại 2336 byte còn lại cho dữ liệu và mức độ sửa lỗi bổ sung. Sử dụng sơ đồ này, các lĩnh vực có thể được giải quyết chính xác mà không phải chỉ dựa vào thông tin kênh Q. Do đó, hiệu ứng jitter không được áp dụng, bạn luôn nhận được cùng một dữ liệu khi bạn đổ CD-ROM và không cần thêm thông minh trong việc bán phá giá.

Chỉnh sửa với nhiều chi tiết hơn:

Theo Ecma-130 , dữ liệu được xáo trộn theo các giai đoạn: 24 byte tạo thành Khung F1 , các byte của 106 khung này được phân phối thành 106 Khung F2 , có thêm 8 byte sửa lỗi. Lần lượt từng khung hình đó có thêm một byte ("byte điều khiển") để biến chúng thành F3-Frames . Byte phụ chứa thông tin kênh con (một kênh con cho mỗi vị trí bit). Một nhóm 98 khung F3 được gọi là một phần và 98 byte điều khiển được liên kết chứa hai byte đồng bộ hóa và 96 byte dữ liệu kênh con thực. Ngoài ra, kênh con Q có 16 bit sửa lỗi CRC trong 96 bit đó.

Ý tưởng đằng sau việc này là phân phối dữ liệu trên bề mặt đĩa sao cho không bị trầy xước, bẩn, v.v. không ảnh hưởng đến nhiều bit liên tục, vì vậy việc sửa lỗi có thể phục hồi dữ liệu bị mất miễn là vết trầy xước không quá lớn.

Do đó, phần cứng ổ đĩa CD cần đọc một phần hoàn chỉnh sau khi định vị lại ống kính để tìm ra vị trí của nó trong luồng dữ liệu. Việc giải mã các giai đoạn khác nhau được thực hiện bằng phần cứng, cần phải tự đồng bộ hóa với 2 byte đồng bộ hóa trong luồng byte điều khiển. Tất cả các mô hình ổ đĩa CD cần một lượng thời gian khác nhau để đồng bộ hóa so với các mô hình khác (bạn có thể kiểm tra bằng cách đọc từ hai ổ đĩa khác nhau, nếu bạn có chúng), tùy thuộc vào cách phần cứng được triển khai. Ngoài ra, nhiều mô hình không phải lúc nào cũng đồng thời chính xác để đồng bộ hóa, vì vậy chúng có thể bắt đầu sớm hoặc muộn một chút và xuất ra dữ liệu được giải mã không phải lúc nào cũng ở cùng một byte.

Vì vậy, khi chương trình trích xuất phát READ CDlệnh (0xBE), nó sẽ cung cấp thời lượng truyền và địa chỉ bắt đầu (hay đúng hơn là thời gian kênh Q). Ổ đĩa định vị ống kính, giải mã các khung hình, trích xuất kênh Q, so sánh thời gian và khi tìm thấy thời gian chính xác, nó bắt đầu chuyển. Việc chuyển này không phải lúc nào cũng bắt đầu ở cùng một byte như đã giải thích ở trên, do đó, kết quả của nhiều READ CDlệnh có thể được thay đổi so với nhau. Đó là lý do tại sao bạn thấy các tệp kênh con khác nhau từ trình trích xuất của mình.

Tùy thuộc vào phần cứng và hoàn cảnh khi ống kính được điều chỉnh, sẽ ít nhiều ngẫu nhiên nếu quá trình chuyển bắt đầu một vài mẫu sớm hoặc một vài mẫu trễ. Vì vậy, mẫu duy nhất bạn sẽ thấy trong kết quả là các ca làm việc là bội số của độ dài chuyển.

Một số mô hình ổ đĩa thực sự có phần cứng chính xác sẽ luôn bắt đầu chuyển cùng một lúc. Tiêu chuẩn xác định một chút trong trang chế độ 0x2a ("Khả năng CD / DVD và Trang trạng thái cơ học") cho biết nếu đó là trường hợp, nhưng kinh nghiệm trong thế giới thực cho thấy một số ổ đĩa tự nhận là chính xác thực tế không phải vậy. (Trong Linux, bạn có thể sử dụng sg_modestừ sg3-utilesgói để đọc các trang chế độ, tôi không biết nên sử dụng công cụ nào trong Windows).

Theo bài viết Wikipedia này

Một khung bao gồm 33 byte, trong đó 24 byte là dữ liệu âm thanh hoặc dữ liệu người dùng, tám byte là sửa lỗi (do CIRC tạo) và một byte dành cho mã con.

Điều này cho thấy không có sửa lỗi cho kênh con.

Tôi cũng đã tìm thấy một câu hỏi khác ở nơi khác . Đó là về CD âm thanh nhưng tôi nghĩ nó giải quyết đúng vấn đề:

Tất cả những gì tôi có thể nói là tôi chưa bao giờ quản lý để có được hai lần đọc kênh con giống hệt nhau (tệp * .SUB) khi đọc từ cùng một CD-DA / CD-TEXT. Điều đó có bình thường khi đọc ở chế độ RAW vì dữ liệu không được sửa vì định dạng CD-DA / CD-TEXT không mang theo EDC / ECC trong tất cả các kênh con?

Câu trả lời ở đó:

Chỉ có dữ liệu âm thanh chịu sự mã hóa của Sậy-Solomon (C1 & C2). Dữ liệu kênh mã hóa (kênh P ... W) không phải chịu sự xen kẽ hoặc bảo vệ lỗi.

Mặc dù dirkt có thể đúng trong một câu trả lời khác cho câu hỏi của bạn rằng bạn có thể không cần .subtệp, nhưng câu trả lời không giải quyết rõ ràng câu hỏi của bạn:

Giải thích về hành vi này là gì?

Câu trả lời của tôi: bạn nhận được các .subtệp khác nhau vì các kênh con không có sửa lỗi. Lỗi đọc được sửa chữa (hoặc ít nhất là được phát hiện) trong khi đọc dữ liệu âm thanh hoặc người dùng, nhưng lỗi đọc có thể vượt qua khi nó xảy ra ở bit kênh con. Các lỗi đặc biệt do vết trầy xước hoặc bụi có thể xuất hiện trong một phiên đọc, không xuất hiện trong một phiên khác, v.v. - do đó .subcác tệp khác nhau.

Trả lời mở rộng để giải quyết các bình luận:

Tôi có hai bản sao của đĩa này, một bản đang trong tình trạng tuyệt vời (không có vết xước rõ ràng) và hành vi vẫn như cũ. Tôi cũng có các CD-ROM trò chơi cũ khác trong tình trạng tồi tệ nhất có .subtệp nhất quán trên nhiều bãi.

Tôi nghi ngờ (không may là không có bằng chứng cứng) các đĩa CD khác nhau có thể đã được sản xuất với chất lượng khác nhau. Trong trường hợp khi kênh con không thành vấn đề, đĩa chất lượng thấp hơn vẫn có thể vượt qua các kiểm tra chất lượng được thiết kế để chỉ phát hiện sự không nhất quán dữ liệu. Hoặc có thể chỉ đơn giản là vấn đề xác suất: một đĩa có điểm yếu (một bit cho kết quả không nhất quán) trong đó sửa lỗi có thể khắc phục; một trường hợp khác có nó trong khu vực kênh con.

Một bit kênh con như vậy là đủ để cung cấp cho bạn các tổng kiểm tra khác nhau, trong khi hàng ngàn bit "chưa quyết định" trong vùng dữ liệu người dùng có thể được sửa chữa một cách âm thầm khi cần, nếu chỉ chúng được phân phối đủ, do đó thuật toán sửa lỗi sẽ không xử lý quá. nhiều trong số họ tại một thời điểm.

Trả lời mở rộng trong phản ứng với kết quả KProbe 2.

Theo như tôi biết thì các lỗi C1 được cho phép (với một số lượng) vì chúng được sửa chữa âm thầm ( nhiều hơn ở đây ). Hiệu chỉnh này hoạt động vì các bit sửa lỗi. Như tôi đã nói trước đây, các kênh con không có sự dư thừa như vậy nói chung ( dirkt đề cập đến sửa lỗi CRC kênh con Q nhưng điều đó không thay đổi nhiều trong kết luận của tôi). Hơn nữa, nếu lỗi xảy ra ở đó, không có cách nào để biết nó, trừ khi bạn biết trước dữ liệu kênh con chính xác là gì.

Vì vậy, bạn đã có tổng cộng 1855 lỗi bạn biết. Lặp lại thử nghiệm (nghiêm túc, thực hiện nó!) Và bạn có thể có ví dụ 1790 lỗi; hoặc 1892. Tuy nhiên, đầu ra được sửa là giống nhau mỗi lần bạn đọc.

Nếu có một bit kênh con cho mỗi 32 bit dữ liệu thì tôi nói rằng bạn có thể có khoảng 1855/32 bit kênh con được đọc với lỗi không bị phát hiện. Đó là khoảng 58 bit. Chà, hầu như, vì nhờ CRC kênh con Q, một số lỗi này có thể được phát hiện ít nhất. Vì Q là một trong tám kênh con, tôi ước tính bạn còn lại khoảng 50 bit sai trong các kênh con khác. Lần tới khi bạn đọc, bạn có thể nhận được một vài trong số các bit này mà không gặp lỗi và một vài lỗi kênh con mới ở nơi khác. Vì vậy, bạn sẽ nhận được các .subtập tin khác nhau . Và bạn vẫn không biết chắc chắn những bit nào được đọc chính xác lần đầu hay lần thứ hai.