Convert MKV to FLAC

Live capture is the usual story. A concert, a recital, a broadcast or a conference session gets filmed and recorded at the same time, and the person doing it wants the sound kept properly even though the picture is only ever going to be a reference. Matroska is where that combination goes, because it is the only widely used video container that will accept a FLAC audio track alongside the video without complaint.

MP4 will not do this. Nor will MOV in any way a normal tool will produce. So a recordist who wants lossless audio and a picture in one file has essentially one option, and that is why a certain kind of MKV turns up in music and archive collections rather than film ones.

If the MKV already carries FLAC, the audio is decoded to samples and encoded again as FLAC, and the samples that come out are the samples that went in. FLAC is a lossless codec in both directions, so a second pass changes the compression and not the sound. Verify it if you like: decode both to PCM and compare the checksums.

This is worth stating precisely because it is rare here. Almost every other conversion on this site costs something, and most pages exist partly to say so. This one has a real case where the answer is nothing at all, and the only condition is what the source track happens to be.

Nothing, is the short answer, and it is worth being blunt. A lossy codec discards detail permanently when it encodes. FLAC then stores whatever the decoder produces with perfect fidelity, which means it preserves the loss along with the sound. The file is exactly as good as the AAC it came from and several times larger.

That is not always a bad trade. If the recording is about to be edited, restored or processed repeatedly, holding it as FLAC between passes stops any further compression from accumulating, and the checksum gives you something to verify against later. What it does not do is upgrade anything, and any tool that suggests otherwise is selling storage.

FLAC as a format holds exactly one audio stream. Matroska has room for 127 and live recordings often use more than one — a desk mix and a pair of room microphones, a stereo bounce and a spare, a main feed and a translation channel. When the file holds several, the first one declared is converted and the others are discarded without comment.

The route to all of them is to convert the whole MKV to a MOV or an MP4 first, both of which carry every audio track the browser can decode, and to split them out in a DAW. It costs a generation of compression on each track, which is exactly the wrong outcome for an archive — so where the material really matters, MKVToolNix on the desktop will separate the tracks without decoding anything.

Against uncompressed PCM, FLAC is typically around half the size for the same samples, and there is no setting to trade because there is nothing to trade — the output is identical either way. Against the lossy track that may have been inside the MKV, it is several times larger, and every one of those bytes is describing the same sound in more detail than the original codec preserved.

The reason to accept that on an archive is verification rather than fidelity. FLAC writes an MD5 of the decoded audio into its own header, so a file can be checked against itself years later and prove it has not been silently truncated or corrupted in a backup cycle. WAV holds the same samples in twice the space with nothing to verify them against.

If the conversion stops with a message saying nothing in the file could be converted, the browser was unable to decode the soundtrack and, with the picture discarded, there was nothing left to write. The codecs involved are always the same: AC-3, E-AC-3, DTS and Dolby TrueHD.

Those are the soundtracks on DVDs and Blu-rays, and browsers ship no decoders for them — DTS and TrueHD are not recognised as codecs by the reader at all. It is worth noting for archivists specifically, because a TrueHD track from a concert Blu-ray is precisely the sort of thing somebody would reasonably want in FLAC, and it is the one case this cannot help with. A desktop tool that owns those decoders is the answer.

Title, artist, album, date, description and comment are read out of the Matroska tags and written into the FLAC as Vorbis comments — the tag format every music player, library manager and archive tool expects to find there. Embedded cover art is carried into the FLAC’s picture block where the source has one.

In practice most MKV recordings carry nothing, because recorders do not write tags and ripping tools rarely bother. That leaves an untagged FLAC named after the source file, which is fine for one recording and unmanageable for fifty. Tagging on the way into the archive rather than afterwards is the habit worth having.

The decoding and the FLAC encoding both run inside the browser tab. Nothing carrying the file is sent anywhere, there is no account, and there is no queue. If the browser has no native FLAC encoder, a WebAssembly build of the reference encoder is downloaded once and used from then on, which is why the first conversion in a session starts slightly slower than the ones after it.

The free tier takes files up to 100 MB, measured on the MKV going in. A full concert capture is well past that, and the honest recommendation for one is a desktop tool that can copy the FLAC track straight out of the container without decoding a single sample — which is both faster and, for an archive, the more correct operation.