मैंने चुंबकीय टेप से अज्ञात प्रारूप में डेटा कैसे पुनर्प्राप्त किया

पृष्ठभूमि

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

हालाँकि, कुछ कैसेटों पर मुझे ऐसी रिकॉर्डिंग मिलीं जो स्पष्ट रूप से ZX स्पेक्ट्रम कंप्यूटर द्वारा नहीं बनाई गई थीं। वे पूरी तरह से अलग लग रहे थे और उल्लिखित कंप्यूटर से रिकॉर्डिंग के विपरीत, वे एक छोटे बेसिक बूटलोडर से शुरू नहीं हुए थे, जो आमतौर पर सभी कार्यक्रमों और गेम की रिकॉर्डिंग में मौजूद होता है।

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

अब जब मैं पूरी तरह से चला गया हूं और कैसेट के लेबल को देखता हूं, तो मैं मुस्कुराता हूं

उत्तर हमेशा मेरी आँखों के सामने था
बाएं कैसेट के लेबल पर टीआरएस-80 कंप्यूटर का नाम है, और निर्माता के नाम के ठीक नीचे: "यूएसए में रेडियो शेक द्वारा निर्मित"

(यदि आप साज़िश को अंत तक बनाए रखना चाहते हैं, तो स्पॉइलर के तहत न जाएं)

ऑडियो संकेतों की तुलना

सबसे पहले, आइए ऑडियो रिकॉर्डिंग को डिजिटलाइज़ करें। आप सुन सकते हैं कि यह कैसा लगता है:

और हमेशा की तरह ZX स्पेक्ट्रम कंप्यूटर से रिकॉर्डिंग सुनाई देती है:

दोनों ही मामलों में, रिकॉर्डिंग की शुरुआत में एक तथाकथित होता है पायलट टोन - समान आवृत्ति की ध्वनि (पहली रिकॉर्डिंग में यह बहुत छोटी <1 सेकंड है, लेकिन अलग-अलग है)। पायलट टोन कंप्यूटर को डेटा प्राप्त करने के लिए तैयार होने का संकेत देता है। एक नियम के रूप में, प्रत्येक कंप्यूटर सिग्नल के आकार और उसकी आवृत्ति के आधार पर केवल अपने "अपने" पायलट टोन को पहचानता है।

सिग्नल के आकार के बारे में ही कुछ कहना जरूरी है. उदाहरण के लिए, ZX स्पेक्ट्रम पर इसका आकार आयताकार है:

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

सिंक पल्स प्राप्त होने के बाद, कंप्यूटर सिग्नल की प्रत्येक वृद्धि/गिरावट को रिकॉर्ड करता है, उसकी अवधि को मापता है। यदि अवधि एक निश्चित सीमा से कम है, तो बिट 1 को मेमोरी में लिखा जाता है, अन्यथा 0। बिट्स को बाइट्स में एकत्र किया जाता है और एन बाइट्स प्राप्त होने तक प्रक्रिया दोहराई जाती है। नंबर N आमतौर पर डाउनलोड की गई फ़ाइल के हेडर से लिया जाता है। लोडिंग क्रम इस प्रकार है:

1. पायलट टोन
2. हेडर (निश्चित लंबाई), डाउनलोड किए गए डेटा का आकार (एन), फ़ाइल नाम और प्रकार शामिल है
3. पायलट टोन
4. डेटा ही

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

तो, आइए अब देखें कि अज्ञात सिग्नल कैसा दिखता है:

यह पायलट टोन है. सिग्नल का आकार काफी अलग है, लेकिन यह स्पष्ट है कि सिग्नल में एक निश्चित आवृत्ति के दोहराए जाने वाले छोटे पल्स होते हैं। 44100 हर्ट्ज की नमूना आवृत्ति पर, "चोटियों" के बीच की दूरी लगभग 48 नमूने हैं (जो ~918 हर्ट्ज की आवृत्ति से मेल खाती है)। आइए इस आंकड़े को याद रखें।

आइए अब डेटा खंड को देखें:

