ช่องย่อยของ CD-ROM แตกต่างกันเมื่อทิ้งแผ่นดิสก์แผ่นเดียวกันหรือไม่?


14

ฉันทำสำเนาสำรองของวิดีโอเกมเก่าด้วย CloneCD 5.3.3.0 บนคอมพิวเตอร์ Windows 10 x64 ของฉันด้วยไดรฟ์ Samsung SH-S223L

หนึ่งในนั้นคือ Hellfire สำหรับพีซี (การขยาย Diablo 1):

  • แผ่นดิสก์มีCOMPACT disc DATA STORAGEโลโก้
  • หมายเลขซีเรียล: S0011770
  • รหัส SID จากโรงงาน: IFPI 1218
  • SID-CD-Master รหัส: 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

เท่าที่ฉันรู้ว่าเกมไม่มีการป้องกัน แต่เมื่อฉันทิ้งแผ่นดิสก์สองครั้งฉันก็จบลงด้วยไฟล์ subchannel ที่แตกต่างกัน ( .sub) .ccdและ.imgไฟล์เหมือนกันเพียง แต่.subแตกต่างกันผม checksums SHA1 สินค้าและแก้ไขฐานสิบหกในการตรวจสอบนี้
ฉันได้อัปโหลดสอง.subทิ้งไฟล์ที่นี่
ฉันต้องพูดถึงว่าฉันเป็นเจ้าของดิสก์สองชุดนี้และพฤติกรรมนั้นเหมือนกันกับแผ่นทั้งสอง

ฉันยังทิ้งสื่อ CD-ROM อื่น ๆ อีกหลายครั้งบางครั้งฉันได้รับพฤติกรรมนี้บางครั้งช่องสัญญาณย่อยมีความสอดคล้องกันระหว่างการทิ้ง

คำอธิบายของพฤติกรรมนี้คืออะไร?


แก้ไข:

ฉันทิ้งซีดีรอมเดียวกันอีกครั้งด้วยไดรฟ์ Lite-On iH124-14 และฉันเห็นพฤติกรรมเดียวกัน ( .subไฟล์ต่าง ๆ)
ฉันยังตรวจสอบสื่อสำหรับข้อผิดพลาดกับ KProbe 2 และฉันได้รับผลลัพธ์ต่อไปนี้:

สแกน KProbe 2 BLER


แก้ไข:

ดูเหมือนว่าเงื่อนไขของดิสก์และ / หรือการขาดความแม่นยำของไดรฟ์เพิ่มเข้ากับข้อเท็จจริงที่ว่าช่องสัญญาณย่อยไม่มีกลไกการควบคุมข้อผิดพลาด (ยกเว้นช่อง Q) อธิบายว่าทำไมฉันถึงได้รับ.subไฟล์ต่าง ๆเมื่อทิ้งสื่อเดียวกันหลาย ๆ ครั้ง

ฉันต้องพูดถึงฉันยังมีไดรฟ์ Plextor PX-712A และการบริหารจัดการที่จะได้รับสอดคล้อง.subไฟล์ทั่วทิ้งโดยใช้Disc Creator ซอฟต์แวร์นี้ใช้0xD8คำแนะนำแทน0xBEคำแนะนำในการอ่านแผ่นดิสก์ทำให้ได้ภาพที่แม่นยำยิ่งขึ้น มีเพียงไม่กี่ไดรฟ์ (ส่วนใหญ่ Plextor) รองรับคำแนะนำนี้

นอกจากนี้ฉันยังเป็นเจ้าของสำเนาทางกายภาพสองแผ่นของซีดีรอมนี้ฉันกำลังทิ้ง (หมายเลขซีเรียลเดียวกันรหัส IFPI เดียวกันและข้อมูลแกะสลักเลเซอร์เดียวกัน) หากฉันถ่ายโอนดิสก์แผ่นเดียวกันหลาย ๆ ครั้งด้วย Disc Image Creator ฉันจะได้รับ.subไฟล์ที่สอดคล้องกันแต่ไม่ใช่ถ้าฉันทิ้งแผ่นดิสก์แผ่นแรกและแผ่นที่สอง
ฉันเดาว่ามันเกี่ยวข้องกับเงื่อนไขของสื่อเนื่องจากหนึ่งในนั้นมีรอยขีดข่วนเล็กน้อยและมีข้อผิดพลาด C1 / C2 เพิ่มเติม


