एक ही डिस्क को डंप करते समय CD-ROM सबचैनेल अलग है?

मैं अपने विंडोज 10 x64 कंप्यूटर पर सैमसंग SH-S223L ड्राइव के साथ क्लोन वीडियो 5.3.3.0 के साथ पुराने वीडियो गेम की बैकअप प्रतियां बना रहा हूं।

उनमें से एक पीसी (डियाब्लो 1 विस्तार) के लिए हेलफायर है:

डिस्क में एक COMPACT disc DATA STORAGEलोगो है
क्रमांक: S0011770
फैक्टरी सिड-कोड: IFPI 1218
सीडी-मास्टर सिड-कोड: IFPI L032
आईएसओ 9660 पीवीडी निर्माण तिथि: 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 चेकसम और इस सत्यापित करने के लिए एक हेक्स संपादक।
मैंने यहां दो .subफ़ाइल डंप अपलोड किए हैं ।
मुझे यह उल्लेख करना होगा कि इस डिस्क की दो प्रतियाँ हैं और दोनों डिस्क के साथ व्यवहार समान है।

मैंने कई अन्य सीडी-रॉम मीडिया को भी डंप किया, कभी-कभी मुझे यह व्यवहार मिलता है कभी-कभी सबचैन डंप के अनुरूप होता है।

इस व्यवहार की व्याख्या क्या है?

संपादित करें:

मैंने लाइट-ऑन iH124-14 ड्राइव के साथ एक ही सीडी-रॉम को फिर से डंप किया और मुझे एक ही व्यवहार (विभिन्न .subफाइलें) दिखाई देती हैं।
मैंने KProbe 2 के साथ त्रुटियों के लिए माध्यम की भी जाँच की और मुझे निम्न परिणाम मिले:

संपादित करें:

ऐसा लगता है कि डिस्क की स्थिति और / या ड्राइव की शुद्धता की कमी इस तथ्य से जुड़ गई है कि सबचैनल में त्रुटि नियंत्रण तंत्र नहीं है (क्यू चैनल को छोड़कर) बताते हैं कि .subएक ही माध्यम से कई बार डंप करने पर मुझे अलग-अलग फाइलें क्यों मिलती हैं ।

मुझे यह उल्लेख करना है कि मुझे Plextor PX-712A ड्राइव भी मिला है और डिस्क निर्माता क्रिएटर.sub का उपयोग करके डंप के पार लगातार फाइलें प्राप्त करने में कामयाब रहा है । यह सॉफ़्टवेयर डिस्क को पढ़ने के लिए निर्देशों के बजाय निर्देशों का लाभ उठाता है , जिसके परिणामस्वरूप अधिक सटीक छवियां होती हैं। केवल कुछ ड्राइव (ज्यादातर Plextor) इस निर्देश का समर्थन करते हैं।0xD80xBE

इसके अलावा, मैं वास्तव में इस सीडी-रॉम की दो भौतिक प्रतियां (मैं एक ही सीरियल नंबर, एक ही IFPI कोड और एक ही लेजर उत्कीर्णन जानकारी) हूं। अगर मैं डिस्क डिस्क क्रिएटर के साथ एक ही डिस्क को कई बार .subडंप करता हूं तो मुझे लगातार फाइलें मिलती हैं लेकिन अगर मैं पहली डिस्क और फिर दूसरी डिस्क को डंप करता हूं।
मुझे लगता है कि यह मीडिया की स्थितियों से संबंधित है क्योंकि उनमें से एक में कुछ खरोंच और अधिक सी 1 / सी 2 त्रुटियां हैं।

— क्रिस
स्रोत

रीड एरर (गंदगी, खरोंच, जरूरी नहीं कि ड्राइव से वास्तविक त्रुटियां) सीडीरॉम छवियों को अलग कर सकती हैं। अंतर कुछ बिट्स जितना कम हो सकता है; 1 बिट अंतर SHA * / MD5 चेकसम के लिए पर्याप्त है।

— क्विक्सोटिक

जवाबों:

विभिन्न सीडी प्रारूप थोड़े से शामिल हैं, और आधिकारिक विनिर्देश (ऑडियो सीडी के लिए "लाल किताब", डेटा सीडी के लिए "पीली किताब") स्वतंत्र रूप से उपलब्ध नहीं हैं। लेकिन आप उपलब्ध मानकों जैसे एक्मा -130 में कुछ विवरण पा सकते हैं।

मूल ऑडियो सीडी (जिसे सीडी-डीए भी कहा जाता है) विनाइल रिकॉर्ड पर मॉडलिंग की गई थी, जिसका अर्थ है कि यह भी उपयोग करता है निरंतर ऑडियो डेटा का एक सर्पिल ट्रैक (डीवीडी बाद में परिपत्र पटरियों का उपयोग करता है)। इस ऑडियो डेटा के भीतर एक बहुत ही जटिल तरीके से परस्पर जुड़े 8 सबचैनल्स (P से W) हैं, जिनमें से क्यू सबचैनल में समय की जानकारी (शाब्दिक रूप से मिनटों / सेकंड / अंशों में) और वर्तमान ट्रैक नंबर हैं। मूल उद्देश्य के लिए यह पर्याप्त था: लगातार खेलने के लिए, लेंस को ट्रैक का पालन करने के लिए थोड़ा समायोजित किया गया था। तलाश करने के लिए, जब तक सही ट्रैक नहीं मिला, तब तक क्यू सबचैन को डिकोड करते समय लेंस हिल जाता। यह स्थिति थोड़ी कठिन है, लेकिन संगीत सुनने के लिए पूरी तरह से पर्याप्त है।

आज भी, कई कंप्यूटर सीडी ड्राइव पूरी तरह से लेंस की स्थिति को ठीक से निर्धारित नहीं कर सकते हैं और डिकोडिंग सर्किट्री को सिंक्रनाइज़ कर सकते हैं ताकि ऑडियो नमूनों का पढ़ना एक सटीक स्थिति में शुरू हो। यही कारण है कि कई सीडी तेजस्वी कार्यक्रमों में एक "व्यामोह" मोड है, जहां वे ओवरलैपिंग पढ़ते हैं और इस "घबराहट" के लिए समायोजित करने के लिए परिणामों की तुलना करते हैं। ऑडियो स्ट्रीम के हिस्से के रूप में, सबचैनेल भी घबराहट के अधीन है, और इसीलिए जब आप सीडी ड्राइव पर चीरते हैं तो आपको अलग-अलग सबचैनल फाइलें मिलती हैं जो सही स्थिति में नहीं आ सकती हैं।

जब CD-DA विनिर्देशन का विस्तार करने के लिए डेटा CD (CD-ROM) विनिर्देशन विकसित किया गया था, तो डेटा को सटीक रूप से संबोधित करने और पढ़ने के लिए महत्व को मान्यता दी गई थी, इसलिए 2352 बाइट के ऑडियो फ्रेम को 12 सिंक बाइट्स और 4 हेडर बाइट्स में विभाजित किया गया था (के लिए सेक्टर का पता), डेटा के लिए शेष 2336 बाइट्स और त्रुटि सुधार का एक अतिरिक्त स्तर छोड़ रहा है। इस योजना का उपयोग करते हुए, केवल Q चैनल की जानकारी पर भरोसा किए बिना क्षेत्रों को संबोधित किया जा सकता है। इसलिए घबराना प्रभाव लागू नहीं होता है, सीडी-रॉम को डंप करने पर आपको हमेशा वही डेटा मिलता है, और डंपिंग में कोई अतिरिक्त चतुराई की आवश्यकता नहीं होती है।

अधिक विवरण के साथ संपादित करें :

