30年前のノートPCからファイルをコピーする方法
(unterminated.com)- 1994年製のApple PowerBook Duo 280c に残っていた短い音声録音を保存する必要があったが、音声出力・フロッピー・ネットワーク・ディスクアダプタの手段がすべて塞がれていたため、ファクス送信が迂回経路になった
- ResEditの16進エディタで音声ファイルを16進テキストとして開き、Microsoft Wordに貼り付けた後、印刷ダイアログのファクス機能で送信した
- 受信はWindows XPを搭載したThinkPad T60の内蔵モデムとファクスアプリが担当し、2台のノートPCを直接電話線でつなぐ代わりに、9V電池ベースの電話線シミュレータ回路が必要だった
- TIFファクス画像をOCRで戻す方法では、0/C、9/4、0/Dの誤認識や欠落・挿入エラーのため、音声にクラックルやポップノイズが残った
- 最終的に固定幅文字グリッドを直接解析するFaxToBinaryツールを作り、文字パターンを手動学習させて、原本とバイト単位で一致する音声ファイルを復元した
行き止まりだったコピー経路
- 対象機器は1994年製のPowerBook Duo 280cで、内部には保存したい短い音声録音がいくつか入っていた
- 幸いノートPCはまだ起動し、ハードドライブを軽く叩くと回転し、音声ファイルは内蔵スピーカーで再生できた
- 一般的なコピー方法は順番に塞がれていた
- オーディオジャックがなく、高品質なアナログコピーが難しかった
- 内蔵ハードドライブは特殊コネクタのSCSIを使っており、最新システムで古いHFSファイルシステムを簡単に読めるかも不確かだった
- 外付けフロッピードライブを接続するとコンピュータが動作せず、故障原因も突き止められなかった
- AppleTalkポートと電話ジャックはあったが、ネットワークソフトウェアがインストールされていなかった
- HTTPが確定したのは1996年で、そのノートPCには当時使えたはずのダイヤルアップ用ソフトウェアもなかった
- その代わり電話ダイヤラとファクスソフトウェアが残っていたため、モデムを使った迂回が可能になった
ファイルをファクス文書に変換する
- ノートPCにはゲームと一緒にリソースエディタのResEditがインストールされており、このツールの16進エディタでファイルの生データを16進数で見られた
- ResEditは出力機能をサポートしていなかったため、16進テキストを別アプリへ移す必要があった
- 例の音声ファイルは37,928バイトで、各バイトが2文字の16進数で表示されるため、テキスト表現はその2倍の長さになった
- 一度に扱えるサイズに制限があったため、ファイルを分割してコピーし、オフセットを覚えやすい12288バイト、つまり0x3000単位で処理した
- クリップボードでコピーした16進テキストはMicrosoft Word文書にそのまま貼り付けられ、Wordは出力機能を提供していた
- ファイルはすべて100KB未満で、ResEditからWordへクリップボード経由で手動コピーする速度は平均約316バイト/秒と見積もられた
2台のノートPCの間に模擬電話線を作る
- 受信用コンピュータは内蔵ダイヤルアップモデムを備えたThinkPad T60で、Windows XPのファクスアプリは受信ファクスを複数ページのTIF画像として保存できた
- 2台のノートPCを電話ケーブルで直接接続する方法は失敗した
- PowerBookは発信したがThinkPadが応答しなかった
- “Ignore Dial Tone”オプションも効果がなかった
- 実際の固定電話網が提供する電圧がモデム動作に重要であり、この問題はphone line simulator circuitで解決した
- この回路は一般的な電子部品と9V電池で作れ、2台のノートPCの間に模擬電話線を提供した
- ファクス送信にはFCC要件によりカバーページが必要で、カバーページを追加した後に送信が進んだ
- 当初はラスタライズ後の送信時間が24分と見積もられたが、フォントサイズを下げて6ページ・7分に短縮し、ファクスは14400bpsでThinkPadに受信された
OCRでは残るエラー
- ThinkPadが受信したファクスはTIF画像で、これを再びバイナリファイルに変換するため、まずPDF変換とOCRを試した
- ファクス画像はOCRに有利に見えた
- テキストがコンピュータ生成で、配置や形が一定していた
- 使用文字は0-9とA-Fの16種類しかなかった
- Courierという一般的な固定幅フォントを使っていた
- OCR結果のテキストを選択して16進エディタにコピーし、バイナリファイルとして保存できた
- Audacityは結果ファイルの音声形式をunsigned 8-bit PCM、little-endian、22050Hz、monoと推定し、波形も表示した
- 再生はおおむね良好だったが、波形の急なディップがOCR転記ミスによるクラックルまたはポップノイズとして聞こえた
- 複数のOCRプログラムやフォントサイズ・フォント変更を試しても、100%の精度には到達しなかった
- 0とC、9と4、0とDを混同した
- 文字を欠落させたり、新しい文字を挿入したりする場合もあった
FaxToBinaryでバイト単位の復元
- ファクス画像のテキストは固定幅フォントで生成されていたため、文書全体を一定間隔の文字グリッドとして扱えた
- 開始位置、文字オフセット、行間を合わせると、各文字を個別にキャプチャして解析できた
- 自作ツールは左側プレビューでサイズやオフセットのパラメータが合っているか確認でき、文字を移動したり行を変えたりしてもドリフトがなければ処理を開始できた
- 文字認識は単純な手動学習方式で動作した
- 初めて見る固有パターンごとに、ユーザーがその文字が何かを指定する
- 以後は同じ形の文字に出会うと、前の答えを記憶して再利用する
- ツールのソースはFaxToBinary.zipとして提供されている
- 少し手動学習を行った後、ツールはファイルを出力し、音声はポップノイズなしで滑らかに再生され、原本とバイト単位で一致するコピーになった
- ファイル復旧後には、そのPowerBookでDOOMも動作した
2件のコメント
ただの感想。
Hacker News のコメント
古いコンピュータ雑誌の16進ダンプをOCRしているときに似た問題に遭遇し、OCR結果を検証するツールを作って解決した。
OCR結果を入力して数字を分割すると、元画像から切り出した文字を分類ごとに表示し、人間が目で見れば「8」グループに入った「3」のような誤分類をすばやく見つけられる。
https://blog.qiqitori.com/2023/03/ocring-hex-dumps-or-other-...
https://blog.qiqitori.com/2023/03/ai-day-in-retroland-prolog...
関連記事を2本書いており、ツールも記事内でリンクしている。ただしツールの使い勝手はsendmailよりほんの少し良い程度。
古いAppleノートPCにプログラミング環境や当時のMicrosoft Wordに似たものがあったのかは分からないが、ハードウェアをいじらなくてももっと良い方法があったように思う。
より良い方法は、モデムポートでFAXを送るよりシリアルポートを使うことだったのではないか。シリアル-USBアダプタは簡単に手に入る。
基本的には2回目のパスで各文字グループの外れ値を見つけ、別のグループに一時的に再分類し、関連グループの類似度スコアが改善すれば維持し、改善がなくなるまで繰り返す方式。
例えば「他の3と最も似ていない3」を見つけて一時的に「8」に入れ、「3の断片同士がどれだけ似ているか」と「8の断片同士がどれだけ似ているか」のスコアが改善すれば、その変更を維持できる。
ただし文書に複数の書体が混在していると、異なる書体の「3」を一緒にまとめてグループ類似度スコアを悪化させるような逆効果があり得る。
そのノートPCにはシリアル（COM）ポートがあったのでは？ 当時はほぼ一般的だったし、このサイト[1]によると2つあった。
Zmodemで済ませれば簡単だったはずで、ターミナルソフトもすでにあったように思う。
[1] https://everymac.com/systems/apple/powerbook_duo/specs/mac_p...
ただしPowerBook側でシリアル受信できる何かが必要。ClarisWorksなら確実に可能だったし、Officeにも同じ「文書を受信」機能があった可能性が高い。
あるいはシリアルポートへ「印刷」して、シリアル出力をキャプチャしてもよい。実質的には一方向のテキスト転送だが、筆者がやろうとしていたことには十分。
それでもFAXで送ってOCRする方法はかなり格好いい。
ノートPCにターミナルアプリがインストールされていた記憶はないが、十分に探していなかった可能性もある。
最初は古いノートPCの画面を写真に撮ってOCRするのかと思ったが、実際の方法はずっと面白かった。
それでも大きなフォントにして転送に24分かけるほうが早かったかもしれない。更新されたOCRソフトを書くのに24分以上かかった可能性が高い。
ただ、それでは面白くなかっただろう。
記事では簡潔にするため省いたが、実際には複数のフォントと文字サイズを1ページずつ試して手動で確認し、大きな改善はなかった。
[0] https://social.immibis.com/notice/AeWSRvyKlhBB2hANoe
若い頃、CP/MデスクトップからMS-DOSのポータブルPCへdBase 2データベースを取り出さなければならなかったことがある。
シリアルケーブルを設定してPCでPROCOMMを実行し、両方のポートを9600/n/8/1に合わせ、dBase 2で印刷しながらPROCOMMにセッションをファイルへ記録させた。
フロッピーへの書き込みのために長く止めずに動かすと文字が欠落したので、CP/M側でctrl-s/qを使ってフロー制御した。
当時は、こういうやり方を思いついた人は誰もいなかったように思う。
それでもモデムが入っていたなら、ターミナルソフトウェアもあったはずだと記憶している。
AppleTalkが正解に近い。ドライバは内蔵されており、Appleは長期にわたる互換性をうまく維持していた。
IIGSと現代の機器との間でファイルを移す際に似た問題を経験したが、フロッピーエミュレータ、SCSI、生のシリアル通信でも可能ではあるものの、AppleTalkとEthernetの両方を備えたMacを中継に置けば、対象のAppleTalkベースの機器とSMBのような共有との間で、ファイル階層全体をドラッグ＆ドロップで移せるので単純だ。
SCSIも、ドライブのコネクタと種類を把握し、いくつかのアダプタをチェーン接続する気があれば、たいてい変換しやすい。2.5インチSCSIドライブはSCA系コネクタだったと記憶しているし、シングルエンド／差動のルールさえ守れば、ほぼ何でも相互接続できるSCSIアダプタがある。
問題は古いMacのファイルシステムを読めるOSやツールを見つけることだが、生イメージを読むユーティリティのどれかでディスクイメージを読み書きできたはずだ。
おそらく別の場所に接続してデータをコピーする作業はかなり単純だった可能性が高い。30年以上前のハードウェアもこのように頻繁に扱う場所で働いているが、要点はソフトウェアによる解決策という枠から抜け出すことだ。
これはソフトウェアの問題ではなく、ほとんどの場合、別種の専門性が必要になる。
SCSI変換については私も同じ考えで、投稿者はHFSボリュームを読めるか確信がないと言っていたが、Linuxにはすでに何十年も前からHFSドライバがある。
この場合はPowerBook DuoとSCSIディスクなので、Duo Dockのような装置[2]、HDI-30変換アダプタ[3]、そしてパラレルSCSIデバイスを現代のシステムに接続するためのケーブル・コンバータ・コントローラの組み合わせが必要になる。
PCI ExpressスロットやThunderbolt PCI Expressエンクロージャを備えた機器なら、eBayで50ドル未満のLSI Logic Ultra320アダプタを勧める。macOS、Linux、Windows用ドライバは簡単に入手できる。
準備ができたら、SCSIケーブルでMac同士を接続し、PowerBookの起動中にTを押してターゲットディスクモードに入り、OSが読めないディスクをフォーマットするか尋ねてきたら、必ず「いいえ」と答えればよい。
HFSファイルシステムへのアクセスは、macOS基準では生ディスクイメージを作成し、バックアップしたうえでqemuにMac OS 9をインストールしてイメージを接続し、Alsoft PlusMakerでHFSをHFS+へインプレース変換した後、現在のmacOSでイメージをマウントする方法が最も完全で簡単に見える。
おまけに、元のPowerBookのハードディスクにあるアプリの大半を現代のMacで実行できる、エミュレートされたMac OS 9システムも手に入る。
[1] https://developer.apple.com/library/archive/technotes/tn/tn1...
[2] https://en.wikipedia.org/wiki/PowerBook_Duo#Docking_stations
[3] https://www.amazon.com/dp/B0081SAIS2/
[4] https://www.broadcom.com/support/download-search?pg=Legacy+P...
[5] https://wiki.qemu.org/Documentation/GuestOperatingSystems/Ma...
[6] https://www.macintoshrepository.org/19-plusoptimizer-plusmak...
[7] https://www.macintoshrepository.org/809-stuffit-deluxe-1-5-x...
[8] https://www.macintoshrepository.org/1724-toast-5-titanium
これは実践的な情報理論の試験みたいで良い
「32,000バイトのファイルを任意のチャネルで送信せよ。どのチャネルも何らかの形で使い勝手が悪い。スマートフォン、シリアルポート、コンピュータがある。コンピュータにはコンパイラはないが、基本機能は何でも使える。送信するファイルより多くの入力バイトを必要とする解法、たとえばスクリプトは失格。時間制限はないが、最速の解法が勝つ。開始」
古いMacなら筆者よりうまくやれたかは分からない。ただ、3と8のように見た目が似た文字を、8→Zのようにはっきり区別できる文字に置き換えられるなら、スマートフォンで画面を撮影してOCRする方法が最速かもしれない、という誘惑はある
System 7にはAppleScriptがあった気がするので、sedのような置換ステップは可能だったかもしれない
hfsprogsをインストールしてドライブをマウントし、必要なファイルを抜き出せば終わり
独自コネクタが問題になる可能性はあり、その場でのはんだ付けのような回避策が必要になるかもしれないが、幸い古い機器はそうしてもかなりうまく動く
正直、ハードウェア寄りの人間の強みだと思う
なので、エラーが極めてまれになるエンコーディングを探すと思う。ノートPCのドライブ全体をダンプしなければならないなら、速いがエラーが出る方法より、ノートPCを1週間つけっぱなしにするほうがよいと思う
単純計算で320MBを1週間で送るなら毎秒530バイト。画面を4Hzで表示してスマートフォンで録画すれば、フレーム落ちや変なアーティファクトはないと仮定でき、1フレームあたり約135バイト、つまり1080ビットになる
8.4インチの640×480画面を16×16ピクセルの正方形に分けると、0.5cm程度のマスが1000個できる。各マスを0.25秒間白黒で表示すれば、カメラのアーティファクトがデータに大きく影響せず、必要な帯域幅にほぼ合う
文字をOCRしないので上で出た問題は減るだろうが、まずそのプログラムをマシンに入れなければならない
内蔵ハードディスクが特殊なコネクタのSCSIなのでアダプトは簡単ではなさそう、というくだりは、実はSCSIバスを使えばよい話だった
SCSIは複数のマスターがバスを共有できるバスマスタリングプロトコルなので、2台のコンピュータを同じSCSIバスに同時につなぎ、ディスクデバイスに共同でアクセスできる。ファイルシステムの同時書き込みを信用してはいけないが、当時のディスク全体は今では大きなファイル1つにすぎないので、丸ごとダンプすればよい
開いたファイルシステムの不整合はクラッシュリカバリと同程度で、長く保存されていたファイルには影響しなかったはず
古いHFSも、オープンソース／New Jerseyスタイルの良さのおかげで、Linuxでループバックマウントするのはとても簡単だったはず
1988年製の古いMac SE20のディスクイメージ全体を今も持っていて、ときどきマウントしている。それもSCSIバス経由で取り出した。20は68020プロセッサのMHzを意味していた気がするが、偶然20MBディスクも載っていて、翌年のSE30も似たようなものだった
FAXソフトウェアを使った部分は、昔考えただけで実行しなかったアイデアを思い出させる。FAXの送付状に文書の.DOC形式をエンコードした大きなQRコードのようなものを入れておけば、普通のFAX機でも送れ、受信側がコンピュータのモデムなら元の形式の文書を受け取って、残りのFAX送信をハンドシェイクで中断できたはず
古いFAX技術をなめらかに移行する方法になったと思う
数年前、Macintosh Plusと現代のコンピュータの間でファイルをやり取りしようとして、かなり時間をかけた
当時は100MB ZIPドライブを2台、つまりMac Plus用のSCSIと現代のコンピュータ用のUSBを使い、後にはターミナルソフトでシリアルポート接続を使った [1]
今なら、より良く安価な選択肢としてBlueSCSI[2]がある。SDカードに保存された.imgファイルをHDDディスクとしてマウントできるSCSI HDDエミュレータで、CDとネットワークカードのエミュレーションにも対応している
ファイルをこうした仮想ドライブにコピーした後は、現代の機器でHFSエクスプローラやエミュレータを使って抽出できる
[1] https://blog.rekawek.eu/2016/12/08/mac-plus#hard-drive
[2] https://bluescsi.com/
本当にワクワクする記事だったし、私の限られたコンピューター知識では複雑すぎた
1993〜1994年ごろ、ほかの出来事との順序を思い出すと、起動しないIBMのノートPCを「直す」機会があった。分厚くて重く、大きかったが、画面は3.5インチフロッピーほどのサイズだった
写真でもほかの場所でもそのようなノートPCを見たことがないので、当時の基準でもさらに古いものだったのだと思う。何か分かる人がいれば写真を見てみたい
時代遅れの変人で、近所のおじさん兼メンターのような人が修理してみろと渡してくれて、私は数日間それを机の上に置いて自慢していた。たぶんAUTOEXEC.BATを書き換えてWordStarを読み込むという、間抜けで単純な方法で直したのだと思う。必要だったのもDOS上のWordStarだけで、Windows 3.xですらなかった
そのノートPCは、故郷の地元教会を訪れていたキリスト教宣教師たちがくれたものだった可能性が高い
ほかにもコンピューター修理の話はあるが、詳細を思い出して書く必要がある。山中の軍の兵舎で寝て、用を足すときには武装警備が付き、妊婦を救急車で介助しながら帰宅したという話だ。その「ミッション」は幼なじみの近所の友人と一緒だったが、彼は亡くなり、その時代錯誤なおじさんも亡くなった。互いに関係はない
ただし、その画面は3.5インチフロッピーよりは少し大きかったはずで、3.5インチフロッピーもなく5.25インチだけをサポートしていた。Osborne 1や80年代初頭のポータブルコンピューターにはもっと小さい画面があったが、DOSは動かなかったはず
もう一つの候補はPC Convertible: https://en.wikipedia.org/wiki/IBM_PC_Convertible
「FAXソフトウェア」があったなら、ほぼ間違いなくターミナルエミュレーターもあったはずで、ZMODEMのようなものでファイルを壊さず送れたはず
精密ドライバーの代わりにバターナイフを使っているのを見るようで、読んでいてつらかった