1
ข้อผิดพลาดในการอ่าน (ฝุ่นรอยขีดข่วนไม่จำเป็นต้องเกิดข้อผิดพลาดจริงจากไดรฟ์) อาจทำให้ภาพ CDROM แตกต่างกัน ความแตกต่างอาจน้อยนิด ความแตกต่าง 1 บิตก็เพียงพอแล้วสำหรับการตรวจสอบ SHA * / MD5 จะแตกต่างกัน
Quixotic

คำตอบ:


15

รูปแบบซีดีที่หลากหลายนั้นมีความเกี่ยวข้องกันเล็กน้อยและข้อกำหนดอย่างเป็นทางการ ("สมุดแดง" สำหรับซีดีเพลง "สมุดเหลือง" สำหรับซีดีข้อมูล) ไม่สามารถใช้ได้อย่างอิสระ แต่คุณสามารถค้นหารายละเอียดบางอย่างในมาตรฐานที่มีเช่น Ecma-130

ซีดีเพลงต้นฉบับ (หรือที่เรียกว่า CD-DA) ถูกสร้างแบบจำลองบนแผ่นเสียงไวนิลซึ่งหมายความว่ามันยังใช้เป็นแทร็กเกลียวของข้อมูลเสียงที่ต่อเนื่อง (ดีวีดีต่อมาใช้แผ่นวงกลม) สอดแทรกข้อมูลเสียงนี้ในรูปแบบที่ซับซ้อนมากคือ 8 ช่องสัญญาณย่อย (P ถึง W) ซึ่งช่องสัญญาณย่อย Q มีข้อมูลเวลา (ตัวอักษรในนาที / วินาที / เศษส่วนของวินาที) และหมายเลขแทร็กปัจจุบัน เพื่อจุดประสงค์ดั้งเดิมนี่ก็เพียงพอแล้ว: สำหรับการเล่นอย่างต่อเนื่องเลนส์ถูกปรับเล็กน้อยเพื่อติดตามแทร็ค ในการค้นหาเลนส์จะเคลื่อนที่ในขณะที่ถอดรหัสช่องสัญญาณย่อย Q จนกว่าจะพบเส้นทางที่ถูกต้อง ตำแหน่งนี้ค่อนข้างหยาบ แต่ก็เพียงพอแล้วที่จะฟังเพลง

จนถึงทุกวันนี้ไดรฟ์ซีดีคอมพิวเตอร์จำนวนมากไม่สามารถวางตำแหน่งเลนส์ได้อย่างแม่นยำและซิงโครไนซ์วงจรถอดรหัสเพื่อให้การอ่านตัวอย่างเสียงเริ่มต้นที่ตำแหน่งที่แน่นอน นี่คือเหตุผลที่โปรแกรมริปซีดีจำนวนมากมีโหมด "ความหวาดระแวง" ซึ่งพวกเขาซ้อนทับกันอ่านและเปรียบเทียบผลลัพธ์เพื่อปรับสำหรับ "กระวนกระวายใจ" นี้ ในฐานะที่เป็นส่วนหนึ่งของกระแสข้อมูลเสียงช่องสัญญาณย่อยจะต้องมีการกระตุกและนั่นคือสาเหตุที่คุณได้รับไฟล์ช่องสัญญาณย่อยต่าง ๆ เมื่อคุณริปบนไดรฟ์ซีดีที่ไม่สามารถวางตำแหน่งได้อย่างถูกต้อง

เมื่อข้อมูลจำเพาะ CD (CD-ROM) ได้รับการพัฒนาเพื่อขยายข้อกำหนด CD-DA ความสำคัญของการระบุที่อยู่และอ่านข้อมูลอย่างถูกต้องจึงได้รับการจดจำเฟรมเสียงของ 2352 ไบต์นั้นแบ่งเป็น 12 sync bytes และ 4 header header ไบต์ ที่อยู่ของเซกเตอร์) ทำให้เหลือข้อมูลอีก 2336 ไบต์สำหรับข้อมูลและระดับการแก้ไขข้อผิดพลาดเพิ่มเติม การใช้รูปแบบนี้ภาคสามารถแก้ไขได้อย่างแน่นอนโดยไม่ต้องพึ่งพาข้อมูลช่อง Q เท่านั้น ดังนั้นเอฟเฟ็กต์ jitter จะไม่นำมาใช้คุณจะได้รับข้อมูลเดิมเสมอเมื่อคุณถ่ายโอนข้อมูลซีดีรอมและไม่จำเป็นต้องใช้ความฉลาดเพิ่มเติมในการถ่ายโอนข้อมูล

