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

prehistory

रेट्रो हार्डवेअरचा प्रेमी असल्याने, मी एकदा UK मधील विक्रेत्याकडून ZX Spectrum+ खरेदी केले. संगणकासहच, मला गेमसह अनेक ऑडिओ कॅसेट्स (सूचनांसह मूळ पॅकेजिंगमध्ये), तसेच विशेष चिन्हांशिवाय कॅसेटवर रेकॉर्ड केलेले प्रोग्राम प्राप्त झाले. आश्चर्याची गोष्ट म्हणजे, 40 वर्षांच्या कॅसेटमधील डेटा चांगला वाचनीय होता आणि मी त्यांच्याकडून जवळजवळ सर्व गेम आणि प्रोग्राम डाउनलोड करण्यास सक्षम होतो.

तथापि, काही कॅसेटवर मला रेकॉर्डिंग आढळले जे स्पष्टपणे ZX स्पेक्ट्रम संगणकाद्वारे बनवलेले नव्हते. ते पूर्णपणे भिन्न वाटत होते आणि, नमूद केलेल्या संगणकावरील रेकॉर्डिंगच्या विपरीत, त्यांनी लहान बेसिक बूटलोडरसह प्रारंभ केला नाही, जो सहसा सर्व प्रोग्राम्स आणि गेमच्या रेकॉर्डिंगमध्ये उपस्थित असतो.

काही काळ याने मला पछाडले - मला त्यांच्यात काय दडले आहे ते शोधायचे होते. जर तुम्ही ऑडिओ सिग्नल बाइट्सचा क्रम म्हणून वाचू शकत असाल, तर तुम्ही अक्षरे किंवा सिग्नलची उत्पत्ती दर्शवणारी कोणतीही गोष्ट शोधू शकता. एक प्रकारचे रेट्रो-पुरातत्व.

आता मी सर्व मार्गाने गेलो आणि स्वतः कॅसेटची लेबले पाहिली, कारण मला हसू आले

उत्तर अगदी माझ्या डोळ्यासमोर होते
डाव्या कॅसेटच्या लेबलवर TRS-80 संगणकाचे नाव आहे आणि निर्मात्याच्या नावाच्या खाली आहे: “यूएसए मधील रेडिओ शॅकद्वारे उत्पादित”

(जर तुम्हाला शेवटपर्यंत कारस्थान ठेवायचे असेल तर, बिघडवणाऱ्याच्या खाली जाऊ नका)

ऑडिओ सिग्नलची तुलना

सर्व प्रथम, ऑडिओ रेकॉर्डिंग डिजिटल करूया. तो कसा वाटतो ते तुम्ही ऐकू शकता:

आणि नेहमीप्रमाणे ZX स्पेक्ट्रम संगणकावरील रेकॉर्डिंग आवाज:

दोन्ही प्रकरणांमध्ये, रेकॉर्डिंगच्या सुरूवातीस एक तथाकथित आहे पायलट टोन - समान वारंवारतेचा आवाज (पहिल्या रेकॉर्डिंगमध्ये तो खूपच लहान आहे <1 सेकंद, परंतु वेगळे करता येण्याजोगा आहे). पायलट टोन संगणकाला डेटा प्राप्त करण्यासाठी तयार होण्यासाठी सिग्नल करतो. नियमानुसार, प्रत्येक संगणक सिग्नलच्या आकाराद्वारे आणि त्याच्या वारंवारतेद्वारे फक्त "स्वतःचा" पायलट टोन ओळखतो.

सिग्नलच्या आकाराबद्दलच काही सांगणे आवश्यक आहे. उदाहरणार्थ, ZX स्पेक्ट्रमवर त्याचा आकार आयताकृती आहे:

जेव्हा पायलट टोन आढळतो, तेव्हा ZX स्पेक्ट्रम सिग्नल ओळखला गेला आहे हे दर्शविण्यासाठी स्क्रीनच्या सीमेवर पर्यायी लाल आणि निळ्या पट्ट्या दाखवतो. पायलट टोन संपतो सिंक्रो पल्स, जे संगणकाला डेटा प्राप्त करणे सुरू करण्यासाठी सिग्नल करते. हे कमी कालावधीद्वारे वैशिष्ट्यीकृत आहे (पायलट टोन आणि त्यानंतरच्या डेटाच्या तुलनेत) (आकृती पहा)

