■前回まで
SONGLIST.VS1とSONG.VS1の関係性から、SONGLIST.VS1がレジストリになっていて、フォルダ名の命名規則や読み込むべくファイルの情報を得ていることが分かったところまでが前回。
VS-2400CD データリカバリー① ファイルシステムの復元と解析らしきこと - y-matsui::weblog (hatenadiary.org)
■今回の結論
・SONGLIST.VS1のフォーマットを解明した。
・VS-2400CDで実際に手動作成したプロジェクトファイルを読み込めた。
・チェックディスク機能で整合のチェックが出来ることを知った
・とはいえプロジェクトが完全な形で復元できていない場合がある（むしろ多い）
■正解にたどり着くまでの長い道のり
①②③の繰り返しを成功するまで。
①バイナリエディタですること
・フォルダを並べたい順にリネーム配置する
・リネームしたフォルダの番号と同じになるようSONG.VS1の一部を修正する
・SONG.VS1の内容をSONGLIST.VS1に転記する
・SONGLIST.VS1の修正をする（←ここがみそ）
②VS-2400CDですること
・起動する（正解にたどり着くまでは正常にプロジェクトリストを目にすることはない）
・チェックディスクを行い、デバッグ情報を得る
③バイナリエディタですること
正常に起動するプロジェクトのファイルと、今編集しているプロジェクトのファイルを比較する（目を皿のようにして）
②に戻る
■ファイルの配置
・プロジェクトフォルダはSONG0000.VS1~連番で配置しなければならない
・フォルダ名称の連番部分は、SONG.VS1とSONGLIST.VS1の連番部分と正確に一致していなければならない
・各プロジェクトフォルダ配下のSONG.VS1の記載内容とSONGLIST.VS1の記載内容は完全に一致していないといけない。（SONG.VS1からSONGLIST.VS1を生成していれば一致しないことがあり得ない）
■SONGLIST.VS1のフォーマット（本邦初公開！貴重なハック資料と自任）
完全に全部のバイトを解明できたわけではないが、少なくともプロジェクトを起動できる程度には、内部を解明できた。
「こんなのわかるかー！」な部分は三ヵ所あった。（今は分かってせいせいしている）
・SONG.VS1とSONGLIST.VS1の構造（整合）
ちょっと細かいが、SONGとSONGLISTの対応状況が下記。
基本的には、SONGSの06-26までの列値を、SONGLISTの0A-2Bまでの列にコピーする。
実物を見るとこんな対応状況だ。
コピー・ペーストする部分に含まれる情報
SONGLISTの列
0D：連番（ID）
0E~19：プロジェクト名称（12文字）
20-2B：最終更新日時、作成日時
06,07及び0A,0B：なんらかのチェックサム？
1A~1F：未解明
・SONG.VS1で編集すべきところ
09：連番（0から開始、プロジェクトフォルダの番号と一致させる必要がある）
ここを編集したら06-27までのバイト列をクリップボードにコピーして、SONGLISTの方を編集（コピペ）する。
・SONGLISTの編集手順
①SONGからの情報ペースト
まずは、上記でSONG.VS1の内容（クリップボードの内容）を、0A-2B列にペーストする。前述の通り、含まれるのは連番とプロジェクト名称、更新日時、作成日時ほか。（恐らく録音モードに関する情報）
②06,07の編集（「こんなの分かるかー」その1）
0Aの値を06に転記
0Bの値に2プラスした値を07に手入力
※なぜか分からないが、正常に読み込めるプロジェクトファイルはすべてそのルールになっていた。なんらかのチェックサムなのか。
これから復元しようとする全部のSONGをSONGLISTに転記できたら、最後の仕上げに③を実行する。
③01の値を編集「こんなの分かるかー」その2）最重要
01のフィールドが死ぬほど重要
ここには、SONGLISTに含まれる、有効なプロジェクトの数が記載されている。
なので、10曲のレコードとプロジェクトフォルダあるならHEX（十六進数）で0Aと書いて無ければならない。
VSが最初にSONGLISTを見たときに、「これから○○曲分のデータがあるよー」と伝えるヘッダの役割何だろう。（推測）
※ここが00だったり、不整合な数字が入っている場合は、エラーを吐く。
（実態とレジストリが違うんだから当然といえば当然。信頼性に欠けると判断される）
■おまけ：こんなの分かるかー！の三つ目
別に知らなくても何も困らない※が、SONGLIST.VS1の20から2Bまでの意味。
知っていたらなんか、安心するというか、色々疑わなくても良いので、知っておいた方が良いかなと。
※（SONG.VS1をコピーしているので、値が間違っているということが無いので）
正常にロードできるプロジェクトをVSで見たときに、例えば
”LVBSonata#20”のVS上の日付表示が
2022/2/1 16:48
となっていたので、SONGLISTのバイナリと比較していると
こんな感じの対応にあることが分かった。※
更新日（必ず作成日よりも後の日付になっているので）
20：dd
21：mm
22：西暦
23：西暦
最終更新日時の日付時刻？
24：秒？（秒なら3Bまでしかないはず→実際に3Aまで確認）
25：分（48分＝30）
26：時（16時＝10）
※実はこういったものをプロジェクトファイルに記載しているのではないか？と言うのは、VS-2400CD資料のプロジェクトファイルのシステムエクスクルーシブ情報の中で、日付時刻やDayWeekの値を扱っていることを知っていたから。
27:（01-07？）2022/2/1は火曜日で03（日曜日が01） ←ここ！
28：Day（01）
29：Month（02）
2A：西暦
2B：西暦
E6やE7という値を連続しているところに注目し、E6,E7のHEXを10進数に変換すると、2022、2023という数字になっている・・ということからココは年で特定。この前に書かれているのは月、日、時刻に決まっているではないか。
時は24までの数、分、秒のところは最大でも59までだから、該当するHEXがあるかどうかを見渡して特定。
残すは、27番目のHEX。値が01-07までしかないことから、日曜日から土曜日と推測。
日付を割り出した後で、Windowsのカレンダーで曜日を調べたら、ビンゴ。作成日の方の曜日が入っているらしい。
これが、「そんなの分かるかーい」の三つ目ってことでした。
どうでも良い情報ですね。（でも、すっきりしたんです）
何故、Rolandがレコーダのフィールドとして曜日を準備しているのかは謎。
そこはちょっとすっきりしない。
■実際にVS-2400CDで読み込めた！
上記で手動で作成したSONGLIST.VS1で、プロジェクトを読み込めた画面をご披露しよう。
歓喜！
更に、ディスクチェックをかけた画面
注目すべきは、プロジェクトリストがOKとなつているところ。
と
各プロジェクト（最大6つまでしかリストアップされないようだが）のステータスがOKとなっているところ。
LOOSE AREA 6
となっているので、まだ何かしらのおかしなところはある。
ちなみに、修復をかけてみるが、失敗で、何も修復されなかった。
※この修復とは何かを直してくれるのではなく、NGとなっているものを削除するだけ。
これまで、プロジェクトリストがNGで、修復をかけるとSONGLIST.VS1ファイルが消されてしまうことで気がついた次第。
■プロジェクトをロード、再生してみる
・開けないプロジェクトがある
・正常に開けて、再生できるプロジェクトもある
・おかしなトラックが混在する
・再生タイミングがおかしい
・デジタルなノイズが入る
恐らくだが、Loose Areaの6というのは、SONGデータ中におかしな（整合のない）状態が6プロジェクトあるよ！の意味で大体あってるんだろう。
…ということで、一応ロードできるようにはなったが、まだまだおかしいところいっぱいだし、曲としてかんぜんに再生できる状態まで復元できたわけじゃないよ。
というご報告でした。
SONGLISTとSONGを手で正常化して、VSでロードできるようになたよ。