แก้ไขพร้อมรายละเอียดเพิ่มเติม:

ตามข้อมูลในEcma-130ข้อมูลจะถูกแปลงเป็นขั้นตอน: 24 ไบต์ประกอบด้วยF1-Frame , ไบต์ของ 106 ของเฟรมเหล่านี้จะถูกกระจายไปยัง 106 F2-Framesซึ่งจะได้รับการแก้ไขข้อผิดพลาดเพิ่มเติม 8 ไบต์ เฟรมเหล่านั้นในการเปิดแต่ละได้รับไบต์พิเศษ ( "การควบคุมไบต์") เพื่อทำให้พวกเขาเป็นF3-Frames ไบต์พิเศษประกอบด้วยข้อมูลช่องสัญญาณย่อย (หนึ่งช่องสัญญาณย่อยสำหรับแต่ละตำแหน่งบิต) กลุ่ม 98 F3-Frames เรียกว่าส่วนและ 98 ไบต์การควบคุมที่เกี่ยวข้อง 98 ไบต์และซิงค์ข้อมูลย่อย subchannel 96 ไบต์ ช่องย่อย Q นอกจากนี้ยังมีการแก้ไขข้อผิดพลาด CRC 16 บิตใน 96 บิตเหล่านั้น

แนวคิดเบื้องหลังนี้คือการกระจายข้อมูลบนพื้นผิวของดิสก์ในลักษณะที่เป็นรอยขีดข่วนสิ่งสกปรก ฯลฯ ไม่ส่งผลกระทบต่อบิตต่อเนื่องจำนวนมากดังนั้นการแก้ไขข้อผิดพลาดสามารถกู้คืนข้อมูลที่สูญหายได้ตราบใดที่รอยขีดข่วนไม่ใช่ มีขนาดใหญ่เกินไป.

ดังนั้นฮาร์ดแวร์ไดรฟ์ซีดีต้องอ่านส่วนที่สมบูรณ์หลังจากเปลี่ยนตำแหน่งเลนส์เพื่อค้นหาตำแหน่งที่อยู่ในกระแสข้อมูล descrambling ของขั้นตอนต่าง ๆ จะทำโดยฮาร์ดแวร์ซึ่งจำเป็นต้องซิงค์ตัวเองกับ 2 ซิงค์ไบต์ในกระแสข้อมูลไบต์ควบคุม ไดรฟ์ซีดีทุกรุ่นต้องใช้เวลาในการซิงค์ต่างกันเมื่อเทียบกับรุ่นอื่น (คุณสามารถทดสอบได้โดยการอ่านจากไดรฟ์สองตัวที่แตกต่างกันหากคุณมี) โดยขึ้นอยู่กับวิธีการใช้งานฮาร์ดแวร์ ยิ่งไปกว่านั้นหลาย ๆ รุ่นไม่ได้ใช้เวลาในการซิงค์ที่แน่นอนเสมอดังนั้นพวกเขาจึงสามารถเริ่มต้นได้ช้าหรือช้าและเอาท์พุทข้อมูลที่ตกกระทบไม่ได้ที่ไบต์เดียวกันเสมอไป

ดังนั้นเมื่อโปรแกรมริปออกREAD CDคำสั่ง (0xBE) จะให้ความยาวการโอนและที่อยู่เริ่มต้น (หรือมากกว่าเวลา Q-channel) ไดรฟ์จัดตำแหน่งเลนส์เลื่อนเฟรมดึงแยก Q-channel เปรียบเทียบเวลาและเมื่อพบเวลาที่ถูกต้องจะเริ่มถ่ายโอน การถ่ายโอนนี้ไม่ได้เริ่มต้นที่ไบต์เดียวกันตามที่อธิบายไว้ข้างต้นเสมอดังนั้นผลลัพธ์ของREAD CDคำสั่งหลายคำสั่งอาจถูกเลื่อนไปหากัน นั่นเป็นเหตุผลที่คุณเห็นไฟล์ subchannel แตกต่างจาก ripper ของคุณ

ขึ้นอยู่กับฮาร์ดแวร์และสถานการณ์เมื่อปรับเลนส์มันจะสุ่มมากขึ้นหรือน้อยลงหากการถ่ายโอนเริ่มต้นตัวอย่างบางส่วนก่อนหรือช้าไปสักสองสามตัวอย่าง ดังนั้นรูปแบบเดียวที่คุณจะเห็นในผลลัพธ์คือกะมีความยาวหลายเท่าของการถ่ายโอน