यदि हम अलग-अलग दालों के बीच की दूरी को मापते हैं, तो यह पता चलता है कि "लंबी" दालों के बीच की दूरी अभी भी ~48 नमूने है, और छोटी दालों के बीच - ~24 है। थोड़ा आगे देखते हुए, मैं कहूंगा कि अंत में यह पता चला कि 918 हर्ट्ज की आवृत्ति के साथ "संदर्भ" दालें फ़ाइल की शुरुआत से अंत तक लगातार चलती रहती हैं। यह माना जा सकता है कि डेटा संचारित करते समय, यदि संदर्भ पल्स के बीच एक अतिरिक्त पल्स का सामना करना पड़ता है, तो हम इसे बिट 1 मानते हैं, अन्यथा 0.

सिंक पल्स के बारे में क्या? आइए डेटा की शुरुआत देखें:

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

आप सिंक बाइट में अंतिम 1 के तुरंत बाद पहले संदर्भ पल्स के बदलाव पर भी ध्यान दे सकते हैं। इसकी खोज बहुत बाद में डेटा पहचान कार्यक्रम विकसित करने की प्रक्रिया में हुई, जब फ़ाइल की शुरुआत में डेटा को स्थिर रूप से नहीं पढ़ा जा सका।

अब आइए एक एल्गोरिदम का वर्णन करने का प्रयास करें जो एक ऑडियो फ़ाइल को संसाधित करेगा और डेटा लोड करेगा।

डेटा लोड हो रहा है

सबसे पहले, आइए एल्गोरिदम को सरल बनाए रखने के लिए कुछ मान्यताओं पर नजर डालें:

1. हम केवल WAV प्रारूप में फ़ाइलों पर विचार करेंगे;
2. ऑडियो फ़ाइल पायलट टोन से शुरू होनी चाहिए और शुरुआत में मौन नहीं होना चाहिए
3. स्रोत फ़ाइल की नमूना दर 44100 हर्ट्ज़ होनी चाहिए। इस मामले में, 48 नमूनों के संदर्भ दालों के बीच की दूरी पहले से ही निर्धारित है और हमें इसे प्रोग्रामेटिक रूप से गणना करने की आवश्यकता नहीं है;
4. नमूना प्रारूप कोई भी हो सकता है (8/16 बिट/फ़्लोटिंग पॉइंट) - चूँकि पढ़ते समय हम इसे वांछित में बदल सकते हैं;
5. हम मानते हैं कि स्रोत फ़ाइल आयाम द्वारा सामान्यीकृत है, जिसे परिणाम को स्थिर करना चाहिए;

रीडिंग एल्गोरिदम इस प्रकार होगा:

1. हम फ़ाइल को मेमोरी में पढ़ते हैं, साथ ही नमूना प्रारूप को 8 बिट्स में परिवर्तित करते हैं;
2. ऑडियो डेटा में पहली पल्स की स्थिति निर्धारित करें। ऐसा करने के लिए, आपको अधिकतम आयाम के साथ नमूने की संख्या की गणना करने की आवश्यकता है। सरलता के लिए, हम इसकी गणना एक बार मैन्युअल रूप से करेंगे। आइए इसे prev_pos वेरिएबल में सहेजें;
3. अंतिम पल्स की स्थिति में 48 जोड़ें (स्थिति := prev_pos + 48)
4. चूँकि स्थिति को 48 तक बढ़ाने से यह गारंटी नहीं मिलती है कि हम अगले संदर्भ पल्स (टेप दोष, टेप ड्राइव तंत्र का अस्थिर संचालन, आदि) की स्थिति में पहुँच जाएंगे, हमें पल्स पॉज़ की स्थिति को समायोजित करने की आवश्यकता है। ऐसा करने के लिए, डेटा का एक छोटा सा टुकड़ा लें (pos-8;pos+8) और उस पर अधिकतम आयाम मान ज्ञात करें। अधिकतम के अनुरूप स्थिति पॉज़ में संग्रहीत की जाएगी। यहां 8 = 48/6 एक प्रयोगात्मक रूप से प्राप्त स्थिरांक है, जो गारंटी देता है कि हम सही अधिकतम निर्धारित करेंगे और आस-पास मौजूद अन्य आवेगों को प्रभावित नहीं करेंगे। बहुत बुरे मामलों में, जब पल्स के बीच की दूरी 48 से बहुत कम या अधिक होती है, तो आप पल्स के लिए एक मजबूर खोज को लागू कर सकते हैं, लेकिन लेख के दायरे में मैं एल्गोरिदम में इसका वर्णन नहीं करूंगा;
5. पिछले चरण में, यह जांचना भी आवश्यक होगा कि संदर्भ पल्स बिल्कुल पाया गया था या नहीं। अर्थात्, यदि आप केवल अधिकतम की तलाश करते हैं, तो यह गारंटी नहीं देता है कि आवेग इस खंड में मौजूद है। रीडिंग प्रोग्राम के मेरे नवीनतम कार्यान्वयन में, मैं एक खंड पर अधिकतम और न्यूनतम आयाम मूल्यों के बीच अंतर की जांच करता हूं, और यदि यह एक निश्चित सीमा से अधिक है, तो मैं एक आवेग की उपस्थिति की गणना करता हूं। सवाल यह भी है कि यदि रेफरेंस पल्स न मिले तो क्या करें। 2 विकल्प हैं: या तो डेटा समाप्त हो गया है और चुप्पी आ गई है, या इसे पढ़ने में त्रुटि माना जाना चाहिए। हालाँकि, एल्गोरिथ्म को सरल बनाने के लिए हम इसे छोड़ देंगे;
6. अगले चरण में, हमें डेटा पल्स (बिट 0 या 1) की उपस्थिति निर्धारित करने की आवश्यकता है, इसके लिए हम खंड के मध्य (prev_pos;pos) के मध्य_pos को मध्य_pos के बराबर लेते हैं: = (prev_pos+pos)/2 और खंड पर मध्य_पोस के कुछ पड़ोस में (मध्य_पोस-8; मध्य_पोस +8) आइए अधिकतम और न्यूनतम आयाम की गणना करें। यदि उनके बीच का अंतर 10 से अधिक है, तो हम परिणाम में बिट 1 लिखते हैं, अन्यथा 0. 10 प्रयोगात्मक रूप से प्राप्त एक स्थिरांक है;
7. वर्तमान स्थिति को prev_pos में सहेजें (prev_pos := pos)
8. चरण 3 से शुरू करके तब तक दोहराएँ जब तक हम पूरी फ़ाइल नहीं पढ़ लेते;
9. परिणामी बिट सरणी को बाइट्स के सेट के रूप में सहेजा जाना चाहिए। चूँकि हमने पढ़ते समय सिंक बाइट को ध्यान में नहीं रखा, इसलिए बिट्स की संख्या 8 से अधिक नहीं हो सकती है, और आवश्यक बिट ऑफसेट भी अज्ञात है। एल्गोरिदम के पहले कार्यान्वयन में, मुझे सिंक बाइट के अस्तित्व के बारे में पता नहीं था और इसलिए अलग-अलग संख्या में ऑफ़सेट बिट्स के साथ 8 फ़ाइलों को सहेजा गया था। उनमें से एक में सही डेटा था। अंतिम एल्गोरिदम में, मैं बस A5h तक के सभी बिट्स को हटा देता हूं, जो मुझे तुरंत सही आउटपुट फ़ाइल प्राप्त करने की अनुमति देता है

रुचि रखने वालों के लिए रूबी में एल्गोरिदम
मैंने प्रोग्राम लिखने के लिए रूबी को भाषा के रूप में चुना, क्योंकि... मैं ज्यादातर समय इस पर प्रोग्राम करता हूं। विकल्प उच्च-प्रदर्शन वाला नहीं है, लेकिन पढ़ने की गति को यथासंभव तेज़ बनाने का कार्य इसके लायक नहीं है।

# Используем gem 'wavefile'
require 'wavefile'

reader = WaveFile::Reader.new('input.wav')
samples = []
format = WaveFile::Format.new(:mono, :pcm_8, 44100)