के अनुसार ऐक्मा -130 , डेटा चरणों से अव्यवस्थित: 24 बाइट्स एक बनाने के एफ 1-फ्रेम , इन फ्रेम के 106 बाइट्स 106 में वितरित कर रहे हैं F2-फ्रेम्स , जो त्रुटि सुधार के 8 अतिरिक्त बाइट्स मिलता है। बारी-बारी से उन फ़्रेमों को एफ 3-फ्रेम्स में बनाने के लिए एक अतिरिक्त बाइट ("कंट्रोल बाइट") मिलता है । अतिरिक्त बाइट में सबचैनल जानकारी (प्रत्येक बिट स्थिति के लिए एक सबचैनल) होती है। 98 F3- फ्रेम्स के एक समूह को एक सेक्शन कहा जाता है , और 98 संबंधित कंट्रोल बाइट्स में दो सिंक बाइट्स और 96 बाइट्स वास्तविक सबचैनल डेटा होते हैं। इसके अलावा क्यू सबचैनेल में उन 96 बिट्स में 16 बिट्स सीआरसी त्रुटि सुधार है।

इसके पीछे विचार यह है कि डिस्क की सतह पर डेटा को इस तरह से वितरित किया जाए कि खरोंच, गंदगी आदि कई निरंतर बिट्स को प्रभावित न करें, इसलिए त्रुटि सुधार खोए हुए डेटा को पुनर्प्राप्त कर सकता है जब तक कि खरोंच नहीं होते हैं बहुत बड़ा।

परिणामस्वरूप, सीडी ड्राइव हार्डवेयर को लेंस का स्थान बदलने के बाद एक पूर्ण खंड को पढ़ने की जरूरत है ताकि यह पता लगाया जा सके कि यह डेटा स्ट्रीम में कहां है। विभिन्न चरणों का अवरोहण हार्डवेयर द्वारा किया जाता है, जिसे नियंत्रण-बाइट स्ट्रीम में 2 सिंक बाइट्स के साथ सिंक करने की आवश्यकता होती है। सभी सीडी ड्राइव मॉडल को अन्य मॉडलों की तुलना में सिंक करने के लिए अलग-अलग समय की आवश्यकता होती है (आप परीक्षण कर सकते हैं कि दो अलग-अलग ड्राइव से पढ़कर, यदि आपके पास है), तो हार्डवेयर कैसे लागू किया जाता है। इसके अलावा, कई मॉडल हमेशा सिंक करने के लिए सटीक समान समय नहीं लेते हैं, इसलिए वे थोड़ा जल्दी या देर से शुरू कर सकते हैं, और अवरोही डेटा को हमेशा एक ही बाइट पर आउटपुट नहीं कर सकते हैं।

इसलिए जब रिपिंग प्रोग्राम एक READ CD(0xBE) कमांड जारी करता है, तो यह ट्रांसफर लेंथ और एक स्टार्ट एड्रेस (या बल्कि, क्यू-चैनल) की आपूर्ति करता है। ड्राइव लेंस को स्थिति देता है, फ़्रेम को अवरूद्ध करता है, क्यू-चैनल को निकालता है, समय की तुलना करता है, और जब यह सही समय पाता है, तो यह स्थानांतरण करना शुरू कर देता है। यह स्थानांतरण हमेशा एक ही बाइट पर शुरू नहीं होता है जैसा कि ऊपर बताया गया है, इसलिए कई READ CDआदेशों का परिणाम एक दूसरे के खिलाफ स्थानांतरित किया जा सकता है। यही कारण है कि आप अपने आरा से अलग सबचैनल फाइलें देखते हैं।

हार्डवेयर और परिस्थितियों के आधार पर जब लेंस समायोजित किया जाता है, तो यह अधिक या कम यादृच्छिक होता है यदि स्थानांतरण कुछ नमूने जल्दी या कुछ नमूने देर से शुरू होते हैं। तो परिणामों में आप देखेंगे केवल एक ही पैटर्न यह है कि स्थानांतरण स्थानांतरण लंबाई के एक से अधिक हैं।

