FLAC 檔案格式
Free Lossless Audio Codec，一種無損壓縮的音訊格式。
- MIME 類型
- audio/flac
- 副檔名
- .flac
- 分類
- 音訊
Magic number（檔案簽章）
| 0x00000000 | 664C6143 | fLaC | 'fLaC' stream marker |
關於 FLAC 格式
FLAC 壓縮音訊時什麼都不丟，通常壓到原始大小的一半到七成之間，而解碼還原出來的就是當初進去的那些取樣值，一個不差。它的做法是替每一塊音訊配一個短的預測器，只存殘差，這件事反推回去很便宜，而且完全不需要浮點運算 — 解碼器在最弱的硬體上都跑得夠快。檔案是四個位元組的標記，接著一串中介資料區塊，然後是音訊音框。第一個中介資料區塊一律是 STREAMINFO，播放器在解出第一個取樣值之前需要的設定全都在裡面，其中還包括原始音訊的 MD5 摘要 — 靠它，你在很多年之後仍然證明得了某次解碼是逐位元正確的。
檔頭結構，一個位元組一個位元組看
| 位移 | 長度 | 欄位 | 意義 |
|---|---|---|---|
| 0 | 4 | Stream marker | 66 4C 61 43，ASCII 的 fLaC，大小寫就是這樣混著。它就是全部的 magic number，而且跟多數音訊格式不同，它是真的在位移 0 — FLAC 規格不允許在它前面寫任何中介資料標籤。 |
| 4 | 1 | First metadata block header | 最高位元是「這是最後一個中介資料區塊」旗標，低七個位元是區塊類型。這個位元組只可能是 00 或 80，因為規格要求第一個區塊必須是 STREAMINFO、也就是類型 0；80 則代表這個檔案完全沒有其他中介資料。 |
| 5 | 3 | STREAMINFO length | 後面那個區塊的位元組數，大端序 24 位元，而且固定是 00 00 22 — 34 個位元組。其他每種中介資料區塊這裡的長度都是變動的，只有這一個不是，所以它是檢查可疑檔案時很好用的合理性檢查。 |
| 8 | 2 | Minimum block size | 任何一個音框裡最少的取樣數，大端序，至少是 16。當它等於下面那個最大值時，每個音框長度都一樣，於是 seek 可以用算的，不必去查表。 |
| 10 | 2 | Maximum block size | 任何一個音框裡最多的取樣數，大端序，上限 65535。參考編碼器在多數取樣率下用 4096，也就是讀到 10 00；如果看到的是 12 00，那就是 4608。 |
| 12 | 3 | Minimum frame size | 串流裡最小音框的位元組數，大端序 24 位元。零是合法的，代表編碼器沒有記錄它 — 一個從來沒回頭補標頭的串流寫入端，留下的就是這個。 |
| 15 | 3 | Maximum frame size | 串流裡最大的音框，單位是位元組，編碼方式相同，不知道時就是零。解碼器用這一對值來決定輸入緩衝區要多大，不必用猜的。 |
| 18 | 8 | Packed audio parameters | 六十四個位元，而且完全不理會位元組邊界：二十個位元是取樣率（Hz），接著三個位元放聲道數減一，再五個位元放每取樣位元數減一，最後是 36 位元的總取樣數。取樣率 0A C4 4 是 44100；取樣率為零不合法，而總取樣數為零代表寫檔當下還不知道長度。 |
| 26 | 16 | MD5 of the unencoded audio | 壓縮之前那些原始取樣值的摘要。這就是驗證程序在解碼之後拿來比對的東西，也是為什麼 FLAC 能證明一次轉檔跟原碟逐位元相同，而不只是「播得動」。全部是零代表編碼器沒去算它，而所有建立在它之上的保證也就此消失。 |
| 42 | 4 | Second metadata block header | 同樣是一個位元組的旗標與類型，後面接 24 位元的長度，位置固定是因為 STREAMINFO 永遠剛好 34 個位元組。類型有 0 STREAMINFO、1 PADDING、2 APPLICATION、3 SEEKTABLE、4 VORBIS_COMMENT、5 CUESHEET、6 PICTURE。讀到 04 00 00 2E 就是一個 46 位元組的 Vorbis comment，而且最後一塊的旗標沒有設，代表後面還有別的區塊。 |
怎麼跟長得像的格式分開
| 容易搞混的 | 怎麼分 |
|---|---|
| Ogg | FLAC 除了原生形式之外，也可以裝在 Ogg 容器裡，而裝著它的 .oga 或 .ogg 檔案，位移 0 是 Ogg 的頁面標記 4F 67 67 53、也就是 OggS 四個字母。fLaC 這個字串仍然會出現，在往後幾十個位元組的第一個封包裡 — 所以一個只掃描標記、而不去測位移 0 的偵測器，會把 Ogg 檔案叫成原生 FLAC。 |
| WAV | 這是大家真的會拿來比較的一對，因為兩者都是無損、也裝著同樣的取樣值。WAV 是 RIFF，開頭 52 49 46 46，位移 8 的格式類型是 WAVE，PCM 完全不壓縮，而它 32 位元的大小欄位讓檔案卡在 4 GB。FLAC 用大約一半的空間裝同樣的音訊，另外附上像樣的標籤，還帶著讓你日後驗證得了的 MD5。 |
| MP3 | 位元組層級毫無玄機 — 看得懂的 fLaC 對上一個 ID3 標籤或一個音框同步 — 但有一個方向確實存在真實的失效模式。某些標籤軟體即使規格明文禁止，還是會把 ID3v2 標籤寫到 FLAC 檔案前面，這會把標記擠離位移 0，於是對任何先測 49 44 33 的東西來說，這個檔案看起來就是 MP3。 |
| ALAC | Apple 的無損編碼，也是為什麼一個無損音樂庫可能以兩種形式之一送到你手上。ALAC 住在 MP4 容器裡，所以檔案位移 4 是 ftyp box，副檔名通常是 .m4a，而裡面任何地方都沒有 fLaC 標記。兩者互轉是把同樣的取樣值真的重新編碼一次，但音質不會有任何變化，因為兩邊都是無損的。 |
常見的壞法
- 截斷。被切掉的 FLAC 會一路乾淨地解到缺掉的位元組為止，然後就結束了，所以「播得出來」什麼都證明不了。抓得到它的是位移 26 的 MD5：完整驗證會把每個取樣值解出來再比對摘要，這也是唯一能確認一個從舊備份翻出來的檔案還是原來那個東西的辦法。
- MD5 全部是零。有些編碼器和多數串流寫入端會跳過算摘要這一步，在位移 26 留下十六個零位元組。音訊完全沒問題、檔案也合法，而大家以為 FLAC 給了他們的那份完整性保證，就這樣悄悄不見了 — 對這種檔案做驗證，只確認得了音框的 CRC，確認不了內容。
- 總取樣數是零。位移 18 那組封裝參數裡的 36 位元欄位，是編碼結束時才補上去的，所以任何寫進管線或被中斷的東西，這裡就留著零。檔案播起來沒問題、卻報不出長度，而播放器不是顯示一片空白的時間，就是把整個檔案掃一遍自己算出來。
- 音框裡翻掉一個位元組。每個音框帶著自己的 CRC-16，所以解碼器會偵測到損壞，然後不是丟掉那一框就是吐出一聲喀，而串流其他部分完全不受影響。這就是為什麼一個輕微受損的 FLAC 仍然從頭播到尾，也是為什麼它的失敗會表現成一個聽得到的雜音，而不是拒絕開檔。
- 馬虎的標籤軟體在前面加了 ID3v2 標籤。規格要求位移 0 必須是 fLaC，某些軟體還是硬把一個 ID3 標頭寫在前面。嚴格的解碼器直接拒收，寬容的則往前掃過去照樣播，而偵測器會把它認成 MP3 — 而這個檔案的音訊其實一點事都沒有。
這個格式現在還在用嗎
在 Apple 生態系之外，講到無損音訊實務上指的就是 FLAC。CD 轉檔、Bandcamp 與 Qobuz 的高解析度下載、典藏母帶，以及任何之後還要再轉檔的東西，全都住在它裡面，因為它沒有專利、不用授權、在跑不動什麼東西的硬體上解碼也很快，而且從 2016 年前後起每個瀏覽器都支援。它唯一像樣的對手是 ALAC，那東西在 MP4 容器裡做同樣的事、得到同樣的結果，存在的主要理由是 Apple 想要自己的一套；WavPack 和 Monkey's Audio 各有一小群擁護者，但完全談不上覆蓋率。FLAC 根本不跟 MP3、AAC 或 Opus 競爭 — 它是那些的兩到五倍大，本來就不是拿來交付的。合理的模式是把 FLAC 當母帶留著，需要時再生一份有損的複本，因為有損複本隨時可以再生一次，而為了生它而丟掉的細節永遠回不來。
在這個站上打開 FLAC 檔
這些全部在你的瀏覽器裡跑，檔案不會離開你的電腦。
相關格式
容易和 FLAC 搞混的格式，可以比對它們的開頭位元組。