ไดรฟ์บางรุ่นมีฮาร์ดแวร์ที่แม่นยำซึ่งจะเริ่มถ่ายโอนในเวลาเดียวกันเสมอ มาตรฐานกำหนดบิตในโหมดหน้า 0x2a ("ความสามารถของซีดี / ดีวีดีและหน้าสถานะกลไก") ซึ่งระบุว่าเป็นกรณีนี้ แต่ประสบการณ์ในโลกแห่งความจริงแสดงให้เห็นว่าไดรฟ์บางตัวที่อ้างว่าเป็นจริงนั้นไม่จริง (ภายใต้ Linux คุณสามารถใช้sg_modesจากsg3-utilesแพ็คเกจเพื่ออ่านหน้าโหมดฉันไม่รู้เครื่องมือที่จะใช้ใน Windows)


ขอบคุณสำหรับคำตอบของคุณมันทำให้ฉันมีบริบทที่น่าสนใจ ฉันเข้าใจว่าฉันไม่ต้องการช่องสัญญาณย่อยเพื่อให้มีข้อมูลที่ถูกต้องจากแผ่นดิสก์ฉันแค่สงสัยว่าทำไมตัวช่องสัญญาณย่อยนั้นไม่สอดคล้องกันในการทิ้ง
Chris

1
ใช่ฉันพยายามอธิบายว่าทำไมช่องสัญญาณย่อยไม่สอดคล้องกัน: คุณส่งคำสั่งไปยังดิสก์เพื่ออ่านข้อมูล "ดิบ" รวมถึงช่องย่อยและการวางตำแหน่งไม่แม่นยำดังนั้นจึงสามารถเกิดขึ้นได้ว่าการอ่านเริ่มต้นที่จุดต่าง ๆ หากคุณเปรียบเทียบข้อมูลที่คุณอ่านคุณจะเห็นว่าส่วนต่างๆเพิ่งเปลี่ยนไป OTOH ข้อมูลซีดีรอมเองไม่มีปัญหานี้ และคุณต้องการบริบทที่จะเข้าใจว่าทำไมการวางตำแหน่งไม่ถูกต้อง (แม้ว่าคุณจะต้องบริบทมากขึ้นด้วยเหตุผลที่แน่นอนซึ่งฉันไม่ได้เข้าไป)
dirkt

ฉันสนใจที่จะทราบเหตุผลที่แน่นอนหากเป็นไปได้ ฉันเพิ่มลิงค์ดาวน์โหลดลง.subในไฟล์ในคำถามของฉัน ฉันเปรียบเทียบกับโปรแกรมแก้ไขฐานสิบหกและคุณพูดถูกว่าข้อมูลถูกเลื่อนไปฉันไม่สามารถหารูปแบบที่ชัดเจนได้
Chris

น่าสนใจมากขอบคุณ ผมติดตั้ง Cygwin, SG3-utils sg_modesและวิ่ง ฉันมี0x2aในส่วน "ความสามารถ MM และสถานะเชิงกล (ล้าสมัย)" ฉันจะได้รับไดรฟ์ Liteon ใหม่ในวันพรุ่งนี้และทดสอบอีกครั้งเพื่อดูว่าฉันได้รับช่องสัญญาณย่อยที่สอดคล้องกันหรือไม่
Chris

1
การปรากฏตัวของเพจรหัสไม่ได้มีความหมายอะไรเลยคุณต้องดูบิตที่ถูกต้อง (บิตที่ 1 จาก 6 ไบต์ "สตรีม CD-DA นั้นแม่นยำ") หากคุณมีไดรฟ์สองตัวให้หยิบซีดีเพลงมาฉีกบนไดรฟ์ทั้งสองแล้วเปรียบเทียบข้อมูล คุณควรเห็นออฟเซ็ตต่าง ๆ ที่ข้อมูลที่ไม่ใช่ศูนย์เริ่มขึ้น คุณอาจเห็นออฟเซ็ตต่าง ๆ สำหรับไฟล์ subchannel ระหว่างสองไดรฟ์
dirkt

8

ตามบทความ Wikipedia นี้

เฟรมประกอบด้วย 33 ไบต์ซึ่ง 24 ไบต์เป็นข้อมูลเสียงหรือผู้ใช้แปดไบต์คือการแก้ไขข้อผิดพลาด (สร้างโดย CIRC) และหนึ่งไบต์สำหรับโค้ดย่อย