कुछ ड्राइव मॉडल में वास्तव में सटीक हार्डवेयर होते हैं जो हमेशा एक ही समय में स्थानांतरण शुरू करेंगे। मानक मोड पृष्ठ 0x2a ("सीडी / डीवीडी क्षमताओं और मैकेनिकल स्थिति पृष्ठ") में थोड़ा परिभाषित करता है जो इंगित करता है कि अगर ऐसा है, लेकिन वास्तविक दुनिया के अनुभव से पता चलता है कि सटीक होने का दावा करने वाले कुछ ड्राइव वास्तव में नहीं हैं। (लिनक्स के तहत, आप मोड पेजों को पढ़ने के sg_modesलिए sg3-utilesपैकेज से उपयोग कर सकते हैं , मुझे नहीं पता कि विंडोज के तहत किस टूल का उपयोग करना है)।

— dirkt
स्रोत

आपके उत्तर के लिए धन्यवाद, यह मुझे कुछ अंतरंग संदर्भ देता है। मैं समझता हूं कि मुझे डिस्क से उचित डेटा प्राप्त करने के लिए सबचैनल की आवश्यकता नहीं है, मैं बस सोच रहा हूं कि सबचैनलाइन खुद ही पूरे डंप के अनुरूप क्यों नहीं है।

— क्रिस

हां, मैंने यह समझाने की कोशिश की कि सबचैनलाइन क्यों सुसंगत नहीं है: आप सबचैन सहित "कच्चे" डेटा को पढ़ने के लिए डिस्क को कमांड भेजते हैं, और पोजिशनिंग सटीक नहीं है, इसलिए ऐसा हो सकता है कि पढ़ना अलग-अलग बिंदुओं पर शुरू हो। यदि आप पढ़े गए डेटा की तुलना करते हैं, तो आप देखेंगे कि भागों को स्थानांतरित कर दिया गया है। OTOH, CD-ROM डेटा में ही यह समस्या नहीं है। और आपको यह समझने के लिए संदर्भ की आवश्यकता है कि स्थिति सटीक क्यों नहीं है (हालांकि आपको सटीक कारण के लिए और भी अधिक संदर्भ की आवश्यकता होगी , जो मैंने नहीं जाना था)।

— dirkt

अगर यह संभव है, तो मुझे इसकी सही वजह जानने में दिलचस्पी है। मैंने .subअपने प्रश्न में फ़ाइलों का डाउनलोड लिंक जोड़ा है । मैंने इसकी तुलना एक हेक्स संपादक के साथ की और आप सही हैं कि डेटा को स्थानांतरित कर दिया गया है, मुझे कोई स्पष्ट पैटर्न नहीं मिल सकता है।

— क्रिस

बहुत दिलचस्प, धन्यवाद। मैंने cygwin स्थापित किया, sg3-utils और भाग गया sg_modes। मेरे पास 0x2a"MM क्षमताओं और यांत्रिक स्थिति (अप्रचलित)" अनुभाग है। मैं कल एक नई लाइटन ड्राइव प्राप्त करूंगा और यह देखने के लिए फिर से परीक्षण करूंगा कि क्या मुझे डंप भर में सबचेनलाइन मिला है।

— क्रिस

कोडपेज की उपस्थिति का कोई मतलब नहीं है, आपको सही बिट (6 वीं बाइट के बिट 1, "सीडी-डीए स्ट्रीम सटीक है") को देखना होगा। यदि आपके पास दो ड्राइव हैं, तो एक ऑडियो सीडी को पकड़ो, इसे दोनों ड्राइव पर रिप करें और डेटा की तुलना करें। आपको अलग-अलग स्थान देखना चाहिए जहां वास्तविक गैर-शून्य डेटा शुरू होता है। आप शायद दो ड्राइव के बीच सबचैनल फ़ाइलों के लिए अलग-अलग ऑफ़सेट भी देखेंगे।

— dirkt

इस विकिपीडिया लेख के अनुसार

एक फ़्रेम में 33 बाइट्स होते हैं, जिनमें से 24 बाइट्स ऑडियो या उपयोगकर्ता डेटा होते हैं, आठ बाइट्स एरर करेक्शन (CIRC- जनरेट किए गए) होते हैं, और एक बाइट सबकोड के लिए होती है।

