मैले कसरी चुम्बकीय टेपबाट अज्ञात ढाँचामा डेटा पुन: प्राप्त गरें

प्रागितिहास

रेट्रो हार्डवेयरको प्रेमी भएको कारण, मैले एक पटक युकेमा बिक्रेताबाट ZX स्पेक्ट्रम+ खरिद गरें। कम्प्यूटरमा नै समावेश गरिएको, मैले खेलहरूसँग धेरै अडियो क्यासेटहरू प्राप्त गरें (मूल प्याकेजिङमा निर्देशनहरू), साथै क्यासेटहरूमा विशेष चिन्हहरू बिना रेकर्ड गरिएका कार्यक्रमहरू। अचम्मको कुरा, 40-वर्ष पुरानो क्यासेटहरूको डाटा राम्रोसँग पढ्न योग्य थियो र मैले तिनीहरूबाट लगभग सबै खेल र कार्यक्रमहरू डाउनलोड गर्न सक्षम थिएँ।

जे होस्, केही क्यासेटहरूमा मैले रेकर्डिङहरू फेला पारे जुन स्पष्ट रूपमा ZX स्पेक्ट्रम कम्प्युटरद्वारा बनाइएको थिएन। तिनीहरू पूर्णतया फरक देखिन्थे र, उल्लेख गरिएको कम्प्युटरबाट रेकर्डिङहरूको विपरीत, तिनीहरूले छोटो बेसिक बुटलोडरको साथ सुरु गरेनन्, जुन प्राय: सबै कार्यक्रमहरू र खेलहरूको रेकर्डिङहरूमा उपस्थित हुन्छ।

केही समयको लागि यसले मलाई सतायो - म साँच्चै तिनीहरूमा लुकेको कुरा पत्ता लगाउन चाहन्थें। यदि तपाईंले बाइटहरूको अनुक्रमको रूपमा अडियो सङ्केत पढ्न सक्नुहुन्छ भने, तपाईंले क्यारेक्टरहरू वा सङ्केतको उत्पत्ति संकेत गर्ने कुनै पनि कुरा खोज्न सक्नुहुन्छ। एक प्रकारको रेट्रो पुरातत्व।

अब जब म सबै बाटो गएको छु र क्यासेटहरूको लेबलहरू हेर्छु, म मुस्कुराउँछु

जवाफ मेरो आँखा अगाडि थियो
बायाँ क्यासेटको लेबलमा TRS-80 कम्प्युटरको नाम छ, र निर्माताको नामको ठीक तल: "संयुक्त राज्य अमेरिकामा रेडियो श्याकद्वारा निर्मित"

(यदि तपाइँ षड्यन्त्रलाई अन्त्य सम्म राख्न चाहानुहुन्छ भने, बिगार्नकर्ता अन्तर्गत नजानुहोस्)

अडियो संकेतहरूको तुलना

सबैभन्दा पहिले, अडियो रेकर्डिङहरू डिजिटलाइज गरौं। तपाईं यो कस्तो आवाज सुन्न सक्नुहुन्छ:

र सामान्य रूपमा ZX स्पेक्ट्रम कम्प्युटरबाट रेकर्डिङ ध्वनि:

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

यो संकेत आकार को बारे मा केहि भन्न आवश्यक छ। उदाहरण को लागी, ZX स्पेक्ट्रम मा यसको आकार आयताकार छ:

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

सिंक पल्स प्राप्त भएपछि, कम्प्युटरले यसको अवधि नाप्दै, सिग्नलको प्रत्येक वृद्धि/पतन रेकर्ड गर्दछ। यदि अवधि निश्चित सीमा भन्दा कम छ भने, बिट 1 मेमोरीमा लेखिएको छ, अन्यथा 0। बिटहरू बाइटहरूमा सङ्कलन गरिन्छ र N बाइटहरू प्राप्त नभएसम्म प्रक्रिया दोहोर्याइन्छ। नम्बर N सामान्यतया डाउनलोड गरिएको फाइलको हेडरबाट लिइन्छ। लोडिङ अनुक्रम निम्नानुसार छ:

1. पायलट टोन
2. हेडर (निश्चित लम्बाइ), डाउनलोड गरिएको डाटाको साइज (N), फाइल नाम र प्रकार समावेश गर्दछ
3. पायलट टोन
4. डाटा आफैं

डाटा सही रूपमा लोड गरिएको छ भनेर सुनिश्चित गर्न, ZX स्पेक्ट्रम तथाकथित पढ्छ समानता बाइट (parity byte), जुन लिखित डाटाका सबै बाइटहरू XOR गरेर फाइल बचत गर्दा गणना गरिन्छ। फाइल पढ्दा, कम्प्युटरले प्राप्त डाटाबाट समानता बाइट गणना गर्दछ र, यदि परिणाम बचत गरिएको भन्दा फरक छ भने, त्रुटि सन्देश "R टेप लोडिङ त्रुटि" देखाउँछ। कडा शब्दमा भन्नुपर्दा, कम्प्युटरले यो सन्देश पहिले जारी गर्न सक्छ यदि, पढ्दा, यसले पल्स चिन्न सक्दैन (छुटेको वा यसको अवधि निश्चित सीमाहरूसँग मेल खाँदैन)।

त्यसोभए, अब अज्ञात संकेत कस्तो देखिन्छ हेरौं:

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

अब डाटा टुक्रा हेरौं:

यदि हामीले व्यक्तिगत दालहरू बीचको दूरी नाप्यौं भने, यो पत्ता लाग्छ कि "लामो" दालहरू बीचको दूरी अझै ~ 48 नमूनाहरू, र छोटोहरू बीचको - ~ 24 छ। अलि अगाडि हेर्दै, म भन्छु कि अन्तमा यो पत्ता लाग्यो कि 918 हर्ट्जको फ्रिक्वेन्सीको साथ "सन्दर्भ" पल्सहरू फाइलको सुरुदेखि अन्त्यसम्म लगातार पछ्याउँछन्। यो मान्न सकिन्छ कि डाटा ट्रान्समिट गर्दा, यदि सन्दर्भ पल्सहरू बीच अतिरिक्त पल्स सामना भयो भने, हामी यसलाई बिट 1, अन्यथा ० मान्छौं।

सिंक पल्सको बारेमा के हो? डाटाको सुरुमा हेरौं:

पायलट टोन समाप्त हुन्छ र डाटा तुरुन्तै सुरु हुन्छ। केही समय पछि, धेरै फरक अडियो रेकर्डिङहरू विश्लेषण पछि, हामीले पत्ता लगाउन सक्षम भयौं कि डेटाको पहिलो बाइट सधैं उस्तै हुन्छ (10100101b, A5h)। कम्प्युटरले डाटा प्राप्त गरेपछि पढ्न सुरु गर्न सक्छ।

तपाइँ सिंक बाइटमा अन्तिम 1st पछि तुरुन्तै पहिलो सन्दर्भ पल्सको शिफ्टमा ध्यान दिन सक्नुहुन्छ। यो धेरै पछि डाटा पहिचान कार्यक्रम विकासको प्रक्रियामा पत्ता लगाइएको थियो, जब फाइलको सुरुमा डाटा स्थिर रूपमा पढ्न सकिँदैन।

अब एक एल्गोरिथ्म वर्णन गर्ने प्रयास गरौं जसले अडियो फाइल प्रशोधन गर्दछ र डाटा लोड गर्दछ।

डाटा लोड गर्दै