สิ่งนี้ชี้ให้เห็นว่าไม่มีการแก้ไขข้อผิดพลาดสำหรับช่องสัญญาณย่อย

ฉันได้พบคำถามอื่นด้วย มันเกี่ยวกับซีดีเพลง แต่ฉันคิดว่ามันแก้ปัญหาได้ถูกต้อง:

ทั้งหมดที่ฉันสามารถพูดได้คือฉันไม่เคยได้รับการอ่าน subchannel สองไฟล์ที่เหมือนกัน (* .SUB) เมื่ออ่านจาก CD-DA / CD-TEXT เดียวกัน เป็นเรื่องปกติหรือไม่เมื่ออ่านในโหมด RAW เนื่องจากข้อมูลไม่ได้รับการแก้ไขเนื่องจากรูปแบบ CD-DA / CD-TEXT ไม่ได้พก EDC / ECC ในช่องย่อยทั้งหมดหรือไม่

คำตอบที่นั่น:

ข้อมูลเสียงเท่านั้นที่ถูกเข้ารหัส Reed-Solomon (C1 & C2) ข้อมูลแชแนลรหัสย่อย (แชนเนล P ... W) ไม่อยู่ภายใต้การสอดแทรกหรือการป้องกันข้อผิดพลาด

แม้ว่าdirktอาจตอบถูกในคำถามของคุณซึ่งคุณอาจไม่ต้องการ.subไฟล์ แต่คำตอบนั้นไม่ได้ตอบคำถามของคุณอย่างชัดเจน:

คำอธิบายของพฤติกรรมนี้คืออะไร?

คำตอบของฉัน: คุณได้รับ.subไฟล์ต่างกันเนื่องจากช่องสัญญาณย่อยไม่มีการแก้ไขข้อผิดพลาด ข้อผิดพลาดในการอ่านได้รับการแก้ไข (หรือตรวจพบอย่างน้อย) ในขณะที่อ่านข้อมูลเสียงหรือข้อมูลผู้ใช้ แต่ข้อผิดพลาดในการอ่านสามารถส่งผ่านได้ตามที่เกิดขึ้นที่บิต subchannel ข้อผิดพลาดโดยเฉพาะอย่างยิ่งเนื่องจากรอยขีดข่วนหรือฝุ่นอาจปรากฏขึ้นในช่วงการอ่านหนึ่งไม่ปรากฏขึ้นในช่วงอื่น ๆ - ดังนั้น.subไฟล์ที่แตกต่างกัน


ขยายคำตอบเพื่อแสดงความคิดเห็นแล้ว:

ฉันมีสองสำเนาของดิสก์นี้อยู่ในสภาพที่ดีเยี่ยม (ไม่มีรอยขีดข่วนที่มองเห็นได้) และพฤติกรรมยังคงเหมือนเดิม ฉันยังมีซีดีรอมเกมรุ่นเก่าอื่น ๆ ในสภาพที่เลวร้ายที่สุดที่มี.subไฟล์สอดคล้องกันในการถ่ายโอนข้อมูลหลายครั้ง

ฉันสงสัยว่า (น่าเสียดายที่ไม่มีหลักฐานที่แน่ชัด) แผ่นซีดีที่แตกต่างกันอาจผลิตด้วยคุณภาพที่แตกต่างกัน ในกรณีที่ช่องสัญญาณย่อยไม่สำคัญดิสก์คุณภาพต่ำอาจยังคงผ่านการทดสอบคุณภาพที่ออกแบบมาเพื่อตรวจสอบความไม่สอดคล้องกันของข้อมูลเท่านั้น หรืออาจเป็นเพียงเรื่องความน่าจะเป็น: ดิสก์หนึ่งแผ่นมีจุดอ่อน (บิตที่ให้การอ่านที่ไม่สอดคล้อง) ซึ่งการแก้ไขข้อผิดพลาดสามารถแก้ไขได้ อีกอย่างเกิดขึ้นกับมันในพื้นที่ subchannel

บิต subchannel หนึ่งบิตนั้นเพียงพอที่จะให้คุณตรวจสอบที่แตกต่างกันในขณะที่บิต "undecided" บิตจำนวนมากในพื้นที่ข้อมูลผู้ใช้อาจได้รับการแก้ไขอย่างเงียบ ๆ เมื่อจำเป็นถ้าพวกเขามีการกระจายเพียงพอดังนั้นอัลกอริธึมการแก้ไขข้อผิดพลาด มากของพวกเขาในเวลา