# Читаем WAV файл, конвертируем в формат Mono, 8 bit 
# Массив samples будет состоять из байт со значениями 0-255
reader.each_buffer(10000) do |buffer|
  samples += buffer.convert(format).samples
end

# Позиция первого импульса (вместо 0)
prev_pos = 0
# Расстояние между импульсами
distance = 48
# Значение расстояния для окрестности поиска локального максимума
delta = (distance / 6).floor
# Биты будем сохранять в виде строки из "0" и "1"
bits = ""

loop do
  # Рассчитываем позицию следующего импульса
  pos = prev_pos + distance
  
  # Выходим из цикла если данные закончились 
  break if pos + delta >= samples.size

  # Корректируем позицию pos обнаружением максимума на отрезке [pos - delta;pos + delta]
  (pos - delta..pos + delta).each { |p| pos = p if samples[p] > samples[pos] }

  # Находим середину отрезка [prev_pos;pos]
  middle_pos = ((prev_pos + pos) / 2).floor

  # Берем окрестность в середине 
  sample = samples[middle_pos - delta..middle_pos + delta]

  # Определяем бит как "1" если разница между максимальным и минимальным значением на отрезке превышает 10
  bit = sample.max - sample.min > 10
  bits += bit ? "1" : "0"
end

# Определяем синхро-байт и заменяем все предшествующие биты на 256 бит нулей (согласно спецификации формата) 
bits.gsub! /^[01]*?10100101/, ("0" * 256) + "10100101"

# Сохраняем выходной файл, упаковывая биты в байты
File.write "output.cas", [bits].pack("B*")

परिणाम

एल्गोरिथम और स्थिरांक के कई प्रकारों को आज़माने के बाद, मैं कुछ बेहद दिलचस्प पाने के लिए भाग्यशाली था:

तो, चरित्र स्ट्रिंग्स को देखते हुए, हमारे पास ग्राफ़ बनाने के लिए एक कार्यक्रम है। हालाँकि, प्रोग्राम टेक्स्ट में कोई कीवर्ड नहीं हैं। सभी कीवर्ड बाइट्स के रूप में एन्कोड किए गए हैं (प्रत्येक मान > 80 घंटे)। अब हमें यह पता लगाना होगा कि 80 के दशक का कौन सा कंप्यूटर इस प्रारूप में प्रोग्राम सहेज सकता है।

वास्तव में, यह एक बेसिक प्रोग्राम के समान ही है। ZX स्पेक्ट्रम कंप्यूटर प्रोग्राम को मेमोरी में लगभग समान प्रारूप में संग्रहीत करता है और प्रोग्राम को टेप में सहेजता है। बस मामले में, मैंने कीवर्ड की जाँच की मेज़. हालाँकि, परिणाम स्पष्ट रूप से नकारात्मक था।

मैंने उस समय के लोकप्रिय अटारी, कमोडोर 64 और कई अन्य कंप्यूटरों के बेसिक कीवर्ड की भी जांच की, जिसके लिए मैं दस्तावेज़ ढूंढने में सक्षम था, लेकिन सफलता नहीं मिली - रेट्रो कंप्यूटर के प्रकारों के बारे में मेरा ज्ञान इतना व्यापक नहीं था।

फिर मैंने जाने का फैसला किया सूची, और फिर मेरी नज़र निर्माता रेडियो शेक और टीआरएस-80 कंप्यूटर के नाम पर पड़ी। ये वो नाम हैं जो मेरी मेज़ पर पड़े कैसेट के लेबल पर लिखे थे! मैं पहले इन नामों को नहीं जानता था और टीआरएस-80 कंप्यूटर से परिचित नहीं था, इसलिए मुझे ऐसा लगा कि रेडियो शेक बीएएसएफ, सोनी या टीडीके जैसे ऑडियो कैसेट निर्माता था, और टीआरएस-80 प्लेबैक का समय था। क्यों नहीं?

कंप्यूटर टैंडी/रेडियो शैक टीआरएस-80

यह बहुत संभव है कि विचाराधीन ऑडियो रिकॉर्डिंग, जिसे मैंने लेख की शुरुआत में एक उदाहरण के रूप में दिया था, इस तरह कंप्यूटर पर बनाई गई थी:

यह पता चला कि यह कंप्यूटर और इसकी किस्में (मॉडल I/मॉडल III/मॉडल IV, आदि) एक समय में बहुत लोकप्रिय थीं (बेशक, रूस में नहीं)। गौरतलब है कि उन्होंने जो प्रोसेसर इस्तेमाल किया था वह भी Z80 था। इस कंप्यूटर के लिए आप इंटरनेट पर पा सकते हैं बहुत सारी जानकारी. 80 के दशक में, कंप्यूटर जानकारी वितरित की गई थी पत्रिका. फिलहाल तो कई हैं emulators विभिन्न प्लेटफार्मों के लिए कंप्यूटर।

मैंने एम्यूलेटर डाउनलोड किया trs80gp और पहली बार मैं देख पाया कि यह कंप्यूटर कैसे काम करता है। बेशक, कंप्यूटर रंग आउटपुट का समर्थन नहीं करता था; स्क्रीन रिज़ॉल्यूशन केवल 128x48 पिक्सेल था, लेकिन कई एक्सटेंशन और संशोधन थे जो स्क्रीन रिज़ॉल्यूशन को बढ़ा सकते थे। इस कंप्यूटर के लिए ऑपरेटिंग सिस्टम के कई विकल्प और बेसिक भाषा को लागू करने के विकल्प भी थे (जो, ZX स्पेक्ट्रम के विपरीत, कुछ मॉडलों में ROM में "फ्लैश" भी नहीं किया गया था और किसी भी विकल्प को फ्लॉपी डिस्क से लोड किया जा सकता था, जैसे ओएस ही)

मैंने भी पाया उपयोगिता ऑडियो रिकॉर्डिंग को CAS प्रारूप में परिवर्तित करने के लिए, जो एमुलेटर द्वारा समर्थित है, लेकिन किसी कारण से उनका उपयोग करके मेरे कैसेट से रिकॉर्डिंग पढ़ना संभव नहीं था।

सीएएस फ़ाइल प्रारूप का पता लगाने के बाद (जो मेरे पास पहले से मौजूद टेप से डेटा की एक बिट-दर-बिट कॉपी थी, सिंक बाइट की उपस्थिति वाले हेडर को छोड़कर), मैंने एक बनाया मेरे प्रोग्राम में कुछ बदलाव हुए और मैं एक कार्यशील CAS फ़ाइल को आउटपुट करने में सक्षम हुआ जो एमुलेटर (TRS-80 मॉडल III) में काम करती थी:

मैंने GEM पैकेज के रूप में पहली पल्स और संदर्भ पल्स के बीच की दूरी के स्वचालित निर्धारण के साथ रूपांतरण उपयोगिता का नवीनतम संस्करण डिज़ाइन किया है, स्रोत कोड यहां उपलब्ध है Github.

निष्कर्ष

हमने जिस रास्ते पर यात्रा की वह अतीत की एक आकर्षक यात्रा बन गई और मुझे खुशी है कि अंत में मुझे इसका उत्तर मिल गया। अन्य बातों के अलावा, मैं:

• मैंने ZX स्पेक्ट्रम में डेटा को सहेजने के प्रारूप का पता लगाया और ऑडियो कैसेट से डेटा को सहेजने/पढ़ने के लिए अंतर्निहित ROM रूटीन का अध्ययन किया।
• मैं टीआरएस-80 कंप्यूटर और उसकी किस्मों से परिचित हुआ, ऑपरेटिंग सिस्टम का अध्ययन किया, नमूना कार्यक्रमों को देखा और यहां तक ​​कि मशीन कोड में डिबगिंग करने का अवसर भी मिला (आखिरकार, सभी Z80 निमोनिक्स मुझसे परिचित हैं)
• ऑडियो रिकॉर्डिंग को CAS प्रारूप में परिवर्तित करने के लिए एक पूर्ण उपयोगिता लिखी, जो "आधिकारिक" उपयोगिता द्वारा मान्यता प्राप्त नहीं किए गए डेटा को पढ़ सकती है

स्रोत: www.habr.com