ファイルフォーマット

いきなりですが、皆さんはファイルフォーマットをご存知ですか。

ファイルフォーマットとは

そもそもファイルフォーマットに対して、ファイルをプログラムで操作する方以外には馴染みがないかもしれません。

ファイルフォーマットとは、直訳するとファイルの保存形式という意味です。例えばファイルとして馴染み深いものとして、メモ帳で書いたものが保存されるテキストファイルがあります。

保存されたファイルの内容は、コンピュータの性質上 0 と 1 の羅列になっており、他の使用者にとっては何が書いてあるか判断できません。そのためファイルフォーマットを定義して、ファイルの中身の情報が統一して書かれるようにしています。

またファイル名の語尾には必ずファイル拡張子.txtが付いています。（ファイル一覧を表示するソフトウェアによっては、拡張子が省略されています。）明確な決まりはないのですが、基本的にはファイル拡張子とファイルフォーマットが一対一対応をしています。

他にも様々な種類のファイルフォーマットがありますので、詳しく知りたい方はファイルフォーマットがまとめられているサイトFILEFORMATや拡張子がまとめられているFileInfo.com等を見ることをお勧めします。

重要性

私はファイルフォーマットがとても重要なものであると考えています。

ファイルフォーマットがどうなっているかによって、ファイルフォーマットを使用するソフトウェアとその関係者にとって、開発の生産性や安全性などが向上したり、多くの方に長い間使用されたりとあらゆる面において多大な影響を及ぼします。

私は音楽の可能性を広げたいと考えており、そのためにはまず私が納得する最強のファイルフォーマットを作ろうと思っています。

この度は、そのようなファイルフォーマットに必要な性質とそのプロトタイプを提案します。

現在のメディアの届けられ方

まずは現状として、動画や画像、音声などのメディアがどのように届けられているかについて説明します。

その前に、動画や音声などにはそれぞれ名称があるのですが、メディアとしてより抽象的に見た時の明確な名称が存在しないため、ここでは以下のように定義しておきます。

名称	具体例
メディア	動画ファイル、音声ファイル
プロジェクトファイル	メディアやプラグインなどに対する処理の組み合わせの情報
生成者（creator）	素材作成者、プラグイン開発者
使用者（user）	視聴者、鑑賞者
編集者（editor）	動画編集者、作曲者
再生ソフトウェア(playing software)	メディアプレーヤー
編集ソフトウェア(editing software)	動画編集ソフト、作曲ソフト

現在の一般的なメディアの届けられ方の流れとしては、

1. 編集者が編集ソフトウェアを使用し、生成者が作成したメディアやプラグインを元にプロジェクトファイルを作成
2. プロジェクトファイルを元に再生ソフトウェアで再生できる出力された状態のメディアを作成
3. そのメディアを使用者に公開し、使用者が再生ソフトウェアでメディアを鑑賞

という風になっています。

現在の問題点

現在の仕組みでは公開されているメディアは、どのような処理が行われているかわかりません。

そのため、他の需要に対応していなかったり、分野の発展の妨げになっていたりします。

副次的な用途での使用

例えば音声ファイルでは、BGM やゲームでの使用などの副次的な用途で使用したい場合があります。

BGM の例

まず BGM の場合は、曲調が使用したい場面である日本らしさに合致しているが、ボーカルが中国語で歌っており、ボーカルの音だけ消したいということが想定されます。現在のメディアで実現するには、パンニングから差分を取ったり、ボーカル除去のソフトウェアを用いたりします。

しかしそれでは、完全に除去できなかったり、元の曲と違うように聞こえたりしてしまいます。

ゲームの例

続いてゲームの例として、Beat Saber という VR のゲーム では、音楽に合わせて出てくる箱を刀で切って遊びます。

Beat Saber では曲を追加したい場合、専用形式のファイルを新たに作成する必要があります。

発展の妨げ

作曲する際には、工程間の移動や二次利用などの際に情報が共有されない問題点があります。

できる操作が少なく、有用的に資源を使用することができず、結果的に分野の発展の妨げになります。

編集者同士の資源共有

現在多くのアーティストは、編集・作曲ソフトウェアを用いて作曲やレコーディング、ミックス、マスタリングなどの様々な工程を経て、曲を完成させています。

工程によって DAW・保有プラグインなどの環境が違うことも珍しくありません。現在では２パターンの方法で互換性を保っています。

wav ファイルの場合も、MIDI ファイルの場合も、情報が失われています。

例えばマスタリングする方が、ある楽器のエフェクトを若干弱めたいと思った場合、本来であればエフェクトのあるパラメータを変更するだけでよいが、エフェクトを抜いた WAV ファイルに別のエフェクトをかけ、元の音に近づかせつつ、若干弱める必要があります。

