FLAC Metadata Inspector

How to use

1. Drop a .flac file on the box. Only the front of the file is read, so a long album track opens as fast as a short one.
2. Read the stream tiles first: sample rate, bit depth and channels come from STREAMINFO, and the duration is exact because the total sample count is stored rather than estimated.
3. Compare the compression ratio with the uncompressed PCM size next to it — that is the real saving for this file, and a poor ratio usually says more about the master than about the encoder.
4. Scan the block table for the layout: which blocks exist, where each one starts, which is flagged last, and the offset where the audio frames begin.
5. In the comment list, look for the fields marked as repeated — those hold more than one value, and they are what tag editors most often collapse into one.

Frequently asked questions

The same tag appears twice in my file. Is that a bug?

No — it is how the format stores multiple values. A Vorbis comment block is a list of NAME=value lines, not a dictionary, so ARTIST can legally appear three times for a collaboration and GENRE twice for a record that sits between two of them. Field names are case-insensitive, so artist and ARTIST are the same field, and the order of the lines is the order the encoder wrote them. A reader that parses the block into a plain map keeps only one value per name and drops the rest without a word, which is how a track tagged with three artists comes back with one after a round trip through the wrong editor. This page lists every line in file order and marks the names that occur more than once.

What is the MD5 in STREAMINFO, and does it prove the file is undamaged?

It is the MD5 of the decoded audio — the interleaved samples, signed and little-endian, exactly as they come out of the decoder — and not of the file. That is what makes it useful: re-encode the same audio at a different compression level and every byte of the file changes while this MD5 stays the same, which is how you prove a conversion was lossless. It is also why it cannot be checked by looking at the file. You have to decode the entire stream and hash the result, which is what flac -t does. Some encoders leave the field as sixteen zero bytes, which means no signature was stored rather than a signature that fails.

Duration says unknown and total samples is 0. Is the file broken?

It is a stream, not a broken file. The sample count in STREAMINFO is written last, once the encoder knows how long the input was; an encoder writing to a pipe or a live stream cannot seek back to fill it in, so it leaves zero, which the specification allows explicitly. Players handle it by decoding until the frames run out, and some show a duration that grows while they play. Everything else in STREAMINFO — rate, channels, depth, the MD5 — is still valid, and the file plays normally. Decoding it and re-encoding to a real file is what writes the number in.

Why does my FLAC start with an ID3 tag?

Because a tool that mostly deals with MP3 wrote one. FLAC keeps its tags in the VORBIS_COMMENT block and the specification has no place for ID3, but ID3v2 is designed to sit at the front of a file, so some rippers, players and phone apps prepend one anyway. Most decoders skip it; a few reject the file outright because fLaC is not at offset 0. This page detects the tag, reports how many bytes it takes, and reads the real metadata from where the marker actually is. Worth knowing: anything written in that ID3 tag is invisible to FLAC-aware software, so the same file can show one title here and a different one elsewhere.

What compression ratio should a FLAC file have?

Most music lands between roughly 50% and 70% of the uncompressed PCM, and the figure here is computed exactly that way: the bytes after the last metadata block, divided by total samples × channels × bit depth ÷ 8. Quiet or sparse material compresses much better, loud and heavily limited masters much worse, and something close to noise barely at all. The encoder setting (-0 to -8) changes how long encoding takes and moves the size by a couple of percent; it never changes the audio, because every level is lossless. A 24-bit master usually shows a worse ratio than a 16-bit one, because the lowest bits are close to random and there is nothing there to predict.

Is the file uploaded, and can this verify the audio?

No to both. The file is opened with the browser’s File API and parsed in the page; only the front of it is even read, because the metadata lives there and the frames after it are merely measured. Nothing is sent anywhere and there is no server to send it to. The second half of the answer matters just as much: nothing here is a claim about the audio. Block lengths, tags and pictures are read from the metadata, the frames are never decoded, and the stored MD5 is copied out rather than verified — so a file with perfect metadata and corrupt audio looks entirely healthy on this page. Decoding is what catches that.

Related tools