पहिले, एल्गोरिथ्म सरल राख्नको लागि केही धारणाहरू हेरौं:

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) र यसमा अधिकतम एम्प्लिच्युड मान फेला पार्नुहोस्। अधिकतम अनुरूपको स्थिति पोजमा भण्डार गरिनेछ। यहाँ 8 = 48/6 एक प्रयोगात्मक रूपमा प्राप्त स्थिर छ, जसले ग्यारेन्टी दिन्छ कि हामी सही अधिकतम निर्धारण गर्नेछौं र नजिकै हुन सक्ने अन्य आवेगहरूलाई असर गर्दैन। धेरै नराम्रो अवस्थामा, जब दालहरू बीचको दूरी 48 भन्दा कम वा बढी हुन्छ, तपाईले पल्सको लागि जबरजस्ती खोज लागू गर्न सक्नुहुन्छ, तर लेखको दायरा भित्र म यसलाई एल्गोरिथ्ममा वर्णन गर्नेछैन;
5. अघिल्लो चरणमा, यो पनि जाँच गर्न आवश्यक हुनेछ कि सन्दर्भ पल्स सबै फेला पर्यो। त्यो हो, यदि तपाइँ केवल अधिकतम खोज्नुहुन्छ भने, यसले ग्यारेन्टी गर्दैन कि आवेग यस खण्डमा अवस्थित छ। पढ्ने कार्यक्रमको मेरो पछिल्लो कार्यान्वयनमा, म खण्डमा अधिकतम र न्यूनतम आयाम मानहरू बीचको भिन्नता जाँच गर्छु, र यदि यो निश्चित सीमा नाघ्यो भने, म आवेगको उपस्थिति गणना गर्छु। सन्दर्भ पल्स फेला परेन भने के गर्ने भन्ने प्रश्न पनि छ। त्यहाँ 2 विकल्पहरू छन्: या त डाटा समाप्त भएको छ र मौनता पछ्याउँछ, वा यसलाई पढ्ने त्रुटि मान्नु पर्छ। यद्यपि, हामी एल्गोरिथ्म सरल बनाउन यसलाई छोड्नेछौं;
6. अर्को चरणमा, हामीले डेटा पल्स (बिट ० वा १) को उपस्थिति निर्धारण गर्न आवश्यक छ, यसका लागि हामीले खण्डको बीचमा (prev_pos;pos) Middle_pos बराबर मध्य_pos := (prev_pos+pos)/0 र केही छिमेकमा मध्य_पोस खण्डमा (middle_pos-1;middle_pos +2) अधिकतम र न्यूनतम एम्प्लिच्युड गणना गरौं। यदि तिनीहरू बीचको भिन्नता 8 भन्दा बढी छ भने, हामी नतिजामा बिट 8 लेख्छौं, अन्यथा 10। 1 प्रयोगात्मक रूपमा प्राप्त गरिएको स्थिर हो;
7. prev_pos (prev_pos := pos) मा हालको स्थिति बचत गर्नुहोस्
8. हामीले पूरै फाइल नपढेसम्म चरण 3 बाट सुरु गरेर दोहोर्याउनुहोस्;
9. परिणामित बिट एरे बाइटहरूको सेटको रूपमा बचत हुनुपर्छ। हामीले पढ्दा सिङ्क बाइटलाई ध्यानमा नराखेको हुनाले, बिट्सको संख्या ८ को गुणन नहुन सक्छ, र आवश्यक बिट अफसेट पनि अज्ञात छ। एल्गोरिथ्मको पहिलो कार्यान्वयनमा, मलाई सिङ्क बाइटको अस्तित्वको बारेमा थाहा थिएन र त्यसैले अफसेट बिटहरूको विभिन्न संख्याका साथ 8 फाइलहरू मात्र बचत गरें। ती मध्ये एक सही डाटा समावेश थियो। अन्तिम एल्गोरिथ्ममा, म केवल A8h सम्मका सबै बिटहरू हटाउँछु, जसले मलाई तुरुन्तै सही आउटपुट फाइल प्राप्त गर्न अनुमति दिन्छ।

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

# Используем 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)। अब हामीले यो ढाँचामा प्रोग्रामहरू बचत गर्न सक्ने 80s बाट कुन कम्प्युटर पत्ता लगाउन आवश्यक छ।

वास्तवमा, यो आधारभूत कार्यक्रमसँग धेरै मिल्दोजुल्दो छ। ZX स्पेक्ट्रम कम्प्युटरले मेमोरीमा लगभग एउटै ढाँचामा प्रोग्रामहरू भण्डारण गर्दछ र प्रोग्रामहरूलाई टेपमा बचत गर्दछ। केवल केसमा, मैले कुञ्जी शब्दहरू विरुद्ध जाँच गरें तालिका। तर, नतिजा भने नेगेटिभ आएको स्पष्ट छ ।

