不明なフォーマットのデータを磁気テープから復元した方法

背景

レトロ ハードウェアの愛好家である私は、かつて英国の販売者から 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 テープロードエラー」というエラーメッセージを表示します。 厳密に言えば、コンピューターは、読み取り時にパルスを認識できない場合（パルスが欠落しているか、パルスの持続時間が特定の制限に対応していない場合）、このメッセージをより早く発行することができます。

それでは、未知の信号がどのようなものかを見てみましょう。

これがパイロットトーンです。 信号の形状は大きく異なりますが、信号が特定の周波数の短いパルスの繰り返しで構成されていることは明らかです。 サンプリング周波数 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 つのファイルを保存しました。 そのうちの 5 つに正しいデータが含まれていました。 最後のアルゴリズムでは、AXNUMXh までのすべてのビットを単純に削除するだけで、正しい出力ファイルをすぐに取得できるようになります。

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 コンピューターは、プログラムをほぼ同じ形式でメモリに保存し、プログラムをテープに保存します。 念のためキーワードを調べてみました テーブル。 しかし、結果は明らかに陰性でした。

また、当時人気のあった Atari、Commodore 64、その他いくつかのコンピューターの BASIC キーワードもチェックし、ドキュメントを見つけることができましたが、成功しませんでした。レトロ コンピューターの種類に関する私の知識はそれほど広くないことが判明しました。

それから私は行くことにしました リストと思ったとき、Radio ShackというメーカーとTRS-80というコンピューターの名前に目が止まりました。 これは私のテーブルに置いてあったカセットのラベルに書かれていた名前です！ 私はこれらの名前を以前は知りませんでしたし、TRS-80 コンピューターにも詳しくなかったので、Radio Shack が BASF、Sony、TDK などのオーディオ カセット メーカーであり、TRS-80 が再生時間であると考えていました。 なぜだめですか？

コンピュータータンディ/ラジオシャック TRS-80

記事の冒頭で例として挙げた問題の音声録音は、次のようなコンピュータで作成された可能性が非常に高いです。

このコンピューターとその種類 (モデル I/モデル III/モデル IV など) は、かつて非常に人気があったことがわかりました (もちろんロシアではありません)。 彼らが使用したプロセッサもZ80であることは注目に値します。 このコンピュータについては、インターネットで見つけることができます 多くの情報。 80年代、コンピュータ情報は次のように流通しました。 雑誌。 現時点ではいくつかあります エミュレータ さまざまなプラットフォーム用のコンピューター。

エミュレータをダウンロードしました trs80gp そして初めてこのコンピュータがどのように動くのかを見ることができました。 もちろん、コンピューターはカラー出力をサポートしておらず、画面解像度は 128x48 ピクセルのみでしたが、画面解像度を上げるための拡張機能や修正が数多くありました。 このコンピュータのオペレーティング システムには多くのオプションがあり、BASIC 言語を実装するためのオプションもありました (ZX Spectrum とは異なり、一部のモデルでは ROM に「フラッシュ」さえされず、どのオプションもフロッピー ディスクからロードできました。 OS自体）

私も見つけました ユーティリティ オーディオ録音をエミュレーターでサポートされている CAS 形式に変換するために使用しましたが、何らかの理由で、それらを使用してカセットから録音を読み取ることができませんでした。

CAS ファイル形式 (同期バイトが存在するヘッダーを除いて、既に手元にあったテープからのデータを少しずつコピーしたものであることが判明) を理解した後、次のファイルを作成しました。プログラムにいくつかの変更を加えることで、エミュレータ (TRS-80 モデル III) で動作する正常に動作する CAS ファイルを出力することができました。

最初のパルスと基準パ​​ルス間の距離を自動決定する変換ユーティリティの最新バージョンを GEM パッケージとして設計しました。ソース コードは次の場所で入手できます。 githubの.

まとめ

私たちが歩んできた道は、過去への魅力的な旅となりました。最終的に答えを見つけられたことを嬉しく思います。 とりわけ、私は:

• ZX Spectrumでデータを保存するフォーマットを考え出し、オーディオカセットからデータを保存/読み出すための内蔵ROMルーチンを研究しました。
• 私は TRS-80 コンピュータとその種類について知り、オペレーティング システムを研究し、サンプル プログラムを調べ、マシン コードでデバッグを行う機会さえ得ました (結局のところ、Z80 ニーモニックはすべて私に馴染みがありました)。
• オーディオ録音を CAS 形式に変換するための本格的なユーティリティを作成しました。これにより、「公式」ユーティリティでは認識されないデータを読み取ることができます

出所： habr.com