როგორ აღვადგინე მონაცემები უცნობი ფორმატით მაგნიტური ლენტიდან

წინაისტორია

როგორც რეტრო ტექნიკის მოყვარული, ერთხელ ვიყიდე ZX Spectrum+ დიდ ბრიტანეთში გამყიდველისგან. თავად კომპიუტერთან ერთად, მივიღე რამდენიმე აუდიო კასეტა თამაშებით (ორიგინალ შეფუთვაში ინსტრუქციებით), ასევე კასეტებზე ჩაწერილი პროგრამები სპეციალური მარკირების გარეშე. გასაკვირია, რომ 40 წლის წინანდელი კასეტების მონაცემები კარგად იკითხებოდა და მათგან თითქმის ყველა თამაში და პროგრამა გადმოვწერე.

თუმცა, ზოგიერთ კასეტაზე ვიპოვე ჩანაწერები, რომლებიც აშკარად არ იყო გაკეთებული ZX Spectrum კომპიუტერის მიერ. ისინი სრულიად განსხვავებულად ჟღერდნენ და, ხსენებული კომპიუტერიდან ჩანაწერებისგან განსხვავებით, არ დაწყებულა მოკლე BASIC ჩამტვირთველით, რომელიც ჩვეულებრივ ყველა პროგრამისა და თამაშის ჩანაწერშია.

გარკვეული პერიოდის განმავლობაში ეს მაწუხებდა - ძალიან მინდოდა გამერკვია რა იმალებოდა მათში. თუ თქვენ შეძლებთ აუდიო სიგნალის წაკითხვას ბაიტების თანმიმდევრობით, შეგიძლიათ მოძებნოთ სიმბოლოები ან ყველაფერი, რაც მიუთითებს სიგნალის წარმოშობაზე. ერთგვარი რეტრო-არქეოლოგია.

ახლა, როცა მთელი გზა გავიარე და თავად კასეტების ეტიკეტებს ვუყურებ, მეღიმება, რადგან

პასუხი სულ თვალწინ იყო
მარცხენა კასეტის ეტიკეტზე არის TRS-80 კომპიუტერის დასახელება, ხოლო მწარმოებლის სახელის ქვემოთ: "დამზადებულია Radio Shack-ის მიერ აშშ-ში"

(თუ გინდათ ინტრიგა ბოლომდე შეინახოთ, სპოილერის ქვეშ არ გადახვიდეთ)

აუდიო სიგნალების შედარება

პირველ რიგში გავაციფროთ აუდიოჩანაწერები. შეგიძლიათ მოუსმინოთ როგორ ჟღერს:

და ჩვეულებისამებრ ჟღერს ჩანაწერი ZX Spectrum კომპიუტერიდან:

ორივე შემთხვევაში, ჩაწერის დასაწყისში არის ე.წ პილოტის ტონი - იგივე სიხშირის ხმა (პირველ ჩანაწერში ძალიან მოკლეა <1 წამი, მაგრამ გამორჩეულია). საპილოტე ტონი აცნობებს კომპიუტერს, რომ მოემზადოს მონაცემების მისაღებად. როგორც წესი, თითოეული კომპიუტერი ცნობს მხოლოდ "საკუთარი" პილოტის ტონს სიგნალის ფორმისა და სიხშირის მიხედვით.

აუცილებელია რაღაცის თქმა თავად სიგნალის ფორმის შესახებ. მაგალითად, ZX Spectrum-ზე მისი ფორმა მართკუთხაა:

პილოტური ტონის აღმოჩენისას, ZX Spectrum აჩვენებს მონაცვლეობით წითელ და ლურჯ ზოლებს ეკრანის საზღვარზე, რათა მიუთითოს, რომ სიგნალი იქნა აღიარებული. პილოტის ტონი მთავრდება სინქრონული პულსი, რომელიც აძლევს სიგნალს კომპიუტერს, რომ დაიწყოს მონაცემების მიღება. იგი ხასიათდება უფრო მოკლე ხანგრძლივობით (საპილოტე ტონთან და შემდგომ მონაცემებთან შედარებით) (იხ. სურათი)

