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

Предистория

Като любител на ретро техниката, по някакъв начин закупих ZX Spectrum+ от продавач във Великобритания. Заедно с компютъра получих няколко аудиокасети с игри (в оригиналната опаковка с инструкции), както и програми, записани на касети без специални обозначения. Учудващо, данните от касетите на 40 години бяха добре четими и успях да заредя почти всички игри и програми от тях.

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

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

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

отговорът беше точно пред очите ми през всичкото време
На етикета на лявата касета — името на компютъра TRS-80, а малко по-долу името на производителя: „Manufactured by Radio Shack in USA“

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

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

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

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

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

Трябва да спомена и самата форма на сигнала. Например, при ZX Spectrum формата му е квадратна:

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

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

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

За да се увери, че данните са заредени правилно, ZX Spectrum чете последния байт, известен като байт на паритета  (parity byte), който се изчислява при запис на файла чрез операция 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 не гарантира, че ще попаднем в позицията на следващия референтен импулс (дефекти на лентата, нестабилна работа на механизма за предаване на ленти и др.), е необходимо да коригираме позицията на импулса pos. За целта ще вземем малък участък от данни (pos-8;pos+8) и ще намерим максимума на стойността на амплитудата. Позицията, съответстваща на максимума, ще запазим в pos. Тук 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

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

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

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

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

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

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

Заключение

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

• Разбрах формата на запазване на данните в ZX Spectrum и изучих вградените в ПЗУ подпрограми за запазване/четене на данни от аудиокасети
• Се запознах с компютъра TRS-80 и неговите разновидности, изучих операционната система, разгледах примери за програми и дори имах възможност да се занимавам с отладка в машинни кодове (все пак всички мнемоники Z80 ми са добре познати)
• Създадох цялостен инструмент за конвертиране на аудиозаписи в CAS формат, който може да чете данни, неразпознавани от "официалния" инструмент.

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