इससे पता चलता है कि सबचैन के लिए कोई त्रुटि सुधार नहीं है।

मुझे अन्य प्रश्न भी कहीं और मिले हैं । यह ऑडियो सीडी के बारे में है, लेकिन मुझे लगता है कि यह सही मुद्दे को संबोधित करता है:

मैं बस इतना ही कह सकता हूं कि मैंने एक ही सीडी-डीए / सीडी-पाठ से पढ़ते समय दो समान सबचेन रीडिंग (* .SUB फ़ाइल) प्राप्त करने में कामयाबी नहीं पाई है। क्या रॉ मोड में पढ़ते समय सामान्य है क्योंकि डेटा को सही नहीं किया गया है क्योंकि CD-DA / CD-TEXT प्रारूप सभी सबचैन में EDC / ECC नहीं ले जाता है?

वहां का जवाब:

केवल ऑडियो डेटा रीड-सोलोमन कोडिंग (सी 1 और सी 2) के अधीन है। सबकोड चैनल डेटा (चैनल पी ... डब्ल्यू) इंटरलेविंग या त्रुटि सुरक्षा के अधीन नहीं हैं।

हालांकि dirkt आपके प्रश्न के किसी अन्य उत्तर में सही हो सकता है, जिसे आपको .subफ़ाइलों की आवश्यकता नहीं हो सकती है , उत्तर आपके प्रश्न को स्पष्ट रूप से संबोधित नहीं करता है:

इस व्यवहार की व्याख्या क्या है?

मेरा उत्तर: आपको अलग .sub- अलग फाइलें मिलती हैं क्योंकि सबचैनल्स में त्रुटि सुधार नहीं होता है। ऑडियो या उपयोगकर्ता डेटा पढ़ते समय त्रुटियों को ठीक किया जाता है (या कम से कम पता लगाया जाता है), लेकिन एक पढ़ने में त्रुटि तब हो सकती है, जब यह सबचैनल बिट पर होती है। खरोंच या धूल के कारण विशेष त्रुटियां एक पढ़ने के सत्र के दौरान दिखाई दे सकती हैं, दूसरे के दौरान दिखाई नहीं देती हैं - इसलिए .subफाइलें जो भिन्न होती हैं।

टिप्पणी को संबोधित करने के लिए उत्तर का विस्तार:

मेरे पास इस डिस्क की दो प्रतियां हैं जो उत्कृष्ट स्थिति में हैं (कोई दिखाई देने वाली खरोंच नहीं) और व्यवहार अभी भी समान है। मेरे पास अन्य पुराने गेम सीडी-रोम सबसे खराब स्थिति में हैं जो .subकई डंपों में लगातार फाइल करते हैं।

मुझे संदेह है (दुर्भाग्य से बिना कठिन साक्ष्य के) हालांकि अलग-अलग सीडी अलग-अलग गुणवत्ता के साथ निर्मित किए गए होंगे। ऐसे मामले में जब सबचैनल्स कोई फर्क नहीं पड़ता, निचली गुणवत्ता की डिस्क अभी भी केवल डेटा असंगति का पता लगाने के लिए डिज़ाइन किए गए गुणवत्ता परीक्षण पास कर सकती है। या यह केवल संभाव्य मामला हो सकता है: एक डिस्क का अपना कमजोर स्थान होता है (थोड़ा सा जो असंगत रीडिंग देता है) जहां त्रुटि सुधार इसे ठीक कर सकता है; एक और होता है यह सबचैननेल क्षेत्र में होता है।

इस तरह की एक सबचैनल बिट आपको अलग-अलग चेकसम देने के लिए पर्याप्त है, जबकि उपयोगकर्ता डेटा क्षेत्र में भी हजारों "अनिर्धारित" बिट्स को जरूरत पड़ने पर चुपचाप ठीक किया जा सकता है, यदि केवल उन्हें पर्याप्त वितरित किया जाता है, तो त्रुटि सुधार एल्गोरिथ्म भी नहीं के साथ संबंधित है- एक समय में बहुत कुछ।

