FLAC メタデータ検査ツール
FLAC ファイルは 4 バイトの目印のあとにメタデータブロックの連なりが続き、その後ろに音声フレームが並ぶ構造です。各ブロックのヘッダーは 4 バイトで、最終ブロックのフラグ、種別、24 ビットの長さを持ちます。このページはその連なりをそのままたどり、どのブロックがどの順に、どの位置に何バイトあるか、どれが最終と印されているか、そして音声がどこから始まるかを表示します。STREAMINFO からサンプルレート、チャンネル数、ビット深度、総サンプル数を読むので、再生時間はビットレートからの推定ではなく正確な値です。メタデータ以降のバイト数を、その値が示す無圧縮 PCM のサイズと比べれば、このファイルの本当の圧縮率が分かります。総サンプル数が 0 でも規格上は正常で、エンコーダーがストリーミング中で長さを知らなかったことを意味します。VORBIS_COMMENT は多くのタグ読み取りが誤る部分です。同じ名前が何度でも現れうる多重マップなので ARTIST が 3 回あってもよく、素朴な辞書に読み込むプログラムは 1 つだけ残して残りを黙って捨てます。ここではすべての行をファイル順に並べ、重複する名前に印を付けます。PICTURE ブロックが宣言する幅・高さ・色深度・色数は誰も検査しないため、埋め込み画像をブラウザーで実際にデコードし、宣言値の隣に実測値を並べます。SEEKTABLE はポイント数とプレースホルダーの数、その範囲を、CUESHEET はカタログ番号とリードイン、トラックを、APPLICATION は登録 ID を、PADDING は無駄になっているバイト数を要約します。先頭に付いた ID3v2 タグは規格外ですがよくあり、fLaC の目印をオフセット 0 から押しのけます。本ツールはそれを壊れたファイルとせず、検出して報告します。分からないのは音声がデコードできるかどうかです。STREAMINFO の MD5 はデコード後の PCM のものなので可逆な往復は証明できますが、ディスク上のバイトは保証せず、確かめるにはストリーム全体のデコードが必要です。
使い方
- .flac ファイルを枠にドロップします。読むのはファイルの先頭だけなので、長いアルバム収録曲でも短い曲と同じ速さで開きます。
- まずストリームのタイルを見ます。サンプルレート・ビット深度・チャンネルは STREAMINFO の値で、総サンプル数が保存されているため再生時間は正確です。
- 圧縮率を隣の無圧縮 PCM サイズと見比べます。それがこのファイルで実際に減った量で、率が悪い場合はエンコーダーよりマスタリングの性格を表しています。
- ブロック表でファイルの構造を確認します。どのブロックがあり、どこから始まり、どれが最終で、音声フレームがどの位置から始まるかが分かります。
- コメント一覧では重複の印が付いたフィールドに注目します。値が複数あるフィールドで、タグ編集ソフトが最もよく 1 つにまとめてしまう項目です。
よくある質問
- 同じタグが 2 回表示されます。不具合ですか。
- いいえ。複数の値を持たせる正しいやり方です。Vorbis コメントブロックは辞書ではなく NAME=value の行の並びなので、共作なら ARTIST が 3 回、ジャンルをまたぐ作品なら GENRE が 2 回あっても構いません。フィールド名は大文字小文字を区別せず artist と ARTIST は同じ項目で、行の順序はエンコーダーが書いた順そのままです。このブロックを普通のマップに読み込む実装は名前ごとに 1 つしか残さず、残りを何も言わずに捨てます。3 人のアーティストを書いたトラックが、あるタグ編集ソフトを 1 往復しただけで 1 人になるのはこのためです。ここではすべての行をファイル順に示し、2 回以上現れる名前に印を付けます。
- STREAMINFO の MD5 は何で、ファイルが無傷である証明になりますか。
- それはファイルではなく、デコード後の音声、つまりデコーダーから出たままの符号付きリトルエンディアンのインターリーブされたサンプルの MD5 です。だからこそ役に立ちます。同じ音声を別の圧縮レベルで符号化し直すとファイルのバイトはすべて変わりますが、この MD5 は変わりません。変換が可逆だったことをそれで示せます。逆に、ファイルを眺めるだけでは確認できないという意味でもあります。ストリーム全体をデコードして結果をハッシュする必要があり、flac -t がまさにその作業です。この欄を 0 が 16 個のまま残すエンコーダーもあり、それは検証失敗ではなく署名を保存しなかったという意味です。
- 再生時間が不明で総サンプル数が 0 です。壊れているのですか。
- 壊れているのではなくストリームです。STREAMINFO のサンプル数は入力の長さが分かってから最後に書かれるため、パイプや生放送に書き出すエンコーダーは戻って埋められず 0 のままにします。規格が明示的に許している値です。再生側はフレームが尽きるまでデコードして対応し、再生しながら時間が伸びていくように見えるものもあります。サンプルレート・チャンネル・ビット深度・MD5 など他の値は有効で、再生も普通にできます。デコードして実ファイルに再エンコードすれば、その数値が書き込まれます。
- FLAC なのに先頭が ID3 タグなのはなぜですか。
- 主に MP3 を扱う道具が書いたからです。FLAC のタグは VORBIS_COMMENT ブロックにあり規格に ID3 の居場所はありませんが、ID3v2 はファイル先頭に置く設計なので、一部のリッパーや再生ソフト、スマートフォンのアプリがそのまま付けます。多くのデコーダーは読み飛ばしますが、fLaC がオフセット 0 にないという理由でファイルごと拒否するものもあります。このページはタグを検出して何バイト占めるかを示し、目印が実際に始まる位置から本来のメタデータを読みます。なお、その ID3 に書かれた内容は FLAC 対応ソフトからは見えないため、同じファイルがここと別の場所で違うタイトルに見えることがあります。
- FLAC の圧縮率はどのくらいが普通ですか。
- 多くの音楽は無圧縮 PCM のおよそ 50〜70% に収まります。ここに出る値もまさにその定義で、最後のメタデータブロック以降のバイト数を、総サンプル数 × チャンネル × ビット深度 ÷ 8 で割ったものです。静かで疎な素材はずっとよく縮み、大音量で強く抑え込んだマスターはあまり縮まず、雑音に近い音はほとんど縮みません。エンコーダーの設定（-0〜-8）は符号化にかかる時間とサイズを数パーセント動かすだけで、音は変わりません。どの水準も可逆だからです。24 ビットのマスターが 16 ビットより率が悪くなるのも普通で、下位ビットが乱数に近く予測できるものがないからです。
- ファイルはアップロードされますか。音声を検証できますか。
- どちらもいいえです。ファイルはブラウザーの File API で開かれページ内で解析されます。メタデータは先頭にあるので読むのは前半だけで、その後ろのフレームは大きさを測るだけです。どこにも送信されませんし、送る先のサーバーもありません。後半の答えも同じくらい重要です。ここにある値は音声そのものの保証ではありません。ブロック長やタグ、画像はメタデータから読み、フレームはデコードせず、保存された MD5 も書き写すだけで検証はしません。したがってメタデータが完璧で音声が壊れたファイルも、このページでは健全に見えます。それを見つけるのはデコードです。
関連ツール
WAV ファイル インスペクター
.wav をドロップ → フォーマット・チャンネル・サンプルレート・ビット深度・再生時間・全 RIFF チャンク・埋め込み LIST/INFO タグを表示。完全クライアントサイド。
Ogg コンテナインスペクター
.ogg / .oga / .opus をページ単位で解析します。グラニュール位置、セグメントテーブル、CRC32 の照合、そしてコンテナが運ぶ論理ストリームを表示します。
MP3 タグ（ID3）ビューア・ジャケット抽出
MP3 をドロップすると ID3 タグ、ビットレート、再生時間を読み取り、埋め込まれたジャケット画像も取り出せます。すべてブラウザ内で。
PNG チャンクインスペクター
`.png` ファイルをドロップして、含まれるすべてのチャンクを見る — IHDR、IDAT、tEXt メタデータ、IEND — サイズ、CRC、critical / ancillary / safe-to-copy フラグ付き。
フォントファイル検査ツール
.ttf、.otf、.woff を開いて、本当のファミリー名、グリフ数と対応文字数、バージョン、ライセンス文、埋め込み許諾を読み取ります。
画像 → WebP / JPEG / PNG 変換
PNG/JPG ↔ WebP 変換、品質スライダー可 — ブラウザ canvas で実行。