Getting the Audio Out of a Video Without a Second Generation of Loss

"Extract" is a promise the button does not keep

There are two entirely different operations hiding behind the same word. One is a stream copy: the audio bytes are lifted out of the video container and dropped into an audio container without ever being decoded. Nothing is examined, nothing is judged, nothing is discarded — on a command line it is written -c:a copy, it finishes in a second even on a two-hour file, and the result is bit-for-bit the track that was in the video. The other is a re-encode: decode the track back to raw samples, then hand those samples to an encoder to be compressed again.

This tool does not offer the first one. Read what it actually runs and there are exactly three recipes, all of them re-encodes: MP3 goes through libmp3lame at variable-bitrate quality 2, AAC goes through the AAC encoder at a fixed 192 kbit/s, WAV goes through 16-bit little-endian PCM. All three drop the video stream, and none of them pass any instruction about sample rate or channel count, so the output inherits whatever the track had. That is worth knowing not because it is a flaw — a stream copy has its own traps, and it can only ever write the format the track already was — but because it changes which button is the safe one. When every path decodes and re-encodes, the safe path is the one whose encoder is lossless.

Generations, and why the second one is the expensive one

A lossy encoder does not shrink sound by finding redundancy in it. It decides which parts of the signal a listener will not miss and removes them, using a model of hearing: a quiet tone next to a loud one at a similar frequency is inaudible, so it need not be transmitted. The result sounds like the original to a person, but it is not the original, and the residue it leaves behind — the quantisation noise the model deemed acceptable — is now part of the signal.

Run that through a second encoder and the model is now looking at the wrong thing. It sees the first encoder's artefacts as signal and spends bits protecting them, while the genuine content it should be protecting has already had its margins eaten. This is why a track that survived one pass at 128 kbit/s sounds noticeably worse after a second pass at 190, even though the second file is bigger: you paid for more bits and got less music. There is no arithmetic here that tells you how much worse — it depends on the material and on how close the two encoders' models are — but the direction is never in doubt, and it never reverses. Nothing downstream restores what the first pass removed.

What each button costs, in bytes you can check

Uncompressed audio has an exact size and no surprises: bytes per second = sample rate × bit depth ÷ 8 × channels. A 48 kHz stereo film track at 16 bits is 48 000 × 2 × 2 = 192 000 bytes a second, which is 11.52 MB a minute and 115.2 MB for ten minutes. If the track is 5.1 rather than stereo it is three times that, because the channel count multiplies directly. Nothing in the tool warns you before it writes a 350 MB file, so it is worth doing the multiplication first on anything longer than a few minutes.

The AAC button is equally predictable, because its bitrate is fixed at 192 kbit/s: 24 000 bytes a second, 1.44 MB a minute, 14.4 MB for ten minutes, whatever the material. The MP3 button is the one that will not tell you in advance. It runs at LAME's variable quality 2, which spends bits where the music needs them and saves them where it does not — LAME's own documentation puts the average at roughly 190 to 200 kbit/s on typical music, so ten minutes lands around 14 or 15 MB, but a quiet spoken passage will come out much smaller and a dense orchestral one much larger. If you need to know, weigh the file: size in bytes ÷ duration in seconds × 8 is the bitrate you got.

For a transcript, almost everything you are keeping is thrown away anyway

Speech recognition systems do not listen the way you do. Whisper, the model behind most of the transcription services people use, resamples every input to 16 000 samples a second in mono before it looks at anything, then turns thirty-second windows of that into a spectrogram. Its own source code says so in two constants and two command-line flags. Everything above 8 kHz — half the sample rate, by Nyquist — is gone before the first layer of the network sees the audio, and so is the stereo image, and so is any distinction between a 320 kbit/s file and a 96 kbit/s one that both survive the resampling intact.

The practical consequence is that you should optimise a transcription upload for size, not for fidelity — but you should still avoid a second lossy generation, because lossy artefacts are precisely the kind of noise that pushes a recogniser toward the wrong word. The clean route is WAV out of this tool, then the audio converter to drop it to mono at 22.05 kHz, which is 44 100 bytes a second: 4.35 times smaller than the 48 kHz stereo original and still well above the 16 kHz the model will use. The converter does not offer 16 kHz itself, so 22.05 mono is as close to the model's own working format as you can get here, and it is close enough that the last step costs nothing you care about.

The AAC file you get is not an M4A

Press AAC and you get a file whose name ends in .aac: a bare stream of encoded audio frames, each with a small header, and nothing around them. An .m4a is the same audio inside an MP4 container, and the container is what carries the duration, the seek index, the track title, the artist and the cover image. A raw stream has none of that. Most players cope — they read the first few frames, assume the bitrate holds and estimate the length — but the estimate is wrong on variable material, seeking is approximate, and anywhere that expects tags will show you a file with no name and no artwork.