სინქრონიზაციის პულსის მიღების შემდეგ, კომპიუტერი აღრიცხავს სიგნალის ყოველ აწევას/დაცემას, გაზომავს მის ხანგრძლივობას. თუ ხანგრძლივობა ნაკლებია გარკვეულ ზღვარზე, ბიტი 1 იწერება მეხსიერებაში, წინააღმდეგ შემთხვევაში 0. ბიტები გროვდება ბაიტებად და პროცესი მეორდება N ბაიტის მიღებამდე. ნომერი N ჩვეულებრივ აღებულია გადმოწერილი ფაილის სათაურიდან. დატვირთვის თანმიმდევრობა შემდეგია:

1. პილოტის ტონი
2. header (ფიქსირებული სიგრძე), შეიცავს გადმოწერილი მონაცემების ზომას (N), ფაილის სახელსა და ტიპს
3. პილოტის ტონი
4. თავად მონაცემები

მონაცემების სწორად ჩატვირთვაში რომ დარწმუნდეს, ZX Spectrum კითხულობს ე.წ პარიტეტის ბაიტი (პარიტეტის ბაიტი), რომელიც გამოითვლება ფაილის შენახვისას ჩაწერილი მონაცემების ყველა ბაიტის XOR-ით. ფაილის წაკითხვისას კომპიუტერი მიღებული მონაცემებიდან ითვლის პარიტეტის ბაიტს და თუ შედეგი განსხვავდება შენახულისგან, აჩვენებს შეცდომის შეტყობინებას "R Tape loading error". მკაცრად რომ ვთქვათ, კომპიუტერს შეუძლია ადრე გამოსცეს ეს შეტყობინება, თუ კითხვისას ვერ ცნობს პულსს (გამოტოვებული ან მისი ხანგრძლივობა არ შეესაბამება გარკვეულ ლიმიტებს)

ახლა ვნახოთ, როგორ გამოიყურება უცნობი სიგნალი:

ეს არის პილოტის ტონი. სიგნალის ფორმა მნიშვნელოვნად განსხვავდება, მაგრამ ცხადია, რომ სიგნალი შედგება გარკვეული სიხშირის მოკლე იმპულსების განმეორებისგან. შერჩევის სიხშირეზე 44100 ჰც, მანძილი "მწვერვალებს" შორის არის დაახლოებით 48 ნიმუში (რაც შეესაბამება ~918 ჰც სიხშირეს). გავიხსენოთ ეს მაჩვენებელი.

ახლა გადავხედოთ მონაცემთა ფრაგმენტს:

თუ გავზომავთ მანძილს ცალკეულ იმპულსებს შორის, გამოდის, რომ მანძილი "გრძელ" პულსებს შორის კვლავ ~48 ნიმუშია, ხოლო მოკლეს შორის - ~24. ცოტა წინ რომ გავიხედოთ, ვიტყვი, რომ საბოლოოდ აღმოჩნდა, რომ 918 ჰც სიხშირის „რეფერენციული“ იმპულსები მიჰყვება განუწყვეტლივ, ფაილის თავიდან ბოლომდე. შეიძლება ვივარაუდოთ, რომ მონაცემთა გადაცემისას, თუ საცნობარო იმპულსებს შორის შეგვხვდება დამატებითი პულსი, მას მივიჩნევთ როგორც ბიტი 1, წინააღმდეგ შემთხვევაში 0.

რაც შეეხება სინქრონიზაციის პულსს? მოდით შევხედოთ მონაცემების დასაწყისში:

პილოტის ტონი მთავრდება და მონაცემები დაუყოვნებლივ იწყება. ცოტა მოგვიანებით, რამდენიმე სხვადასხვა აუდიო ჩანაწერის გაანალიზების შემდეგ, ჩვენ შევძელით აღმოვაჩინეთ, რომ მონაცემთა პირველი ბაიტი ყოველთვის იგივეა (10100101b, A5h). კომპიუტერმა შეიძლება დაიწყოს მონაცემების წაკითხვა მისი მიღების შემდეგ.

თქვენ ასევე შეგიძლიათ ყურადღება მიაქციოთ პირველი მითითების პულსის ცვლას სინქრონიზაციის ბაიტში ბოლო 1-ის შემდეგ. ის გაცილებით გვიან აღმოაჩინეს მონაცემთა ამოცნობის პროგრამის შემუშავების პროცესში, როდესაც ფაილის დასაწყისში მონაცემები სტაბილურად ვერ იკითხებოდა.

ახლა შევეცადოთ აღვწეროთ ალგორითმი, რომელიც დაამუშავებს აუდიო ფაილს და ჩატვირთავს მონაცემებს.

იტვირთება მონაცემები