KProbe 2 परिणामों की प्रतिक्रिया में विस्तारित उत्तर।

जहां तक मुझे पता है कि सी 1 त्रुटियों की अनुमति है (कुछ मात्रा के लिए) क्योंकि वे चुपचाप सही किए जाते हैं ( यहां अधिक )। यह सुधार त्रुटि सुधार बिट्स के कारण काम करता है। जैसा कि मैंने पहले कहा था, सबचैनल्स में सामान्य रूप से ऐसी अतिरेक नहीं होता है ( d -tt में Q- subchannel CRC त्रुटि सुधार का उल्लेख है लेकिन यह मेरे निष्कर्ष में बहुत अधिक परिवर्तन नहीं करता है)। इसके अलावा अगर त्रुटि वहां होती है, तो इसे जानने का कोई तरीका नहीं है, जब तक कि आपको पहले से पता न हो कि सही सबचैनल डेटा क्या है।

तो आपके पास कुल 1855 त्रुटियां थीं जिनके बारे में आप जानते हैं। परीक्षण को दोहराएं (गंभीरता से, इसे करें!) और आपके पास 1790 त्रुटियां हो सकती हैं; या 1892. फिर भी सही आउटपुट हर बार पढ़ने के दौरान समान होता है।

अगर हर 32 डेटा बिट्स के लिए एक सबचैनल बिट है, तो मैं कहता हूं कि आपके पास लगभग 1855/32 सबचैन बिट्स हैं जो कि अनडेटेड एरर के साथ पढ़े गए थे। वह लगभग 58 बिट्स है। खैर, लगभग, क्योंकि क्यू-सबचैनेल सीआरसी के लिए धन्यवाद, इनमें से कुछ त्रुटियों को कम से कम पता लगाया जा सकता है। चूंकि क्यू आठ सबचैनल्स में से एक है, मुझे लगता है कि आप अन्य सबचैनल्स में लगभग 50 गलत बिट्स के साथ छोड़ दिए गए हैं। अगली बार जब आप पढ़ेंगे तो आपको बिना किसी त्रुटि के इनमें से कुछ बिट्स मिल सकते हैं, और कुछ नई सबचेंनल त्रुटियां कहीं और मिल सकती हैं। तो आपको अलग .subफाइल मिलेगी । और फिर भी आप यह नहीं जान पाएंगे कि उन बिट्स में से कौन सा पहली बार सही ढंग से पढ़ा गया या दूसरा।

— कामिल मैकियोरोव्स्की
स्रोत

आपके उत्तर के लिए सबसे पहले धन्यवाद, मैं समझता हूं कि मध्यम स्थिति को ध्यान में रखना है, लेकिन मेरे पास इस डिस्क की दो प्रतियां हैं जो एक उत्कृष्ट स्थिति में हैं (कोई दृश्य खरोंच नहीं) और व्यवहार अभी भी समान है। मेरे पास अन्य पुराने गेम सीडी-रोम सबसे खराब स्थिति में हैं जो .subकई डंपों में लगातार फाइल करते हैं। मुझे पता है कि मुझे यह बताने की ज़रूरत नहीं है कि खेल को संरक्षित नहीं किया गया है, मैं यह सवाल तकनीकी जिज्ञासा से पूछ रहा हूं :)।

— क्रिस

@ चित्रपट मैंने अपने उत्तर का विस्तार किया है।

— कामिल मैकियोरोस्की

मै समझता हुँ। मुझे लगता है कि माध्यम के लिए त्रुटि जानकारी रखना दिलचस्प हो सकता है, मैंने लाइटन iHAS124 ड्राइव का आदेश दिया और इसे जांचने के लिए kprobe2 का उपयोग करेगा। मुझे इस पर कल अपडेट करना चाहिए।

— क्रिस

मैंने अपने प्रश्न में C1 त्रुटि स्कैन परिणाम को जोड़ा, यह अच्छा लगता है, अधिकतम 25 है।

— क्रिस

@Christophe मैंने फिर से अपने उत्तर का विस्तार किया है।

— कामिल मैकियोरोस्की