Как възстанових данни в неизвестен формат от магнитна лента

праистория

Тъй като съм любител на ретро хардуера, веднъж закупих ZX Spectrum+ от продавач в Обединеното кралство. В комплект със самия компютър получих няколко аудио касети с игри (в оригиналната опаковка с инструкции), както и програми записани на касети без специални маркировки. Изненадващо, данните от 40-годишни касети се четят добре и успях да изтегля почти всички игри и програми от тях.

На някои касети обаче намерих записи, които очевидно не са направени от компютъра ZX Spectrum. Те звучаха съвсем различно и за разлика от записите от споменатия компютър не стартираха с кратък BASIC буутлоудър, който обикновено присъства в записите на всички програми и игри.

Известно време това ме преследваше - много исках да разбера какво се крие в тях. Ако можете да прочетете аудиосигнала като поредица от байтове, можете да потърсите знаци или нещо, което показва произхода на сигнала. Един вид ретроархеология.

Сега, след като извървях целия път и погледнах етикетите на самите касети, се усмихвам, защото

отговорът беше точно пред очите ми през цялото време
На етикета на лявата касета е името на компютъра TRS-80 и точно под името на производителя: „Произведено от Radio Shack в САЩ“

(Ако искате да запазите интригата до края, не минавайте под спойлера)

Сравнение на аудио сигнали

Първо, нека дигитализираме аудиозаписите. Можете да чуете как звучи:

И както обикновено звучи записът от компютъра ZX Spectrum:

И в двата случая в началото на записа има т.нар пилотен тон - звук със същата честота (в първия запис е много кратък <1 секунда, но се различава). Пилотният тон сигнализира на компютъра да се подготви за получаване на данни. По правило всеки компютър разпознава само своя „собствен“ пилотен тон по формата на сигнала и неговата честота.

Необходимо е да се каже нещо за самата форма на сигнала. Например на ZX Spectrum формата му е правоъгълна:

Когато бъде открит пилотен тон, ZX Spectrum показва редуващи се червени и сини ленти на границата на екрана, за да покаже, че сигналът е разпознат. Пилотният тон свършва синхронен импулс, което сигнализира на компютъра да започне да получава данни. Характеризира се с по-кратка продължителност (в сравнение с пилотния тон и последващите данни) (виж фигурата)

След получаване на синхронизиращия импулс компютърът записва всяко нарастване/спадане на сигнала, измервайки неговата продължителност. Ако продължителността е по-малка от определено ограничение, бит 1 се записва в паметта, в противен случай 0. Битовете се събират в байтове и процесът се повтаря, докато се получат N байта. Числото N обикновено се взема от заглавката на изтегления файл. Последователността на зареждане е следната:

1. пилотен тон
2. заглавка (фиксирана дължина), съдържа размера на изтеглените данни (N), името и типа на файла
3. пилотен тон
4. самите данни

За да е сигурен, че данните са заредени правилно, ZX Spectrum чете т.нар паритетен байт (паритетен байт), който се изчислява при запис на файл чрез XOR на всички байтове от записаните данни. Когато чете файл, компютърът изчислява паритетния байт от получените данни и ако резултатът се различава от записания, показва съобщение за грешка „R Tape loading error“. Строго погледнато, компютърът може да издаде това съобщение по-рано, ако при четене не може да разпознае импулс (пропуснат или продължителността му не отговаря на определени граници)

И така, нека сега видим как изглежда неизвестен сигнал:

Това е пилотният тон. Формата на сигнала е значително различна, но е ясно, че сигналът се състои от повтарящи се кратки импулси с определена честота. При честота на семплиране от 44100 Hz, разстоянието между "пиковете" е приблизително 48 семплиране (което съответства на честота от ~918 Hz) Нека запомним тази цифра.

Нека сега да разгледаме фрагмента от данни:

Ако измерим разстоянието между отделните импулси, се оказва, че разстоянието между „дългите“ импулси все още е ~48 проби, а между късите - ~24. Гледайки малко напред, ще кажа, че в крайна сметка се оказа, че „референтните“ импулси с честота 918 Hz следват непрекъснато, от началото до края на файла. Може да се предположи, че при предаване на данни, ако се срещне допълнителен импулс между референтните импулси, ние го считаме за бит 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 не гарантира, че ще стигнем до позицията на следващия референтен импулс (дефекти на лентата, нестабилна работа на механизма на лентовото устройство и т.н.), трябва да коригираме позицията на позиционния импулс. За да направите това, вземете малка част от данните (поз-8;поз+8) и намерете стойността на максималната амплитуда върху тях. Позицията, съответстваща на максимума, ще бъде запаметена в поз. Тук 8 = 48/6 е експериментално получена константа, която гарантира, че ще определим правилния максимум и няма да повлияем на други импулси, които може да са наблизо. В много лоши случаи, когато разстоянието между импулсите е много по-малко или по-голямо от 48, можете да приложите принудително търсене на импулс, но в рамките на статията няма да описвам това в алгоритъма;
5. В предишната стъпка също ще бъде необходимо да се провери дали референтният импулс изобщо е намерен. Тоест, ако просто търсите максимума, това не гарантира, че импулсът присъства в този сегмент. В последното си изпълнение на програмата за четене проверявам разликата между максималните и минималните стойности на амплитудата на сегмент и ако надвишава определена граница, отчитам наличието на импулс. Въпросът е и какво да правим, ако референтният импулс не бъде открит. Има 2 варианта: или данните са приключили и следва мълчание, или това трябва да се счита за грешка при четене. Ние обаче ще пропуснем това, за да опростим алгоритъма;
6. На следващата стъпка трябва да определим наличието на импулс за данни (бит 0 или 1), за това вземаме средата на сегмента (prev_pos;pos) middle_pos равна на middle_pos := (prev_pos+pos)/2 и в някакъв квартал на middle_pos на сегмента (middle_pos-8;middle_pos +8) нека изчислим максималната и минималната амплитуда. Ако разликата между тях е повече от 10, записваме бит 1 в резултата, в противен случай 0. 10 е константа, получена експериментално;
7. Запазете текущата позиция в prev_pos (prev_pos := pos)
8. Повторете, като започнете от стъпка 3, докато прочетем целия файл;
9. Полученият битов масив трябва да бъде записан като набор от байтове. Тъй като не взехме предвид синхронизиращия байт при четене, броят на битовете може да не е кратен на 8 и необходимото битово отместване също е неизвестно. При първото изпълнение на алгоритъма не знаех за съществуването на синхронизиращия байт и затова просто запазих 8 файла с различен брой отместени битове. Един от тях съдържаше верни данни. В крайния алгоритъм просто премахвам всички битове до A5h, което ми позволява незабавно да получа правилния изходен файл