このように情報が抜けていると、補うための作業を余分に行わなければならなかったり、行いたい操作がそもそもできなかったりする問題があります。

DAW プラグインの例

DAW で使用されている楽器やエフェクトのプラグインの多くは、買い切りという形で提供されています。この場合、作曲初心者にとっては高価で手が出ないことで購入する層が限られたり、新規の顧客に購入してもらう販売戦略を立てることが重要になっていたりして、アップデートが頻繫に行われていません。

その他にも最近ではサブスクリプションで提供されています。この場合、契約を継続してもらうためにアップデートされることが多いものの、契約を解除した際に作曲した過去の作品が使用できなくなるデメリットがあり、あまり浸透していません。

更に全体では、VST、AU、AAX というようなプラグインの種類があり、DAW ごとに対応しているプラグインが違い、互換性を妨げています。

• 処理の中身はブラックボックスになっている。
• ユーザーごとにプラグインを購入しなければならない
• 日本の作曲のプロフェッショナル（JASRAC 登録者）は２万人。購入する人が少ない。

以上のように現在の仕組みではプラグインの発展が見込めず、結果として独創的な曲が生まれません。

プラグインという仕組みを変える必要があります。

これからのメディアフォーマット

以上の問題点を踏まえると公開するメディアが、プロジェクトファイル等を元に出力された状態になっているのではなく、プロジェクトに関する様々な情報が失われていない汎用的なファイルフォーマットであるべきだと考えています。

名称	概要
メディアプロジェクトファイル	プロジェクトに関する様々な情報が失われていない汎用的なファイルフォーマット
全般ソフトウェア (universal software)	再生や編集などの機能が全て揃っており、編集者から使用者までが使用するソフトウェア
特別ソフトウェア (particular software)	ある処理を行う際に、副次的にメディアを使用することに特化したソフトウェア

メディアの届けられ方の流れとしては、

1. 編集者が全般ソフトウェアを使用し、生成者が作成したメディアプロジェクトファイルを元にメディアプロジェクトファイルを作成
2. そのメディアを使用者に公開し、使用者が全般ソフトウェアでメディアを鑑賞したり、編集者になったり、特別ソフトウェアを使用・開発したりする

という風になっています。

そのため再生や編集ソフトウェアの境界がなくなっていくと考えられます。

これからそのようなフォーマットでは、どの情報をどの形式で保持するべきかについて研究します。

性質

まずそのようなフォーマットでは、どのような性質を持つべきかについてまとめてみました。

• 完全性
• 再利用性
  • 拡張性
  • 可読性
• 安全性
  • 部分的機密性
  • 還元性
  • 法律

また必要な性質以外にも、リアルタイムで計算されることが想定されるため、処理速度が上げられるような仕様でなければなりません。

完全性

完全性とは、必要な全ての情報が含まれていることです。汎用的なファイルフォーマットにおいて、完全性が基礎になります。

完全性にも様々な種類があり、それらを多く網羅していることが大事です。あるべき機能として、

• 出力に至るまでのデータや処理に関する情報、つまりプロセスが残っていること
• そのフォーマットに必要な外部の入力などの副作用がないこと
• 変更した部分の過去の情報が残っていること
• プロセスや出力とは関係ない重要な情報も残されていること

再利用性

再利用性は、編集者やソフトウェアが新たに使用する際に重要になります。

具体的には拡張性と可読性という性質があります。

拡張性

拡張性とは、時代とともに出てきた新たに必要な情報を無理なく入れることができるかになります。

拡張性がない場合時代と共に廃れていき、誰も使用しなくなるので再利用性自体がなくなってしまいます。

可読性

可読性とは、ファイルに書かれている内容を読みやすいかになります。

編集者やソフトウェアにとって可読性がなかった場合、再利用することが難しくなります。

安全性

安全性とは、技術的な部分機密性と社会的な還元性や法律の整備があります。

還元性と法律は、直接フォーマットの性能に影響するわけではないのですが、フォーマットが広く使用されるうえでとても重要になっていきます。

部分的機密性

部分的機密性とは、プログラムの一部の情報が隠されている性質のことです。

生成者によっては、その人らしさを醸し出す肝となる処理があり、それを隠したい際に必要です。

しかし完全に機密性を持たせてしまうと、二次的な編集者が、その部分を編集したくても、編集することができなくなってしまいます。そのため全てを機密にするのではなく、一部分のみ隠す必要があります。

還元性

生成者や編集者への還元が大きな肝です。

今まで使用者に向けて出力のみのデータしか公開しなかった理由としては、出力前のデータは生成者や編集者にとっての財産であるからです。それらを公開することのメリットがない限り、それらを無断で使用されてしまうことを危惧して公開はしません。そのため、金銭をはじめとする還元を行うことが、フォーマットを成り立たせるうえで、一番重要なことになります。

