先日ダウンロードしたVSWave Export Softwareは、VSのプロジェクトをWavに書き出しできる神ツールであるが、当然このツールの作者は、プロジェクトファイルの構成やトラックデータ（TK**.VS1ファイル）の構造もハックしてわかっている。
・・で、VSWave Export SoftwareのREADMEを読んでいたら、VSがどのようにトラックを保存しているかについてのヒントがあった。（…と同時に、これを読んで、TKファイルをかき集めて復元するという熱意が失せた）
→ファイル名規則とEVENTLISTのフォーマットで整合を確保でき、熱意が復活した。w
■VSWave Export SoftwareのREADMEの記述
But before doing this you must understand how multitrack recordings are saved by the VS:
If you record 8 Tracks at the time, the VS will place the audio data of this 8 Tracks in consecutive single clusters. This means that cluster 1 will hold one second of audio data for track 1, cluster 2 will hold one second for Track 2, …, cluster 8 holds one second of Track 8. After that the next recorded second follows: cluster 9 holds the 2nd second of Track 1, a.s.o.
Therefore if we just play clusters 1,2,3 we would mixup Tracks. Instead we must play cluster 1,9,17,25,33, aso to hear Track 1.
You can do this by setting the ‘offset’ to the number of tracks you recorded at once: 2 for 2 tracks, 8 for 8 tracks, 16 for 16.
↓ Google翻訳
ただし、これを行う前に、マルチトラック録音が VS によってどのように保存されるかを理解する必要があります。
一度に 8 トラックを録音すると、VS はこの 8 トラックのオーディオ データを連続する単一クラスタに配置します。 これは、クラスター 1 がトラック 1 のオーディオ データを 1 秒保持し、クラスター 2 がトラック 2 を 1 秒保持し、…、クラスター 8 がトラック 8 の 1 秒を保持することを意味します。 トラック 1 の 2 番目、a.s.o.
したがって、クラスター 1、2、3 だけを再生すると、トラックが混同されます。 代わりに、トラック 1 を聞くには、クラスター 1、9、17、25、33 を再生する必要があります。
一度に録音したトラックの数に「オフセット」を設定することでこれを行うことができます: 2 トラックの場合は 2、8 トラックの場合は 8、16 の場合は 16。
■「想像してたん違うぅ」
クラスタというのは、音の素片を（1トラックの1秒の録音データ）意味していて、VSは一度の録音ですべてのトラックのデータを1秒ずつスライスして、シリアルで一つのデータの中に入れている・・という意味。
てっきり、（VSのタイムラインで表示されるような）トラック別で長尺のwaveファイルのようなものが保存されていると思っていた。
なので、TK**.VS1のファイル名の中に、トラックを表すような記号が入っていると思っていたし、各トラックの帯に1体1で対応するTK**.VS1が一つ独立で存在すると思っていた。
つまり8トラック分を同時に録音すれば、8つのTK++.VS1データがあり、それぞれのファイルサイズは同じはずだ・・と思っていたがそうではないらしい。
どこか別のフォルダにはぐれてしまったTK**.VS1データを適切なフォルダに配置さえしてやれれば、ヴァイオレンスなリミックス状態を解消できると思っていたが、萎えてしまった。
■TK**.VS1ファイルのファイル名
ファイル名の命名規則を調べようとしている図（そして分からなかった）
ファイル名は、3つのパートから分かれていると推測
始めのバイトには00-05まで入っていた。
※始めの2バイトがトラック番号ではないか？と思っていた。
（バーチャルトラックも併せて各トラック20*16）
しかし、この仮説の場合、自分が良く使っているトラックが見覚えのある数字となって現れるはずで、ドラムトラックは常に7,8なので、数字で6,7が付くものがドラムのはずだった。（妄想の中では）
打ち込みトラックは1,2で固定なので、0.1が打ち込みデータとなっているはずだった、
2つ目と3つ目は、恐らく00-FFまで65536個の数字を割り当てられる。
恐らく、一つのパーティションなりディレクトリ内に65536個までの音声データを保存できるのではないだろうか？
…と思ったのが、すべて打ち砕かれた。
ファイルリストからトラックや内容を割り出せなかったし、ファイル番号も連番ではない。
VSのトラックがVTも含めると、256では足りないので、トラック番号はHEX3桁じゃないかと思い、ファイル名の3桁を眺めると、連番になっているのに気が付いた。
そうすると、トラックは16の3乗で4096、音素片も4096まで持てる？
復元できたプロジェクトのTK**.VS1のファイル名を眺めると、上3バイトは000-054まで連番で存在し、下3バイトも000-FFEまできれいに並んでいることが分かった。
もしかして、散逸したTK**.VS1も、この規則に従って（ファイル日付を見ながら）フォルダに放り込んでやればOKかもしれん。
バイト数の見方を変えたら、一気に期待できる推測が成り立ってうれしい。
これが分かれば、曲データの再生に弾みがつくのだが。
■EVENTLIST.VS1がTRK**.VS1と対応
ようやく見つけた。
TRK**.VS1が、トラックに録音された音自体だということは分かっていたが、その法則や、トラックに貼り付けられた順番とか時間をどうやって管理しているのかを探していた。
答えは、EVENTLIST.VS1にあった。
ETHNIC0のSONG000は、エンヤのオリノコフローという曲のデータ。
始めにこのファイルの中に”03FF74”とか書かれた部分があるかを検索し、存在することを確認したのち、その近くに”V.T1-1”と書かれていることを見つけたらビンゴ！
次に全体を見やすくするために、64バイトで1行になるように表示したら、
トラック情報が整然と並んだ。
V.T**の記載があるところを見てみる。
VT1-1
VT2-2
VT4-1
VT3-1
のように出てきて、「これは1,2のMIDIオケパートと4トラックに入れたベース」と即座に分かった。後ろのように出てくるVT3というのは、恐らく最後に録音したヴォコーダーパートだ。
64バイト1行表示にして、33,34,35の値を見ると、TRK***.VS1ファイルと整合する。
これで「EVENTLISTで指定はされているものの、実体ファイル（TRK***）が存在しないもの」を特定できる。EVENTLISTと実ファイルの整合を見ていけば、クロストークやノイズなんかの原因が分かるかもしれない。
EVENTLIST内に指定があるのにファイルが無ければクロストークやノイズ？
EVENTLIST内に指定がないのにファイルが存在していればLOOSE AREA？
かな。
結論：
EVENTLIST,VS1に、使用する音素材（TRK***.VS1）が記載されている。
※他のバイトも何が記載されているのか？が徐々に分かってくることに期待ができる。