Алгоритъм в Ruby, за интересуващите се
Избрах 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*")

Резултат

След като опитах няколко варианта на алгоритъма и константите, имах късмета да получа нещо изключително интересно:

И така, съдейки по символните низове, имаме програма за изчертаване на графики. В текста на програмата обаче няма ключови думи. Всички ключови думи са кодирани като байтове (всяка стойност > 80h). Сега трябва да разберем кой компютър от 80-те може да записва програми в този формат.

Всъщност тя е много подобна на BASIC програма. Компютърът ZX Spectrum съхранява програми в приблизително същия формат в паметта и ги записва на лента. За всеки случай сверих ключовите думи маса. Резултатът обаче очевидно беше отрицателен.

Проверих и BASIC ключовите думи на популярните Atari, Commodore 64 и няколко други компютъра от онова време, за които успях да намеря документация, но безуспешно - познанията ми за видовете ретро компютри се оказаха не толкова широки.

Тогава реших да отида Списъкът, и тогава погледът ми попадна на името на производителя Radio Shack и компютъра TRS-80. Това са имената, които бяха написани на етикетите на касетите, които лежаха на масата ми! Не знаех тези имена преди и не бях запознат с компютъра TRS-80, така че ми се стори, че Radio Shack е производител на аудиокасети като BASF, Sony или TDK, а TRS-80 е времето за възпроизвеждане. Защо не?

Компютър Tandy/Radio Shack TRS-80

Много е вероятно въпросният аудиозапис, който дадох за пример в началото на статията, да е направен на компютър като този:

Оказа се, че този компютър и неговите разновидности (Модел I/Модел III/Модел IV и т.н.) са били много популярни по едно време (разбира се, не в Русия). Прави впечатление, че процесорът, който използваха, също беше Z80. За този компютър можете да намерите в интернет много информация. През 80-те години компютърната информация се разпространява в списания. В момента има няколко емулатори компютри за различни платформи.

Изтеглих емулатора trs80gp и за първи път успях да видя как работи този компютър. Разбира се, компютърът не поддържаше цветен изход; разделителната способност на екрана беше само 128x48 пиксела, но имаше много разширения и модификации, които можеха да увеличат разделителната способност на екрана. Имаше и много опции за операционни системи за този компютър и опции за внедряване на езика BASIC (който, за разлика от ZX Spectrum, при някои модели дори не беше „флашнат“ в ROM и всяка опция можеше да бъде заредена от флопи диск, точно като самата ОС)

Аз също намерих полезност за конвертиране на аудио записи във формат CAS, който се поддържа от емулатори, но по някаква причина не беше възможно да прочета записи от моите касети с тях.

След като разбрах файловия формат CAS (който се оказа просто малко по битово копие на данните от лентата, която вече имах под ръка, с изключение на заглавката с наличието на синхронизиращ байт), направих няколко промени в моята програма и успях да изведа работещ CAS файл, който работеше в емулатора (TRS-80 Model III):

Проектирах най-новата версия на помощната програма за преобразуване с автоматично определяне на първия импулс и разстоянието между референтните импулси като GEM пакет, изходният код е достъпен на Github.

Заключение

Пътят, който изминахме, се оказа увлекателно пътешествие в миналото и се радвам, че в крайна сметка намерих отговора. Между другото аз:

• Разбрах формата за запазване на данни в ZX Spectrum и проучих вградените ROM процедури за запис/четене на данни от аудио касети
• Запознах се с компютъра TRS-80 и неговите разновидности, проучих операционната система, разгледах примерни програми и дори имах възможност да правя отстраняване на грешки в машинни кодове (в края на краищата всички мнемоники на Z80 са ми познати)
• Написа пълноценна помощна програма за конвертиране на аудио записи във формат CAS, която може да чете данни, които не се разпознават от „официалната“ помощна програма

Източник: www.habr.com