Two practical rules follow. If the destination is a podcast host, a music library or anything that indexes metadata, do not hand it the .aac — take MP3, which carries its tags inside the stream itself and is understood everywhere, or take WAV and let the destination encode. And if the video's track is 5.1 surround, expect MP3 to be the button that fails: MP3 is a two-channel format and the tool passes no downmix instruction, so there is nothing to tell the encoder what to do with six channels. AAC and WAV both handle it, and the audio converter will fold the result down to stereo or mono afterwards if that is what you wanted.

It takes the whole track, and it runs on your machine

There is no start or end control here: the tool takes the entire audio stream of whatever file you give it. If you only want ninety seconds out of a forty-minute recording you have two orders to choose between, and they are not equivalent. Trimming the video first means the extraction only ever sees the part you care about, which is faster and produces a smaller intermediate. Extracting first and trimming the audio afterwards means one very large WAV lands on your disk before you cut it down — but it also means you can cut precisely by ear, on the waveform, rather than by guessing timecodes against a video preview.

Whichever order you pick, none of it leaves the machine. The extraction runs a build of FFmpeg compiled to WebAssembly inside the page, and the engine is served from this site rather than a third-party network, so the only thing that ever travels is the one-off engine download of about 32 MB on your first conversion of a session. That matters more here than on most tools: a video's audio track is the part most likely to contain a private conversation, an unreleased recording, a client meeting or somebody else's voice, and the difference between processing it locally and posting it to a server is not a matter of degree.

Frequently asked questions

Why is my extracted MP3 bigger than the audio track that was in the video?

Because the encoder is aiming at a quality target, not at your source's bitrate, and it has no idea your source was already compressed. Variable quality 2 is tuned to be roughly transparent on original music, which lands it near 190 kbit/s on typical material — comfortably above the 128 kbit/s a phone or an editor commonly writes into an MP4. So the new file is about half again as large as the old track and sounds slightly worse, because it spent those extra bits reproducing the first encoder's artefacts faithfully. This is the clearest possible demonstration that bitrate is not quality: you cannot spend bits back into a signal that has already lost them.

Is there any way to get the original track out untouched?

Not with this tool, and the reason is worth understanding rather than working around. A true stream copy can only ever write out the format the track already is — if the video holds AAC, a copy gives you AAC and nothing else; you cannot copy an AAC track "to MP3". So a copy button would need to first tell you what is inside your file, then offer exactly one output, and it would be useless for the most common request, which is a format the destination will accept. The compromise this tool makes is to always re-encode and let you choose, and the way to make that compromise cost nothing is to choose WAV, which re-encodes losslessly. If you genuinely need the original bytes, the command line is the honest answer: -c:a copy into a container that accepts them.

It failed and told me to check whether the video has an audio track. What else causes that?

That message is the tool's single catch-all for anything the engine refused, so the missing track is only the first suspect. The others, roughly in order of how often they turn up: a surround track sent to the MP3 button, which cannot represent more than two channels; a container the build does not carry a decoder for, which is most likely on older or unusual formats rather than on MP4, WebM and MOV; a screen recording exported with the audio switched off, which genuinely has no track; and a file large enough that the browser tab ran out of memory partway through, which tends to happen well above an hour of video. Try WAV first — it has the fewest constraints of the three — and if the same file works as WAV but not as MP3, the answer was the channel count.

For a podcast, should I extract to MP3 straight away?

Only if nothing else will happen to the file. A podcast episode almost always gets levelled, gated, topped and tailed, joined to an intro and normalised to a loudness target, and every one of those operations decodes the audio, changes it and writes it back. Do them on an MP3 and you accumulate a generation each time. Take WAV out of here, do the whole edit on WAV, and encode once at the very end — and let the host do that encode if it offers to, because most hosts re-encode whatever you upload anyway to hit their own delivery bitrate. Uploading an MP3 to a host that re-encodes is the classic way to spend three lossy generations on one episode.

The extracted WAV is far too big to email. What is the smallest honest option?

It depends on what the file is for, and the two answers are far apart. If a person is going to listen to it, the AAC at 192 kbit/s is eight times smaller than the WAV and, for speech, indistinguishable from it — one extra lossy generation on a spoken track is a cost almost nobody can hear. If a machine is going to read it, do not compress at all: put the WAV through the audio converter, set it to mono at 22.05 kHz, and you get a file 4.35 times smaller with no lossy stage anywhere in the chain. And if the recording is long rather than large — an hour of interview — the right move is neither, it is to trim the part you actually need first, because half of what makes these files unmanageable is that nobody cut them.