सिंक पल्स प्राप्त झाल्यानंतर, संगणक सिग्नलच्या प्रत्येक वाढ/पतनाची नोंद करतो, त्याचा कालावधी मोजतो. कालावधी ठराविक मर्यादेपेक्षा कमी असल्यास, बिट 1 मेमरीमध्ये लिहिला जातो, अन्यथा 0. बिट बाइट्समध्ये एकत्रित केले जातात आणि N बाइट्स प्राप्त होईपर्यंत प्रक्रिया पुनरावृत्ती केली जाते. N ही संख्या सहसा डाउनलोड केलेल्या फाईलच्या शीर्षलेखातून घेतली जाते. लोडिंग क्रम खालीलप्रमाणे आहे:

1. पायलट टोन
2. शीर्षलेख (निश्चित लांबी), डाउनलोड केलेल्या डेटाचा आकार (N), फाइल नाव आणि प्रकार समाविष्टीत आहे
3. पायलट टोन
4. डेटा स्वतः

डेटा योग्यरित्या लोड केला आहे याची खात्री करण्यासाठी, ZX स्पेक्ट्रम तथाकथित वाचतो पॅरिटी बाइट (पॅरिटी बाइट), ज्याची गणना लिखित डेटाचे सर्व बाइट्स XOR करून फाइल सेव्ह करताना केली जाते. फाइल वाचताना, संगणक प्राप्त झालेल्या डेटावरून पॅरिटी बाइटची गणना करतो आणि जर निकाल जतन केलेल्यापेक्षा भिन्न असेल तर, "आर टेप लोडिंग त्रुटी" त्रुटी संदेश प्रदर्शित करतो. काटेकोरपणे सांगायचे तर, संगणक हा संदेश आधी जारी करू शकतो, जर, वाचताना, तो नाडी ओळखू शकत नाही (चुकले किंवा त्याचा कालावधी विशिष्ट मर्यादेशी संबंधित नाही)

तर, आता अज्ञात सिग्नल कसा दिसतो ते पाहू:

हा पायलट टोन आहे. सिग्नलचा आकार लक्षणीय भिन्न आहे, परंतु हे स्पष्ट आहे की सिग्नलमध्ये विशिष्ट वारंवारतेच्या लहान डाळींची पुनरावृत्ती होते. 44100 Hz च्या सॅम्पलिंग फ्रिक्वेंसीमध्ये, “शिखर” मधील अंतर अंदाजे 48 नमुने आहे (जे ~918 Hz च्या वारंवारतेशी संबंधित आहे). ही आकृती लक्षात ठेवूया.

आता डेटा तुकडा पाहू:

जर आपण वैयक्तिक डाळींमधील अंतर मोजले तर असे दिसून येते की "लांब" कडधान्यांमधील अंतर अद्याप ~ 48 नमुने आहे आणि लहान डाळींमधील अंतर - ~ 24 आहे. थोडेसे पुढे पाहताना, मी म्हणेन की शेवटी असे दिसून आले की 918 हर्ट्झच्या वारंवारतेसह "संदर्भ" डाळी फाइलच्या सुरुवातीपासून शेवटपर्यंत सतत फॉलो करतात. असे गृहीत धरले जाऊ शकते की डेटा प्रसारित करताना, संदर्भ डाळींमध्ये अतिरिक्त नाडी आढळल्यास, आम्ही त्यास बिट 1 मानतो, अन्यथा 0.

सिंक पल्स बद्दल काय? चला डेटाची सुरूवात पाहू:

पायलट टोन संपतो आणि डेटा लगेच सुरू होतो. थोड्या वेळाने, अनेक भिन्न ऑडिओ रेकॉर्डिंगचे विश्लेषण केल्यावर, आम्ही शोधण्यात सक्षम झालो की डेटाचा पहिला बाइट नेहमी सारखाच असतो (10100101b, A5h). संगणक डेटा प्राप्त केल्यानंतर तो वाचण्यास प्रारंभ करू शकतो.

