WindowsのHDD復元ソフトウェアで、ディレクトリとファイルの復元を試みた。
次に、ディレクトリと曲名の対応のあたりを付け、
続いて、ドライブルートにあるSONGLIST.VS1と、プロジェクト（曲）毎のSONG.VS1をバイナリエディタで比較、編集して、VSで読めるかどうかを試みた。
■経過報告
まだVSで正常に読めるところまで行っていない。
仮説として、LIST表示時には、まずSONGLIST.VSを読みに行き、頭からの連番でディレクトリ内を見に行くと想定している。
■ファイル・ディレクトリの復元
LOST_DIR_[n]の名前のディレクトリが復元される。
これはディレクトリを正しく戻せているのではなく、ファイル日付などから復元ソフトが類推して固めてくれているに過ぎない。
復元ソフトによってディレクトリが分からないものはLost_Locationというディレクトリで復元されるので、ファイル日付で固めてサブフォルダuk0000のようなフォルダに入れた（uk:unknown）
復元したフォルダとプロジェクト名（ファイル名）の整合を取った時に、不足分があれば、ここから引っ張ってくる想定。
■ディレクトリのリネーム、SONG特定
ゼロ埋めの連番のSONG0001.VS1のようなディレクトリ名にするため、リネームをかける（図はLibreOfficeでリネーム用のバッチコマンドを生成しているところ）
ずばっと一気にリネーム。
下記のようなフォルダ名にリネームされた
各フォルダの中には（願わくば）SONG.VS1というプロジェクト名が記載されたファイルがあるので、こいつらをまとめてテキスト保存して、プロジェクトフォルダ名とプロジェクト名（曲名）を確認していく。
またしてもLibreOffice上でファイルコピー用のコマンドを生成する。
（セルを選択してテキストをコピー、メモ帳などでペーストし、.batファイルとして保存して、実行）
保存されたSONGS.VS1ファイル達と、一つを開いたところ。
SONGS.VS1ファイルには、プロジェクト名が記載されていることが分かる。
（この例では167番目のフォルダが、EL&PのJerusalemだということ）
生成されたテキスト（SONG.VS1のコピー）の中身を参照しながら、LibreOfficeで曲名と連番フォルダの対応を確認する
そもそもフォルダが無いもの（0049,0050）や重複（0060と0061）があるが、ファイル実態のタイムスタンプを見ると、日付違いで同じ曲を保存したモノらしい。もしくは編集履歴をずっと取っているのかな（UNDO,REDOとかできるように）
※どちらを使うか迷ったら、日付を比較して新しい方を採用しておけば問題なさそう。
■まずは、1曲分を戻してみる
ここからはVSから引っこ抜いたパーティショニング済SSDをPCに接続して、Dドライブとして認識されたパーティションに、1曲分のプロジェクトを入れてみる。
まずはSONG0001.VS1を削除して、SONG0085.VS1をSONG0001.VS1とする。
この曲は城南海のAitsumugiという曲なので、SONG.VS1のInitProjectの文字列を、Aitsumugiと変えておこうか（当初は強引にもテキストエディタで書き換えた）
・レッツ起動！
「ありゃりゃ。なんだこの文字化けは。」
やはり、バイナリとして編集しないとダメか。
（そもそもバイトの並びも調べずに）
選択して、ロードするも、トラックは空。
実体ファイルを読んでいない様子。
・VSで強引に開いた後
プロジェクトを保存していないのに、ファイルサイズ2Mになっている。
（このプロジェクトは401MBあるはずなのに）
なんと、InitProjectに変更されてしまう。
SONGLIST.VS1の記述を元に、保存しなおしてしまうのか！
そうか、フォルダとファイル実体があっても、これを強引に読むようなことはしないんだ。
SONGLIST.VS1とかSONG.VS1ってのがレジストリのようなものなんだな。
■バイナリを見てみる
バイナリエディタBzをダウンロードして、これで.VS1ファイルを見てみよう。
バイナリの中身までは分からんが、なんとなく固定長でプロジェクトの設定情報が羅列されているのではないか？と推測する。
固定長というのが何バイトなのか分からんが、恐らく44バイトのような気が。
・SONG.VS1の比較
InitProjectのSONG.VS1と具体的な曲が入っているSONG.VS1の比較
両者綺麗に44バイト。
なんとなく44バイト単位な気がする・・・の根拠。
・SONG.VS1とSONGLIST.VS1の比較
次にSONGLIST.VS1のフォーマットを類推する。
先のSONG.VS1ファイルが綺麗に44バイトだったので、恐らくそのまま続けてか、何か区切りバイトを挟んで、シリアルにつなげているだろうと推測。
反転させている部分が、最初の44バイトの次の44バイト
・バイナリの固定長で見れるエディタEdbixで見てみる
曲名が綺麗に並んでいるのが分かる。
0Eから19までの12バイト分だ
更に連番を発見。
プロジェクト名の直前のバイト、0Dを縦に見ると連番になっている。00からFFまでで256まで付番できる。仕様を見ると、各パーティションで200のプロジェクトを持てると書かれているので、ファイル仕様の256までと整合する。
データがないところのフォーマットを見ると
0C,0DにFFが入っている。区切りバイトではなかろうか。
先ほど、プロジェクト名が入っていた0Eから19までの12バイトには初期値として20が入っていて、その他は00で埋められている。
ASCIIコード表でHEXの20はスペース文字だ。当然ながら00はNULL
よし、曲が定義されていないところのレコードはこれを埋めておこう。
・資料を発見
VS-2400の紙マニュアルで”VS-2400CD 資料”というのがあり、この中にMIDIのエクスクルーシブメッセージとしてプロジェクトパラメータの記載がある。
推測だが、MIDIのシステムエクスクルーシブメッセージも、シリアル通信でバイト列を流すだけなので、当然固定長だろう。
一応、ここで参考にできることは、プロジェクト名が12バイトて定義されているよーーっていうことくらいか。