मैले लोकप्रिय अटारी, कमोडोर 64 र त्यस समयका धेरै अन्य कम्प्यूटरहरूको आधारभूत कुञ्जी शब्दहरू पनि जाँच गरें, जसको लागि मैले कागजातहरू फेला पार्न सक्षम थिएँ, तर सफलता बिना - रेट्रो कम्प्युटरहरूको प्रकारहरूको मेरो ज्ञान यति फराकिलो भएन।

त्यसपछि मैले जाने निर्णय गरें सूची, र त्यसपछि मेरो नजर निर्माता रेडियो शेक र TRS-80 कम्प्युटरको नाममा पर्यो। मेरो टेबुलमा पल्टिएका क्यासेटको लेबलमा लेखिएका नामहरू यी हुन् ! मलाई यी नामहरू पहिले थाहा थिएन र TRS-80 कम्प्युटरसँग परिचित थिएन, त्यसैले मलाई रेडियो शैक BASF, Sony वा TDK जस्ता अडियो क्यासेट निर्माता थियो र TRS-80 प्लेब्याक समय थियो। किन नगर्ने ?

कम्प्युटर ट्यान्डी/रेडियो शेक TRS-80

यो धेरै सम्भव छ कि प्रश्नमा अडियो रेकर्डिङ, जुन मैले लेखको सुरुमा उदाहरणको रूपमा दिएँ, यो कम्प्युटरमा बनाइएको थियो:

यो पत्ता लाग्यो कि यो कम्प्युटर र यसको किस्महरू (मोडेल I/Model III/Model IV, आदि) एक पटक धेरै लोकप्रिय थिए (निस्सन्देह, रूसमा होइन)। यो उल्लेखनीय छ कि तिनीहरूले प्रयोग गरेको प्रोसेसर पनि Z80 थियो। यो कम्प्युटरको लागि तपाईंले इन्टरनेटमा फेला पार्न सक्नुहुन्छ धेरै जानकारी। 80 को दशक मा, कम्प्युटर जानकारी वितरित गरिएको थियो पत्रिकाहरू। हाल त्यहाँ धेरै छन् इमुलेटरहरू विभिन्न प्लेटफर्महरूको लागि कम्प्युटर।

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

मैले पनि फेला पारे उपयोगिता अडियो रेकर्डिङहरूलाई CAS ढाँचामा रूपान्तरण गर्न, जुन इमुलेटरहरूद्वारा समर्थित छ, तर केही कारणले मेरो क्यासेटहरू प्रयोग गरेर रेकर्डिङहरू पढ्न सम्भव भएन।

CAS फाइल ढाँचा पत्ता लगाएर (जुन टेपबाट डाटाको एक बिट-बाइ-बिट प्रतिलिपि बन्यो जुन मसँग पहिले नै हातमा थियो, सिङ्क बाइटको उपस्थितिको साथ हेडर बाहेक), मैले एउटा बनाएको छु। मेरो कार्यक्रममा केहि परिवर्तनहरू र इमुलेटर (TRS-80 मोडेल III) मा काम गर्ने काम गर्ने CAS फाइल आउटपुट गर्न सक्षम थिए:

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

निष्कर्षमा

हामीले यात्रा गरेको बाटो विगतमा एक आकर्षक यात्रा भयो, र म खुसी छु कि अन्तमा मैले जवाफ पाएको छु। अन्य चीजहरू मध्ये, म:

• मैले ZX स्पेक्ट्रममा डाटा बचत गर्ने ढाँचा पत्ता लगाएँ र अडियो क्यासेटहरूबाट डाटा बचत/पढ्नका लागि निर्मित ROM दिनचर्याहरू अध्ययन गरें।
• मैले TRS-80 कम्प्युटर र यसको किस्महरूसँग परिचित भएँ, अपरेटिङ सिस्टमको अध्ययन गरें, नमूना कार्यक्रमहरू हेरेँ र मेसिन कोडहरूमा डिबग गर्ने अवसर पनि पाएको थिएँ (बादमा, सबै Z80 निमोनिक्सहरू मलाई परिचित छन्)।
• अडियो रेकर्डिङलाई CAS ढाँचामा रूपान्तरण गर्नको लागि पूर्ण उपयोगिता लेखियो, जसले "आधिकारिक" उपयोगिताद्वारा पहिचान नभएको डाटा पढ्न सक्छ।

स्रोत: www.habr.com