პირველ რიგში, მოდით შევხედოთ რამდენიმე ვარაუდს, რათა შევინარჩუნოთ ალგორითმი მარტივი:

1. ჩვენ განვიხილავთ მხოლოდ ფაილებს WAV ფორმატში;
2. აუდიო ფაილი უნდა დაიწყოს პილოტური ტონით და არ უნდა შეიცავდეს სიჩუმეს დასაწყისში
3. წყაროს ფაილს უნდა ჰქონდეს შერჩევის სიხშირე 44100 ჰც. ამ შემთხვევაში მანძილი 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 და შუა_pos-ის ზოგიერთ უბანში სეგმენტზე (middle_pos-8;middle_pos +8) გამოვთვალოთ მაქსიმალური და მინიმალური ამპლიტუდა. თუ მათ შორის სხვაობა 10-ზე მეტია, შედეგში ვწერთ 1 ბიტს, წინააღმდეგ შემთხვევაში 0. 10 არის ექსპერიმენტულად მიღებული მუდმივი;
7. შეინახეთ მიმდინარე პოზიცია prev_pos-ში (prev_pos := pos)
8. გაიმეორეთ მე-3 ნაბიჯიდან, სანამ არ წავიკითხავთ მთელ ფაილს;
9. შედეგად მიღებული ბიტების მასივი უნდა იყოს შენახული ბაიტების ნაკრების სახით. ვინაიდან წაკითხვისას არ გავითვალისწინეთ სინქრონიზაციის ბაიტი, ბიტების რაოდენობა შეიძლება არ იყოს 8-ის ჯერადი და ასევე უცნობია ბიტის საჭირო ოფსეტი. ალგორითმის პირველ განხორციელებაში მე არ ვიცოდი სინქრონიზაციის ბაიტის არსებობის შესახებ და ამიტომ უბრალოდ შევინახე 8 ფაილი სხვადასხვა რაოდენობის ოფსეტური ბიტით. ერთ-ერთი მათგანი შეიცავდა სწორ მონაცემებს. საბოლოო ალგორითმში, მე უბრალოდ ვხსნი ყველა ბიტს A5h-მდე, რაც საშუალებას მაძლევს დაუყოვნებლივ მივიღო სწორი გამომავალი ფაილი

ალგორითმი რუბიში, დაინტერესებულთათვის
პროგრამის დაწერის ენად Ruby ავირჩიე, რადგან... მე მასზე ვაპროგრამებ უმეტეს დროს. ვარიანტი არ არის მაღალი ხარისხის, მაგრამ კითხვის სიჩქარის რაც შეიძლება სწრაფი გატარების ამოცანა არ ღირს.

# Используем 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-იანი წლების რომელ კომპიუტერს შეეძლო ამ ფორმატში პროგრამების შენახვა.

სინამდვილეში, ის ძალიან ჰგავს BASIC პროგრამას. ZX Spectrum კომპიუტერი ინახავს პროგრამებს დაახლოებით იმავე ფორმატში მეხსიერებაში და ინახავს პროგრამებს ფირზე. ყოველ შემთხვევაში, მე შევამოწმე საკვანძო სიტყვები წინააღმდეგ მაგიდა. თუმცა, შედეგი აშკარად უარყოფითი იყო.

მე ასევე შევამოწმე პოპულარული Atari, Commodore 64 და იმდროინდელი რამდენიმე სხვა კომპიუტერის BASIC საკვანძო სიტყვები, რისთვისაც შევძელი დოკუმენტაციის პოვნა, მაგრამ უშედეგოდ - ჩემი ცოდნა რეტრო კომპიუტერების ტიპების შესახებ არც ისე ფართო აღმოჩნდა.

მერე გადავწყვიტე წასვლა სია, შემდეგ კი ჩემი მზერა მწარმოებლის Radio Shack-ის და TRS-80 კომპიუტერის სახელზე დაეცა. აი ეს სახელები ეწერა იმ კასეტების ეტიკეტებზე, რომლებიც ჩემს მაგიდაზე იდო! ადრე არ ვიცოდი ეს სახელები და არ ვიცნობდი TRS-80 კომპიუტერს, ამიტომ მეჩვენებოდა, რომ Radio Shack იყო აუდიო კასეტების მწარმოებელი, როგორიცაა BASF, Sony ან TDK, და TRS-80 იყო დაკვრის დრო. Რატომაც არა?