आपण सिंक बाइटमधील शेवटच्या 1 ला नंतर लगेच प्रथम संदर्भ पल्सच्या शिफ्टकडे देखील लक्ष देऊ शकता. डेटा रेकग्निशन प्रोग्राम विकसित करण्याच्या प्रक्रियेत हे खूप नंतर सापडले, जेव्हा फाइलच्या सुरूवातीस डेटा स्थिरपणे वाचता येत नाही.

आता अल्गोरिदमचे वर्णन करण्याचा प्रयत्न करूया जो ऑडिओ फाइलवर प्रक्रिया करेल आणि डेटा लोड करेल.

डेटा लोड करत आहे

प्रथम, अल्गोरिदम सोपे ठेवण्यासाठी काही गृहीतके पाहू:

1. आम्ही फक्त WAV फॉरमॅटमधील फाइल्सचा विचार करू;
2. ऑडिओ फाइल पायलट टोनने सुरू होणे आवश्यक आहे आणि सुरुवातीला शांतता नसावी
3. स्त्रोत फाइलचा नमुना दर 44100 Hz असणे आवश्यक आहे. या प्रकरणात, 48 नमुन्यांच्या संदर्भ डाळींमधील अंतर आधीच निर्धारित केले आहे आणि आम्हाला प्रोग्रामॅटिकरित्या गणना करण्याची आवश्यकता नाही;
4. नमुना स्वरूप कोणतेही असू शकते (8/16 बिट्स/फ्लोटिंग पॉइंट) - कारण वाचताना आपण ते इच्छित एकामध्ये रूपांतरित करू शकतो;
5. आम्ही असे गृहीत धरतो की स्त्रोत फाइल मोठेपणाद्वारे सामान्यीकृत केली जाते, ज्यामुळे परिणाम स्थिर झाला पाहिजे;

वाचन अल्गोरिदम खालीलप्रमाणे असेल:

1. आम्ही फाइल मेमरीमध्ये वाचतो, त्याच वेळी नमुना स्वरूप 8 बिट्समध्ये रूपांतरित करतो;
2. ऑडिओ डेटामधील पहिल्या नाडीची स्थिती निश्चित करा. हे करण्यासाठी, आपल्याला जास्तीत जास्त मोठेपणासह नमुन्याची संख्या मोजण्याची आवश्यकता आहे. साधेपणासाठी, आम्ही एकदा स्वहस्ते गणना करू. prev_pos व्हेरिएबलमध्ये सेव्ह करूया;
3. शेवटच्या नाडीच्या स्थितीत 48 जोडा (pos := prev_pos + 48)
4. 48 ने पोझिशन वाढवल्याने आम्ही पुढील रेफरन्स पल्स (टेपमधील दोष, टेप ड्राईव्ह मेकॅनिझमचे अस्थिर ऑपरेशन इ.) स्थितीत पोहोचू याची हमी देत ​​नाही, आम्हाला पॉस पल्सची स्थिती समायोजित करणे आवश्यक आहे. हे करण्यासाठी, डेटाचा एक छोटा तुकडा घ्या (pos-8;pos+8) आणि त्यावर कमाल मोठेपणाचे मूल्य शोधा. कमालशी संबंधित स्थिती pos मध्ये संग्रहित केली जाईल. येथे 8 = 48/6 हा प्रायोगिकरित्या प्राप्त केलेला स्थिरांक आहे, जो हमी देतो की आम्ही योग्य कमाल निश्चित करू आणि जवळपासच्या इतर आवेगांवर परिणाम करणार नाही. अत्यंत वाईट प्रकरणांमध्ये, जेव्हा डाळींमधील अंतर 48 पेक्षा खूपच कमी किंवा जास्त असते, तेव्हा आपण नाडीसाठी सक्तीने शोध लागू करू शकता, परंतु लेखाच्या व्याप्तीमध्ये मी अल्गोरिदममध्ये याचे वर्णन करणार नाही;
5. मागील टप्प्यावर, संदर्भ नाडी अजिबात आढळली नाही हे तपासणे देखील आवश्यक आहे. म्हणजेच, जर तुम्ही फक्त जास्तीत जास्त शोधत असाल, तर हे या विभागात आवेग उपस्थित असल्याची हमी देत ​​नाही. रीडिंग प्रोग्रामच्या माझ्या नवीनतम अंमलबजावणीमध्ये, मी एका विभागावरील कमाल आणि किमान मोठेपणा मूल्यांमधील फरक तपासतो आणि जर ते एका विशिष्ट मर्यादेपेक्षा जास्त असेल तर मी आवेगाची उपस्थिती मोजतो. संदर्भ नाडी सापडली नाही तर काय करायचे हाही प्रश्न आहे. तेथे 2 पर्याय आहेत: एकतर डेटा संपला आहे आणि शांतता आहे, किंवा ही वाचन त्रुटी मानली पाहिजे. तथापि, अल्गोरिदम सुलभ करण्यासाठी आम्ही हे वगळू;
6. पुढील पायरीवर, आपल्याला डेटा पल्सची उपस्थिती (बिट 0 किंवा 1) निश्चित करणे आवश्यक आहे, यासाठी आपण सेगमेंटच्या मध्यभागी (prev_pos;pos) Middle_pos समान मध्य_pos := (prev_pos+pos)/2 घेतो आणि सेगमेंटवर मध्य_पोसच्या काही परिसरात (middle_pos-8;middle_pos +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*")

परिणाम

अल्गोरिदम आणि स्थिरांकांचे अनेक प्रकार वापरून पाहिल्यानंतर, मी अत्यंत मनोरंजक काहीतरी मिळवण्यात भाग्यवान होतो:

म्हणून, अक्षरांच्या तारांनुसार, आमच्याकडे आलेख प्लॉट करण्याचा एक प्रोग्राम आहे. तथापि, प्रोग्राम मजकूरात कोणतेही कीवर्ड नाहीत. सर्व कीवर्ड बाइट्स म्हणून एन्कोड केलेले आहेत (प्रत्येक मूल्य > 80h). आता आपल्याला हे शोधण्याची आवश्यकता आहे की 80 च्या दशकातील कोणता संगणक या स्वरूपात प्रोग्राम जतन करू शकतो.

खरं तर, हे बेसिक प्रोग्रामसारखेच आहे. ZX स्पेक्ट्रम कॉम्प्युटर मेमरीमध्ये अंदाजे समान स्वरूपात प्रोग्राम संचयित करतो आणि प्रोग्राम टेपमध्ये जतन करतो. फक्त बाबतीत, मी विरुद्ध कीवर्ड तपासले टेबल. मात्र, निकाल साहजिकच नकारात्मक आला.

मी त्या काळातील लोकप्रिय अटारी, कमोडोर 64 आणि इतर अनेक संगणकांचे मूलभूत कीवर्ड देखील तपासले, ज्यासाठी मी दस्तऐवजीकरण शोधण्यात सक्षम होतो, परंतु यश न मिळाल्याने - रेट्रो संगणकांच्या प्रकारांबद्दलचे माझे ज्ञान इतके विस्तृत नव्हते.

मग मी जायचे ठरवले यादी, आणि मग माझी नजर निर्माता रेडिओ शॅक आणि TRS-80 संगणकाच्या नावावर पडली. माझ्या टेबलावर पडलेल्या कॅसेटच्या लेबलवर ही तीच नावे लिहिली होती! मला ही नावे आधी माहित नव्हती आणि TRS-80 संगणकाशी परिचित नव्हता, त्यामुळे मला असे वाटले की रेडिओ शॅक ही BASF, Sony किंवा TDK सारखी ऑडिओ कॅसेट निर्माता आहे आणि TRS-80 हा प्लेबॅकचा काळ होता. का नाही?

संगणक टँडी/रेडिओ शॅक TRS-80

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

असे दिसून आले की हा संगणक आणि त्याचे प्रकार (मॉडेल I/मॉडेल III/मॉडेल IV, इ.) एका वेळी खूप लोकप्रिय होते (अर्थातच, रशियामध्ये नाही). हे लक्षात घेण्यासारखे आहे की त्यांनी वापरलेला प्रोसेसर देखील Z80 होता. या संगणकासाठी आपण इंटरनेटवर शोधू शकता बरीच माहिती. 80 च्या दशकात, संगणक माहिती वितरीत करण्यात आली मासिके. याक्षणी अनेक आहेत अनुकरणकर्ते वेगवेगळ्या प्लॅटफॉर्मसाठी संगणक.

मी एमुलेटर डाउनलोड केले trs80gp आणि हा संगणक कसा काम करतो हे मी प्रथमच पाहू शकलो. अर्थात, संगणक रंग आउटपुटला समर्थन देत नाही; स्क्रीन रिझोल्यूशन फक्त 128x48 पिक्सेल होते, परंतु स्क्रीन रिझोल्यूशन वाढवणारे बरेच विस्तार आणि बदल होते. या संगणकासाठी ऑपरेटिंग सिस्टीमसाठी अनेक पर्याय आणि मूलभूत भाषा (जे ZX स्पेक्ट्रमच्या विपरीत, काही मॉडेल्समध्ये रॉममध्ये "फ्लॅश" देखील नव्हते आणि फ्लॉपी डिस्कवरून कोणताही पर्याय लोड केला जाऊ शकतो, असे अनेक पर्याय होते. ओएस स्वतः)

मलाही सापडले उपयुक्तता ऑडिओ रेकॉर्डिंग्स सीएएस फॉरमॅटमध्ये रूपांतरित करण्यासाठी, जे एमुलेटरद्वारे समर्थित आहे, परंतु काही कारणास्तव ते वापरून माझ्या कॅसेटमधील रेकॉर्डिंग वाचणे शक्य झाले नाही.

सीएएस फाईल फॉरमॅट शोधून काढल्यानंतर (जे सिंक बाइटच्या उपस्थितीसह शीर्षलेख वगळता माझ्याकडे आधीपासूनच असलेल्या टेपमधील डेटाची फक्त एक बिट-बाय-बिट कॉपी असल्याचे दिसून आले), मी तयार केले माझ्या प्रोग्राममध्ये काही बदल केले आणि एमुलेटर (TRS-80 मॉडेल III) मध्ये काम करणारी कार्यरत CAS फाइल आउटपुट करण्यात सक्षम होते:

मी रूपांतरण उपयुक्ततेची नवीनतम आवृत्ती प्रथम पल्सचे स्वयंचलित निर्धारण आणि GEM पॅकेज म्हणून संदर्भ डाळींमधील अंतरासह डिझाइन केली आहे, स्त्रोत कोड येथे उपलब्ध आहे जिथूब.

निष्कर्ष

आम्ही ज्या मार्गाने प्रवास केला तो भूतकाळातील एक आकर्षक प्रवास ठरला आणि मला आनंद झाला की शेवटी मला उत्तर सापडले. इतर गोष्टींबरोबरच, मी:

• मी ZX स्पेक्ट्रममध्ये डेटा सेव्ह करण्यासाठी फॉरमॅट शोधला आणि ऑडिओ कॅसेटमधून डेटा वाचवण्यासाठी/वाचण्यासाठी अंगभूत रॉम रूटीनचा अभ्यास केला.
• मी TRS-80 संगणक आणि त्याच्या वाणांशी परिचित झालो, ऑपरेटिंग सिस्टमचा अभ्यास केला, नमुना प्रोग्राम पाहिला आणि मशीन कोडमध्ये डीबगिंग करण्याची संधी देखील मिळाली (तरीही, सर्व Z80 नेमोनिक्स मला परिचित आहेत)
• ऑडिओ रेकॉर्डिंग सीएएस फॉरमॅटमध्ये रूपांतरित करण्यासाठी एक पूर्ण उपयुक्तता लिहिली, जी "अधिकृत" युटिलिटीद्वारे ओळखली जात नसलेला डेटा वाचू शकते.

स्त्रोत: www.habr.com