前 9‒21 p ｜ 
もくじ i ｜ 次 9‒23 n 
3行でまとめると…
字幕を作らない・使わない人には関係ない。現在進行中のことで（2019年10月に話題になり対応されつつある事柄）、記事としてまとめられる段階ではないため、前半では、速報メモをそのままアーカイブ。後半では技術的な事柄について簡単にメモ。
問題に気づいたのは2019年9月末。仲間内で検討したり Matroska の開発者に質問したりして、10月初めに暫定的な「推奨」が決まった。「正解」のない難しいジレンマ。
要約: TTFフォントを添付する場合、メディア型（いわゆるMIME）が font/ になるケースがある。これは2017年に定義されたウェブ標準のメディア型だが、多くのプレーヤーはまだこの型を認識できず、添付フォントがロードされないという不具合（字幕スタイルが壊れる）が生じる。
推奨: 当面、フォントを添付する場合、レガシーのメディア型を明示的に指定。コマンドラインの場合、TTF なら --attachment-mime-type application/x-truetype-font、OTF なら --attachment-mime-type application/vnd.ms-opentype （※注）。GUI の場合、mux前に、そうなっていることを確認する。
（※注） OTF の場合、TTF と同じメディア型 application/x-truetype-font でもロードされるらしい。
補足: (1) 非公式の新しい MPC-HC (clsid2 builds) なら、一定条件下で新しいメディア型の添付フォントもロードされるが、公式の MPC-HC や MPC-BE や古い LAV に依存するプレーヤーでは、現在、字幕が壊れる。次のバージョンから新しいメディア型がサポートされる見通し。
(2) MKVToolNix は、現在、TTF に関してはデフォルトで application/x-truetype-font を使うように設計されていて、本来、明示的に指定する必要はないのだが、一部の環境では、2018年ごろから、意図通りにならないことがある。過渡期の混乱が生じているため、フォントを添付した場合、念のため、システムからそのフォントをアンインストールした状態で添付フォントがロードされるかテストした方がいい。万全を期すなら、フォントがキャッシュされている可能性を考慮し、再起動後にテスト。
(3) 添付ファイルの MIME は、MPC系なら [Shift]+[F10] の Resources タブでも確認できる。
(4) フォントのメディア型の標準化とその背景については、RFC 8081 参照。「どちらでも同じ」なら標準化された新しい型を使うべきだが、現在、プレーヤー側のサポートが追いついていないので、当面は古い MIME を使い続けるのが現実的。自分たちだけでなく Matroska の開発者も同意見。
MPC-BE＝対応完了（世界初！）: 1.5.4.4799 において、font/ttf と font/otf と font/sfnt がサポートされた。コード更新は 2019-10-07、バイナリー公開は 2019-10-08。残りの2タイプについてサポート追加をリクエスト（2019-10-09）。同日1.5.4.4808 において、font/collection と application/font-sfnt も認識されるようになった。2019-10-10T08:30Z 現在バイナリー待ち。公開されたら動作確認する。〔追記: 同日午後バイナリー公開、テスト結果＝OK〕
LAV Filters＝TTC以外対応完了: 0.74.1-26 において、font/ttf と font/otf と font/sfnt と application/font-sfnt が認識されるようになった（font/collection は認識されない）。コード更新 2019-10-07、バイナリー公開 2019-10-09。font/collection のサポート追加についてはリクエスト済み。〔追記: 2019-10-14 TTCにも対応。2019-10-15 v0.74.1-28 バイナリー公開、テスト結果＝OK〕
MPC-HC（clsid2 build）: 新しい LAV Filters を取り込めば、自動的に同じ更新が反映される。現時点での最新版バイナリー（1.8.8.234）は、上記の LAV の更新より前にビルドされていて、font/ttf などを明示的にサポートしていない。「MPC-HC（非公式）では既に font/ttf などが認識される」と速報に記したが、拡張子が小文字の .ttf などである必要があり、それが .TTF に変わるだけで認識されなくなる…という危ういもの。順当にいけば、次の 1.8.9 では全部ちゃんと認識されるようになる。
アクティブに開発が続いているプレーヤーなら、1～2カ月以内に、新標準に対応可能になるだろう。良いことだが、そうなると、今度は作成ツール側で「フォントを添付するとき、新標準の font/ メディア型を使おうかな…」となるのは必然。この変更を急ぎ過ぎると「新規作成した MKV が古いプレーヤーでは意図通りに再生されない」という混乱を招く。状況の背景・詳細については後日あらためて解説するが、今回の協調更新の趣旨は「新仕様のファイルが来ても再生できるように、先回りして準備」。「旧仕様の添付フォントのサポートをやめる」ということではない。「動画作成側がコマンドラインから明示的に新仕様を使う」または「作成ツールの添付フォント処理のデフォルトが変わる」のどちらかが起きない限り、当面、エンドユーザーには何の影響も生じない。
何らかの理由で古いプレーヤーを使い続けた場合、今から数年以内に「それまでは問題なかった字幕のフォントスタイルが正しく表示されないケース」が起こり得る。特殊な文字だと、最悪、表示が□や？や空白になってしまうかもしれない。そうした問題が起きたときには、あわてず、内部の Matroskaスプリッターをオフにして、外部の LAV を試してみよう。そうすれば、元祖 Gabest バージョンの MPC（約10年前）でさえ、新仕様の添付フォントを利用できる！
「壊れてないのに直すな！」という格言がある。フォント埋め込みMKVは、2004年に実験的に実装され、次第にサポートが充実、今ではクロスプラットフォーム（再生側のOSに依存しない形）での相互運用が当たり前。それがなぜ突然「仕様変更」なのか。古いプレーヤーが新しいMKVに対応できなくなり、未来のプレーヤーが古いMKVに対応できなくなるかもしれないのに…。
問題が生じた背景は、次の通り。
text/css とか image/png といった識別子を見たことある方は多いだろう。MIME Type は、文脈によっては Media Type とも呼ばれる（以下「メディア型」）。application/octet-stream などで一応間に合っていた。@font-face が標準化され、状況は急変。ブラウザにバックグランドでフォントをダウンロードさせ、特定フォントを使ってウェブページを表示させることが一般化した。ダウンロードさせるフォーマットも ttf/eot/woff などバラバラ。ブラウザから見ると「漠然と application/octet-stream と言われ、ダウンロードしてみたら未対応の形式だった」となれば時間の無駄だし、ページの表示も遅れ、帯域も浪費され、エンドユーザーから見ても迷惑。従って、フォーマットごとにフォントのメディア型を標準化する必要が生じ、多少の混乱もあったが、2017年には font/ttf や font/woff などの新しい型が公式に定義された。「公式な型がなかったのなら、今までMKVの添付フォントはどうなってたの。どうやって再生互換性が維持されてたの？」という疑問が生じるでしょうが、メディア型の仕様には「x- で始まるサブタイプは、プライベートで自由に使えるよ」という規定があって、
application/x-truetype-font
というプライベート型が、MKV に TTF を埋め込むときの事実標準となっていた（初期の実装において Haali/Gabest が採用した型）。でも Matroska は、誰でも自由に使えるオープンなフォーマット。仕様書で「ファイルのMIME型を指定する」と明記されている。新たにMKVを作るとき「今の公式な型は font/ttf だから、それを使おう」と考える人が出てきても、それを止められない。
結果として、もしプレーヤーが新旧両方のメディア型に対応していないと、未対応型フォントの字幕がデザイン通りに表示されず、困ったことになる。「フォントが違うだけで文字は読める」のなら実用上OKかもしれないが、場合によっては、字幕をオンにしても文字が表示されない。バグ報告・問い合わせが殺到し、多くの人の時間とエネルギーが浪費され、最悪、作成済みのMKVを全部作り直す羽目になる！ 大混乱が生じる前に、先手を打って対応しておきたい。
2種類のテスト用ファイルが doom9 の MKVToolNix スレの 2019-10-07/08 にあるので（※1）、MPC系/LAV利用/mpv以外で未対応のプレーヤーを発見したら（ZoomPlayerなどはLAV利用）、そのプレーヤーの開発者に対して、サポート追加を丁重にお願いしてほしい。新形式ファイルの登場による問題で、プレーヤー内部の不具合ではないので、バグ報告ではなく、新形式対応のリクエストという形で。「新形式といっても FileMimeType の文字列が違うだけで中身は同じ」という点を伝えてください。疑問点・問題点・コメントがあれば、上記スレや各プレーヤーのスレに書くと吉。動画作成者は、当面（少なくともプレーヤー側の対応が整うまで）古いメディア型を使い続けるのが無難（速報の「推奨」参照）。趣味で字幕やカラオケを作ってる友達がいたら、このことを教えてあげてください。
※1 テスト内容は、画面上部の文字（ハードサブ）と同じフォントで下の文字（ソフトサブ）を表示できるか。一つ目のサンプルの Test1～4 に合格すれば、そのプレーヤーは実用上ほぼOK。二つ目のサンプルの Test5 に合格すれば TTC 対応もOK。Test8 は「メディア型を本当にサポートしているか、拡張子に基づくその場しのぎのサポートか」を判別するもの。Test6/7 はWOFFサポートを試すものだが、WOFF埋め込みMKVは現在実際には使われていないので、6/7 の結果はどうでもいい（これに通るプレーヤーがあれば神）。
MPC-BE, LAV とも新標準対応のバイナリー（テスト版）が出そろった。内部的に LAV を使う MPC-HC の更新も時間の問題。どのバージョン以降で対応したかは「第2報」参照。MPC-HC (clsid2) の次の正式版リリースは2019年12月以降か（10月3日に 1.8.8 が出たばかりなので。MPC-HC は開発が止まっていて、clsid も積極的な機能追加などはしていない）。
2019-10-16 現在のリリース版において、問題が条件付きで回避されるのは、LAVFilters のうち、2019-03-16 の v0.74 以降（※）。リリースノートに Fixed: Fonts embedded in MKVs without a proper mimetype were not being imported
とある（※※）。MPC-HC では、2019-03-17 の v1.8.5 以降に当たる。
（※） ソース変更は 2019-03-15。報告 #261 への対応だった。報告者が提供したサンプルで使われているのは新メディア型ではないが、問題の本質は同じ。レガシーの事実標準と異なる application/octet-stream が使われていて、それにプレーヤーが対応できなかった。
（※※） 何が proper mimetype
なのか明確でないことが、問題の核心。
この回避は、拡張子チェックによるものだが、大文字・小文字を区別してしまったため「.ttf なら良くても .TTF では駄目」といった制約あり。さらに .ttc にも対応できない。メディア型の本当のサポートは、2019-10-15 の v0.74.1-28 以降（「第2報」参照）。MPC-HC に関しては対応待ち。
2019-10-18 MPC-BE 1.5.4 (build 4850) beta が正式公開された。MKVの字幕の「新仕様」に対応した。「新仕様」はRFCレベルではメディア型の新しい国際標準だが、旧仕様も依然有効。MKV においては、現時点ではむしろ旧仕様が推奨される。新仕様への移行のタイミングの目安として、MKVToolNix の作者は「2020年末くらいか、もう少し後」とコメントしている。「あと1年半くらいは旧仕様で。その後も互換性重視のユーザーは旧仕様を使い続けてもいい」という感じ。
font の登録（2017）年より14年も前のこと。従って、FileMimeType の価が font/* ではない無数のMKVファイルが存在する。FileMimeType 値を認識しなければならない。sfnt（スケーラブル・フォント）の TTF & OTF および TTC が使われる。従って、次の5タイプが認識されるべきである: font/sfnt (#1), font/ttf (#2), font/otf (#3), font/collection (#4), application/font-sfnt (#5).application/octet-stream (#6) も使われることがある。2013年に #5 が登録される前において、これは合理的な選択肢だった。application/x-truetype-font (#7) はレガシー型の事実標準であり、Matroska において広く使われた（今も使われる）。典型的には #2 に当たるが、時には #1 #3 #4 と同等。このプライベート型は、2004年に Windows 上の最初の2種類の実装において使われ、数年後 ffmepg によってもサポートされた。application/vnd.ms-opentype (#8) は、OTFフォントについて広く使われた（今も使われる）。#3 と同等。application/x-font-ttf (#9) と application/x-font (#10) があり、幾つかの実装系においてサポートされている。FileMimeType は FileName より信頼性が高い。後者は任意の値（例: font.xtf）を持ち得る。実際には、FileName の拡張子をチェックすることは時として有益である。FileMimeType が認識できない場合には、特に。大文字小文字を区別しない拡張子 .ttf / .otf / .ttc は、それぞれ #2 / #3 / #4 を強く示唆する。font/woff（エイリアス application/font-woff）、font/woff2、application/vnd.ms-fontobject などが考えられる。@font-face が標準化され、フォントの Mime型は日常的に使われる重要なものとなった。2017年にトップレベルの型 font が正式に登録され、#5 は #1 のエイリアスとなった（非推奨だが依然有効）。ツールチェーンの中には、意図的かどうかはともかく、これらの標準化された新しい型を使うものが徐々に現れ始めた。しかし2011年の修正のため、少なくとも Windows 上の MKVToolNix GUI は明示的に #7 を使い続け、新しい標準ができたことによる互換性問題をマスクし続けた。[1] ASS では、インラインSVGのようにして、\p を使ってグリフ（特定のフォントの文字）を描画できるが、この低水準アプローチは、一般論として実用的なものではなかった。
2021年6月13日にリリースされた MKVToolnix v58.0.0 の GUI では、フォント・アタッチメントのMIME型の自動認識が変更された。背景については「MKV埋め込み字幕用フォントのMIME問題」を参照。
注意点:
1. 今回の変更によって、古めのプレーヤーはフォントを正しくロードできなくなり、字幕表示が乱れる。おおむね2019年10月以前のバージョンが影響を受ける（MPC-BE 1.5.4以前、MPC-HC 1.8.8以前、LAV Filters 0.74.1以前）。不特定多数の人（古めのプレーヤーを使っているかもしれない）にファイルを公開する場合、要注意。
2. 技術的問題。標準準拠のための変更なのに、MKVToolnix v58 がデフォで使う MIME-type は標準準拠になっていない。#3137 として開発者にフィードバック済み。
暫定的推奨:
状況がクリアになるまで v58以降への更新をせず、しばらく様子見が吉。
MKVToolnix v58 の GUI を使うと、非標準なファイルが作成され、禍根を残す可能性がある。どうしても58 の GUI を使いたい人は、Preferences | GUI | General Options のUse legacy MIME types for font attachments にチェックを入れると、後方互換になる。状況を把握できていて、自分でコントロールできるなら、更新しても問題ない。
MIMEタイプが標準準拠になること自体は、原則的には良いこと。けれど MKVToolNix 58 は、標準準拠にしたつもりで中途半端になってしまっている。これを開発者が「magicライブラリの仕様」と主張するのか、それとも、標準仕様とずれていることを認めて修正するのか…。
追記: 開発者もこれが不具合であることを認めた。修正されるまで、バージョン57以前を使い続けることをお勧めする。
短期的には、標準準拠に実用上のメリットは何もなく、リスクだけがある（互換性が失われて一部のプレーヤーで字幕が正しく表示されない）。かなりの人々が、当面、明示的にレガシー（後方互換）を使い続けるのではないか。コマンドラインから使えば、MIMEタイプは好きに設定できるし、GUIからでも上述の「レガシーモード」のオプションがある。けれど手動設定が必要。一般ユーザーがデフォのまま操作すると、変なファイルが作成されてしまう可能性がある。一般ユーザー視点では、v57 以前を使い続けるのが、手っ取り早い。
libmagic がフォントのMIME型をおかしくするのは、MKVToolnix史上、少なくとも3度目。最初はまだ font/ が公式に定義されていない時期。独自に font/ を使い、互換性問題が生じた。2回目は2019年ごろ。Mac上で MKV を作ったら、application/font-sfnt というマニアックな型（技術的には間違いではない）を書き込まれ、再び互換性問題。この時点で libmagic に疑いが生じたが、MKVToolnix の作者は「このライブラリは事実標準」と擁護。そして今回（2021年）。主要プレーヤーが標準準拠して1年半たったから、準備そろそろOK？とレガシー対応を廃止したとたん、また libmagic が TTF を font/sfnt という変な型にしつつ（技術的には間違いではない）、OTF をレガシーにするというちぐはぐな挙動。さらに TTC が font/ttf というのは、訳が分からない。
libmagic の返すフォント型がミッション・クリティカルになる場面がほとんどないので、報告されず、放置されているのだろう。字幕制作者は過去のいきさつに懲りて、--attachment-mime-type を明示的に書くようになっているため、MKV でも問題が表面化しにくい。
MKVToolnix の作者もとうとう「これはおかしい」と考え、libｍagic 自体を使わないように変更した。実用上、とりあえず賢明な選択かもしれない。けれど、変更の思わぬ副作用として、フォントとは別の添付ファイル（カバーアートなど）で、分かりにくい互換性問題が生じてくる可能性がある。しばらく添付ファイルのMIME型をよく確認した方がいい。
さいわい主要な動画プレーヤーは、font/sfnt のようなレアな型にも対応しているし、「MIMEを認識できない場合は拡張子をチェックする」という安全策を施した実装もある。自動更新で何も考えずに MKVToolnix 58 にしてしまっても、再生サイドの実害は限定的だろう。
ただ MPC-HC の最後の公式バージョン（clsid2 が引き継ぐ前）を使い続けているユーザーは、内蔵フィルター使用の場合、今後、埋め込みフォントがロードされないケースが増えてくるかもしれない。
バージョン58では、デフォのMIMEを標準準拠に変更しようとしたものの、結果がおかしかった。最新のバージョン59ではライブラリを一新、標準準拠の対応は改善されたが、今度は、後方互換モードに不具合が生じた模様。具体的に、レガシーの挙動を指示しても、TTCのMIME型がレガシーにならない。
どちらのモードでも、状況によって、一部プレーヤーで字幕の表示がおかしくなる。
コマンドラインからなら型を明示的に指定できるものの、GUIユーザーは、引き続きバージョンアップを控え、バージョン56.1以前を使うのが無難。
当然いつかは標準準拠に移行するべきだが、現時点では、移行しても実際上のメリットがほとんどなく、確実にデメリットがある。「公式」の古いMPC-HCが標準MIMEに対応していない（よってテキスト表示が乱れる）。「非公式」のclsid2版なら大丈夫だが、MPC-BEが sourceforge にあることなどから、意外とMPC-HCもそっちからダウンロードしてしまう人が多いのでは…。
![メールアドレス（画像）: [ http://www.faireal.net/image/2005/addr.png ]](/image/2005/addr.png "メールアドレス <PNG画像>"){kind=small}