კომპიუტერი Tandy/Radio Shack TRS-80

ძალიან სავარაუდოა, რომ განსახილველი აუდიოჩანაწერი, რომელიც მე მოვიყვანე სტატიის დასაწყისში მაგალითზე, გაკეთდა კომპიუტერზე ასე:

აღმოჩნდა, რომ ეს კომპიუტერი და მისი ჯიშები (Model I/Model III/Model IV და ა.შ.) ერთ დროს ძალიან პოპულარული იყო (რა თქმა უნდა, არა რუსეთში). აღსანიშნავია, რომ მათ მიერ გამოყენებული პროცესორიც იყო Z80. ამ კომპიუტერისთვის შეგიძლიათ იპოვოთ ინტერნეტში ბევრი ინფორმაცია. 80-იან წლებში კომპიუტერული ინფორმაცია გავრცელდა ჟურნალები. ამ დროისთვის არის რამდენიმე ემულატორები კომპიუტერები სხვადასხვა პლატფორმისთვის.

ემულატორი გადმოვწერე trs80gp და პირველად შევძელი დამენახა როგორ მუშაობდა ეს კომპიუტერი. რა თქმა უნდა, კომპიუტერს არ უჭერდა მხარს ფერადი გამომავალი; ეკრანის გარჩევადობა იყო მხოლოდ 128x48 პიქსელი, მაგრამ იყო მრავალი გაფართოება და მოდიფიკაცია, რამაც შეიძლება გაზარდოს ეკრანის გარჩევადობა. ასევე იყო ამ კომპიუტერისთვის ოპერაციული სისტემების მრავალი ვარიანტი და BASIC ენის დანერგვის ვარიანტები (რომელიც, განსხვავებით ZX Spectrum-ისგან, ზოგიერთ მოდელში არც კი იყო "ჩამოკიდებული" ROM-ში და ნებისმიერი ვარიანტის ჩატვირთვა შეიძლებოდა დისკეტიდან, ისევე როგორც თავად OS)

მეც ვიპოვე სასარგებლო აუდიო ჩანაწერების CAS ფორმატში გადაქცევა, რომელსაც მხარს უჭერს ემულატორები, მაგრამ რატომღაც შეუძლებელი იყო მათი გამოყენებით ჩემი კასეტებიდან ჩანაწერების წაკითხვა.

როდესაც გავარკვიე CAS ფაილის ფორმატი (რომელიც აღმოჩნდა მხოლოდ ფირზე მონაცემების ბიტ-ბიტი ასლი, რომელიც უკვე ხელთ მქონდა, გარდა სათაურის სინქრონიზაციის ბაიტის არსებობით), გავაკეთე რამდენიმე ცვლილება ჩემს პროგრამაში და შევძელი სამუშაო CAS ფაილის გამოტანა, რომელიც მუშაობდა ემულატორში (TRS-80 Model III):

მე დავაპროექტე კონვერტაციის პროგრამის უახლესი ვერსია პირველი პულსის ავტომატური განსაზღვრით და მითითების პულსებს შორის მანძილით, როგორც GEM პაკეტი, წყაროს კოდი ხელმისაწვდომია აქ Github.

დასკვნა

გზა, რომელიც ჩვენ გავიარეთ, წარსულში მომხიბლავი მოგზაურობა აღმოჩნდა და მიხარია, რომ საბოლოოდ პასუხი ვიპოვე. სხვა საკითხებთან ერთად მე:

• მე გავარკვიე ZX Spectrum-ში მონაცემების შენახვის ფორმატი და შევისწავლე ჩაშენებული ROM რუტინები აუდიო კასეტებიდან მონაცემების შესანახად/წაკითხვისთვის.
• გავიცანი TRS-80 კომპიუტერი და მისი ჯიშები, შევისწავლე ოპერაციული სისტემა, გადავხედე პროგრამებს და კიდევ მქონდა შესაძლებლობა გამეკეთებინა გამართვა მანქანების კოდებში (ბოლოს და ბოლოს, ყველა Z80 მნემონიკა ჩემთვის ნაცნობია)
• დაწერა სრულფასოვანი პროგრამა აუდიო ჩანაწერების CAS ფორმატში გადასაყვანად, რომელსაც შეუძლია წაიკითხოს მონაცემები, რომლებიც არ არის აღიარებული "ოფიციალური" პროგრამის მიერ

წყარო: www.habr.com