法律の整備

著作権などで守られていることも重要であり、法律によって無断で使用されないようにすることも必要です。

提案するフォーマット

それではメディアプロジェクトファイルフォーマットとして、以下の技術をもつプロトタイプを提案します。

プログラミング言語

動画や音声フォーマットによっては、ソフトウェアで事前に決められた大きな処理を記述することはできますが、拡張性がありません。

事前に決められた大きな処理のみしか記述できない場合、ソフトウェアごとに別のフォーマットを定義する必要性があったり、とても仕様が冗長になったりしてしまいます。

そのためプログラミング言語を記述できるようにして拡張性や完全性を高めます。

可逆性

ここで使用するプログラミング言語は処理に可逆性を持たせようと考えています。なぜなら処理速度の向上を見込めるからです。

研究：どのようなプログラミングパラダイムにするべきか？

研究：フーリエ変換などの処理を可逆的に記述できるか？

研究：どの級の言語にするべきか？

テキストとバイナリの融合

完全性として、プログラミング言語などのテキストのみではなく、バイナリも記述できるようにします。

研究：編集に支障は出ないか？

最適化

全てを順に計算することは無駄な処理を行うことになるので、プログラムをあるまとまりごとにコンパイルのような最適化を行います。

これを行うことで、部分的機密性を得ることができます。

研究：どのように最適化を行うか？

メタデータ

プログラムの間に ID や更新日時などのメタデータを記述できるようにします。

研究：どのレベルごとに、メタデータを入れるか？

研究：どこに記述するか？

著作物管理

ID 管理機構という取り組みが解決してくれます。

プラグインで記述したような問題が存在します。そこで ID を楽器やエフェクトなどのプラグインごとにファイルに記録させ、インターネットを通じて使用料を管理する仕組みで解決します。

現在はアーティストのような完成物を作成した者にのみ印税が入っているが、私はプラグインも作品の一部であると考えており、その開発者にも印税をもらうべきです。

• アーティスト

  • 一見アーティストにはメリットがないように思えるが、この仕組みによりプラグインを無料で提供することも可能になり、手軽に新しいプラグインを使用できる。

• リスナー

  • 使用楽器やエフェクト、メロディなどの曲に関する様々な情報を取得できる
  • ある曲を聴いてその音が好きという理由から、ファンがついたり、アーティストとチームを組んだりする可能性もあり

• デベロッパー

  • サンプルや楽器・エフェクトごとのアーティストも輝けるように
  • 仕事も増え、結果的に繫栄する

またプラグイン開発者は、成果に合わせて対価を得るため、実際の意味で人気のあるプラグイン開発者の新規プラグインやアップデートが盛んになります。最終的に有名なアーティストとプラグイン開発者のかかわりが親密になり、コラボ曲というものが出てくることが期待され、新しい音の創造という面で発展することを望見ます。 その他のメリットとして、時代によって必要な付加情報が変わってくるため、ID で管理していると後々必要になった情報を補うことができたり、曲全体での著作権使用料なども管理できたりします。

但しこれは著作物の無断利用を、技術的に保証するものではありません。

そのため今後は、無断利用ができない技術が必要になると考えています。

研究：無断利用を防ぐ技術がないか？

バージョン管理

複数人で作成することも多く、同時に作業している際の正しい同期を行うには、バージョン管理が必要になります。

プログラムに対応した更新日時により管理します。

研究：あるプログラムで、ある人が削除し、ほぼ同じタイミングで少し追加処理を行ったとき、変更前と変更後であまり変わらないのに、重複して大きなデータが残ってしまうがそれでよいのか？変更内容自体を操作するものが必要？

研究：初めてファイルを読み込んだ時、変更時間を全て把握するのは、オーバーヘッドにならないか？

研究：他のバージョン管理の技術がないか？

誤り検出訂正

誤り検出訂正 では、情報が正しく保っていることを、保証してくれます。

プロトタイプでは、誤り検出することができる **巡回冗長検査（CRC）**を用います。

ビットのランダム誤りやバースト誤りを検出できるため、大きなデータを保存したり送信したりするファイルフォーマットにも向いています。

例えば CRC-32K/4.2 では、ハミング距離 4 は 2147483615 ビット（268 メガバイト、268,435,451.875 バイト）まで、ハミング距離 6 は 6167 バイト（770.875 バイト）まで担保されています。

研究：どの範囲でどの CRC を用いるか？ 研究：改ざん性の観点から暗号学的ハッシュ関数などの別のものを用いた方がよいのか？ 研究：情報を変更するたびに再計算する必要があり、オーバーヘッドになるため、フォーマットのレベルで情報の正しさを保証する必要があるのか？