คำตอบถูกขยายออกไปเพื่อตอบสนองต่อผลลัพธ์ KProbe 2

เท่าที่ฉันทราบข้อผิดพลาด C1 ได้รับอนุญาต (ในปริมาณ) เพราะพวกเขาได้รับการแก้ไขอย่างเงียบ ๆ ( เพิ่มเติมที่นี่ ) การแก้ไขนี้ใช้งานได้เนื่องจากบิตการแก้ไขข้อผิดพลาด ดังที่ฉันพูดก่อนหน้านี้ช่องย่อยไม่มีความซ้ำซ้อนโดยทั่วไป ( dirktกล่าวถึงการแก้ไขข้อผิดพลาด CRC Q-subchannel แต่ไม่ได้เปลี่ยนแปลงมากนักในข้อสรุปของฉัน) ยิ่งไปกว่านั้นถ้าข้อผิดพลาดเกิดขึ้นที่นั่นจะไม่มีทางรู้ได้นอกจากว่าคุณรู้ล่วงหน้าว่าข้อมูล subchannel ที่ถูกต้องคืออะไร

ดังนั้นคุณมีข้อผิดพลาดทั้งหมด 1855 ข้อที่คุณทราบ ทำแบบทดสอบซ้ำ (อย่างจริงจังทำ!) และคุณอาจมีข้อผิดพลาดเช่น 1790; หรือ 1892. แต่ผลลัพธ์ที่ถูกต้องจะเหมือนกันทุกครั้งที่คุณอ่าน

หากมีบิตช่องสัญญาณย่อยหนึ่งบิตสำหรับทุกบิตข้อมูล 32 บิตฉันว่าคุณอาจมีบิตย่อยช่องประมาณ 1855/32 บิตที่อ่านด้วยข้อผิดพลาดที่ตรวจไม่พบ นั่นคือประมาณ 58 บิต เกือบจะเป็นเพราะขอบคุณ Q-subchannel CRC ข้อผิดพลาดบางอย่างอาจตรวจพบได้อย่างน้อย เนื่องจาก Q เป็นหนึ่งในแปดช่องสัญญาณย่อยฉันจึงประมาณว่าคุณมีเหลืออยู่ประมาณ 50 บิตที่ผิดพลาดในช่องย่อยอื่น ๆ ครั้งต่อไปที่คุณอ่านคุณอาจได้รับบิตเหล่านี้เพียงเล็กน้อยโดยไม่มีข้อผิดพลาด ดังนั้นคุณจะได้รับ.subไฟล์ที่แตกต่าง และถึงกระนั้นคุณก็ยังไม่รู้ว่าบิตใดที่อ่านอย่างถูกต้องในครั้งแรกหรือครั้งที่สอง


ก่อนอื่นขอขอบคุณสำหรับคำตอบของคุณฉันเข้าใจว่าสภาพปานกลางนั้นจะต้องคำนึงถึง แต่ฉันมีดิสก์สองชุดอยู่ในสภาพดีเยี่ยม (ไม่มีรอยขีดข่วนที่มองเห็นได้) และพฤติกรรมยังคงเหมือนเดิม ฉันยังมีซีดีรอมเกมรุ่นเก่าอื่น ๆ ในสภาพที่เลวร้ายที่สุดที่มี.subไฟล์สอดคล้องกันในการถ่ายโอนข้อมูลหลายครั้ง ฉันรู้ว่าฉันไม่ต้องการช่องสัญญาณย่อยเนื่องจากเกมไม่ได้รับการปกป้องฉันขอคำถามนี้ด้วยความอยากรู้ด้านเทคนิค :)
Chris

1
@ Christophe ฉันได้ขยายคำตอบของฉัน
Kamil Maciorowski

ฉันเข้าใจ. ฉันคิดว่ามันน่าสนใจที่จะมีข้อมูลข้อผิดพลาดสำหรับสื่อฉันสั่งไดรฟ์ Liteon iHAS124 และจะใช้ kprobe2 เพื่อตรวจสอบสิ่งนี้ พรุ่งนี้ฉันควรจะอัพเดท
Chris

ฉันเพิ่มผลลัพธ์การสแกนข้อผิดพลาด C1 ในคำถามของฉันดูเหมือนว่าจะดีสูงสุดคือ 25
Chris

1
@ Christophe ฉันได้ขยายคำตอบของฉันอีกครั้ง
Kamil Maciorowski
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.