日記みたいな何か

2025年7月26日の日記を表示中

■ドリキャス

ドリキャスのGD-ROMの高密度領域に複数トラックが記録されているタイプのダンプで、最後のデータトラックの直前の2秒の空白部分の最初の2セクタをうまく読み出せない問題に関して、開始セクタによって中身が変わることをツイートしたら、ランダムっぽいデータになっているのはスクランブルが解けていないからではないかとのご指摘を頂きました。

あまり詳しくないですが

音楽～データ部分のGAP、「音楽1秒 + データ2秒」のように形式が混在している事が吸い出しの問題となっているのだと思います。

GAPデータ普通は空っぽだと思うので、上の形式(内容部分は"00"埋め)で自作しても大丈夫なはず。
— (-_+) (@_nega_posi_) July 25, 2025

吸い出す場合は

>最初の方のセクタがエラー
データモード?で読んだ為、音楽部分がエラー?
・音楽、データ部分を別々に吸い出す

>もう少し手前から読み～ジャンクデータ
音楽モード?で読んだ為、データ部分がスクランブル状態
・データ部分を切り出し、ツールでスクランブル解除

とかで
— (-_+) (@_nega_posi_) July 25, 2025

スクランブル解除https://t.co/Ud7i0lGDIw
MyStupidPrograms > unScramble.exe

昔PCエンジンを手動で吸い出してた時なんかに使ってました。
他にもツールあるのかな、今どうなってんだろう。
— (-_+) (@_nega_posi_) July 25, 2025

うおお、CD-ROMのデータトラックって、元々スクランブルがかかっているのか！調べてみたら、ECMA-130なんていうので定義されていたりするんですね。これは知らなかった。

早速ダンプ済みのスターグラディエイター2のデータに対して、教えていただいたツールを適用してみたところ、ランダムっぽかった中身が綺麗なデータに！

調べてみると、最初の 12Byte (00 FF FF FF FF FF FF FF FF FF FF 00) の部分が同期部分で、その後の3Byte (A3 01 40) がそのセクタのアドレスを時刻 (分、秒、フレーム) の模様。数字はBCD形式とのことですが、分の部分が 0xA3と、BCDじゃない数値になっちゃっています。これは多分、GD-ROMだとCD-ROMと違って99分を超えちゃうので仕方なく拡張したものと推測ｗ。なので、0xA3は103分かな。計算してみると、103 * 60 * 75 + 1 * 75 + 40 = 463,615 となり、まさに最後のデータトラックの2秒手前の最初のセクタ番号と一致しますね。

次のセクタ 463,616も正しくスクランブル解除できているようだったので、これらをダンプ済みのデータと合成してみたところ、ついに最後のデータトラックのSHA1が redump.orgのデータベースと一致するようになりました。やった！ありがとうございます！いやしかし、ほんと解決するとは思いませんでしたｗ。SNS凄すぎるｗ