Someone asked me to get the sound off a 40 minute lecture recording so it could go on a phone for the commute. I did the obvious thing first, which was convert it to MP3, and it took a couple of minutes and produced a file slightly larger than the audio that was already sitting inside the video. Then I did the thing I should have done first and copied the track out instead. It took under a second, the file was smaller, and the audio was bit for bit identical to what the recorder captured. The second method is not a trick or a shortcut. It is what the file format was designed for, and almost every converter that answers this question ignores it.
TL;DR: An MP4 or MOV usually carries AAC audio, and an M4A is that same AAC in an audio-only container from the same family, so the track can be copied straight out with no decoding and no loss. Measured on a 60 second test clip here: the copy finished in 0.04 seconds and the extracted audio stream had the same MD5 as the stream inside the video. Encoding the same audio to MP3 at 192 kbps took 0.36 seconds, produced a file 48% larger, and went through a second round of lossy compression it did not need. Pick M4A unless something downstream refuses it, pick WAV when an editor or a transcriber wants PCM, and pick MP3 only for a device that reads nothing else. The audio extractor does all three in the browser tab, so a recorded meeting never leaves the machine.
What is inside an MP4's audio track?
An MP4 is a container, which means it is a filing system rather than a format. Inside it are separate streams: one holding compressed pictures, one holding compressed sound, sometimes subtitle tracks and chapter markers beside them. The container describes where each one starts, how long it runs and what codec was used, and that is almost all it does.
The sound stream in an MP4 is nearly always AAC. That is what an iPhone produces, what a Mac screen recording produces, what a QuickTime export produces, what a drone produces, and what every camera that writes MP4 or MOV has produced for about fifteen years. There are exceptions, mostly older files with MP3 audio inside an MP4 wrapper and professional formats carrying uncompressed PCM, but AAC is the overwhelming default.
This is checkable on any file you have. ffprobe will tell you in one line, and so will the file inspector in most video players. On the test clip I built for this guide, the audio stream reports as aac, 44100 Hz, stereo, 128158 bit/s, which is an ordinary camera-grade recording.
The useful consequence is the one in the next section. Once you know the stream is AAC, you know an M4A can hold it without touching it.
Why can the audio come out without being converted?
Because M4A is the same container with the video part left out.
Both MP4 and M4A are profiles of the ISO base media file format, the structure standardised as ISO/IEC 14496-12 and shared by MP4, M4A, M4V, MOV and a handful of others. It grew out of Apple's QuickTime format, whose box layout is still documented in full and reads as a description of MP4 because it very nearly is one. The boxes are laid out the same way, the sample tables work the same way, and an AAC track written into one is byte for byte the same track written into the other. The extension differs so that an operating system knows whether to open a player window, and that is most of what the extension is for.
So extracting audio from an MP4 into an M4A is not a conversion. It is a remux: the audio samples are read out of one container and written into another, and no decoder or encoder is involved at any point. Nothing is interpreted, so nothing can be degraded.
This is the same distinction that causes the larger misunderstanding on the video side, covered in the video format guide: changing a wrapper is close to free, changing the compression inside it is not. Audio extraction is the case where the free option is also the correct one, which is rarer than it should be.
In ffmpeg terms the whole operation is four arguments:
ffmpeg -i recording.mp4 -vn -acodec copy recording.m4a
-vn drops the video stream. Leave it out and ffmpeg tries to carry the picture into a container that has nowhere to put it, which produces an M4A your music player refuses to open. -acodec copy is the part that makes it lossless: it tells ffmpeg to pass the samples through rather than hand them to an encoder.
How do you know the copy really lost nothing?
Because you can hash the stream before and after, and the two hashes match.
I built a 60 second test file, 1280x720 H.264 video with a 128 kbps stereo AAC track, 19 MB in total. Then I hashed the audio stream inside the video, copied the audio out, and hashed it again:
$ ffmpeg -i src.mp4 -vn -c:a copy -f md5 -
MD5=650032f86f01780991c64c30bd02f71b
$ ffmpeg -i src.mp4 -vn -acodec copy out.m4a
real 0.04
$ ffmpeg -i out.m4a -c:a copy -f md5 -
MD5=650032f86f01780991c64c30bd02f71b
Same digest, so the compressed audio data in the M4A is the compressed audio data from the video, with not one bit altered. The extracted file was 950 KB and the whole operation took 0.04 seconds, which is roughly the time it takes to read 19 MB off an SSD.
That test is worth running on your own file rather than taking on trust, because it is the only way to tell a real copy from a conversion that claims to be one. If the two hashes differ, something re-encoded your audio while telling you it had not.
What does choosing MP3 instead cost you?
A second generation of lossy compression, plus a larger file.
AAC and MP3 both work by discarding what a psychoacoustic model predicts you cannot hear, and they disagree about what that is. They split the signal into different numbers of bands, they model masking differently, and they handle sudden transients differently. So when an MP3 encoder is handed the decoded output of an AAC file, it cannot tell which parts came from the microphone and which the first encoder left behind. It spends bits preserving both, and throws away some of what survived the first pass.
Here is the same 60 second clip through each path:
| Output | How it was made | Size | Time | Further loss |
|---|---|---|---|---|
| M4A | AAC stream copied | 972,706 bytes | 0.04 s | None, hash-identical |
| MP3 192 kbps | Decoded, re-encoded with LAME | 1,441,479 bytes | 0.36 s | Yes, second generation |
| WAV | Decoded to 16-bit PCM | 10,584,142 bytes | 0.05 s | None added, none undone |
The MP3 is 48% larger than the M4A while holding audio that has been through one more lossy encoder. There is no setting that avoids this, because the loss is in the decode and re-encode itself rather than in the bitrate.
None of which makes MP3 wrong. A car stereo from 2009, a cheap voice recorder, a gym treadmill with a USB port and a surprising amount of broadcast software will read MP3 and nothing else. When that is the destination, the generation loss is the price of the file playing at all, and it is a small price on speech. The point is to pay it knowingly rather than because a tool picked MP3 for you.
Does a higher MP3 bitrate make the extraction better?
It makes the MP3 a more faithful copy of the damaged audio, which is not the same thing as better.
I tested this with a broadband source, because pure tones are easy for a codec and tell you nothing. The test clip was 30 seconds of pink noise mixed with a low sine, encoded to 128 kbps AAC, which is roughly how hard real music is on an encoder. Then I decoded that AAC to PCM to use as the reference, encoded it to MP3 at two bitrates, and measured the signal to distortion ratio of each against the reference:
| MP3 bitrate | Size for 30 s | SDR against the AAC source |
|---|---|---|
| 192 kbps | 705 KB | 26.7 dB |
| 320 kbps | 1.1 MB | 42.3 dB |
The 320 kbps file is a much closer reproduction of the AAC audio, by about 15 dB. What it is not is a closer reproduction of the original recording, because the AAC already discarded that and no encoder can put it back. The extra 400 KB bought a more faithful copy of the first encoder's output, artefacts included.
So the rule from the audio converter guide holds, with a sharper reason behind it. Matching or slightly undercutting the source bitrate is the sensible range. Going well above it is spending storage to preserve detail that is not in the recording, and going well below it throws away a second helping of what is.
If fidelity to the original is what you care about, the answer is not a bitrate. It is the M4A copy, which has no bitrate decision to make.
When is WAV the right answer?
When something downstream wants PCM, which is more often than people expect.
Audio editors prefer it because it needs no decoding and can be edited sample by sample. Transcription services and speech models frequently demand it, and the ones that accept compressed audio usually decode it to PCM internally anyway. Forced alignment tools, acoustic analysis software and anything doing signal processing all start from PCM.
WAV adds no further loss, though it cannot undo what the source already discarded. A WAV made from a 128 kbps AAC track still has every missing detail that the AAC was missing. It is a faithful container for damaged audio, which is exactly what you want when the next step is analysis rather than listening.
The measured result is reassuring on this point. The WAV I extracted was bit for bit identical to a direct decode of the source audio, same MD5, so the extraction added nothing of its own. The cost is size, which the next section covers.
16-bit 44.1 kHz stereo is the sensible default and what the extractor writes. It is CD specification, it is universally readable, and nothing is gained by writing 24-bit PCM from a source that was lossy to begin with.
How big will the file be?
Predictably, which is the useful part.
Audio size is bitrate times duration, with no dependence on content, so unlike video it can be told to you before the work starts rather than guessed at afterwards.
| Format | Per minute, stereo | One hour |
|---|---|---|
| M4A copied from a 128 kbps source | 0.95 MB | 57 MB |
| MP3 192 kbps | 1.4 MB | 84 MB |
| MP3 128 kbps | 0.96 MB | 58 MB |
| WAV 16-bit 44.1 kHz | 10.1 MB | 606 MB |
The WAV row is the one that surprises people. 10.1 MB a minute is a measured figure from the test above, and it follows directly from the arithmetic: 44,100 samples a second, two bytes a sample, two channels. An hour of lecture audio in WAV is a 600 MB file, which is larger than many of the videos it came out of and larger than some services will accept as an upload.
That is also why the extractor shows an estimate before it runs. A one hour recording extracted to WAV is a reasonable thing to want and an unreasonable thing to be surprised by.
Why does a WebM refuse to copy its audio into an M4A?
Because the codec inside it is one the MPEG-4 container will not carry, and the tool is honest about that rather than silently re-encoding.
A WebM holds Opus or Vorbis audio, not AAC. Neither belongs in an M4A as far as the standard muxers are concerned, so the copy path is not available. ffmpeg says so plainly:
[ipod @ 0x75bd019180] Could not find tag for codec opus in stream #0,
codec not currently supported in container
[out#0/ipod] Could not write header (incorrect codec parameters ?)
There is a published specification for encapsulating Opus in an ISO base media container, so this is a tooling and playback reality rather than a theoretical impossibility. In practice nothing you would hand the file to plays an M4A full of Opus, so the useful answer is to re-encode. On the same test content that took 0.32 seconds for 20 seconds of audio and produced a 473 KB file, which is one generation of loss and the only option available.
The same logic decides every other source. MP4, MOV, M4V and M4A can have their AAC copied out. WebM, MKV with Opus or Vorbis, and anything carrying a codec from outside the MPEG-4 family cannot, and the extractor says which case you are in before it starts rather than after.
Why do the durations not match exactly?
Because AAC and MP3 both pad their output, and the two containers handle that padding differently. It is the detail that breaks gapless playback, and it shows up clearly in the test numbers.
The source audio was exactly 60 seconds, 2,646,000 samples at 44.1 kHz. The extracted M4A reports a duration of exactly 60.000000 seconds. The extracted WAV and MP3 both report 60.000363 seconds, which is 16 samples longer.
Those 16 samples are encoder delay. AAC works in 1024 sample frames, so a 60 second recording does not divide evenly and the encoder pads the end. The M4A hides this using an edit list, a small table in the container that says which part of the decoded output is the real recording. Decode the M4A and you get the padded 2,646,016 samples back, which is where the WAV's extra 0.36 milliseconds comes from.
MP3 has no edit list, because the format predates the idea. What it has instead is the LAME information tag, a vendor block in the first frame recording how many samples to discard at each end. The field layout is documented byte by byte, and the encoder delay and end padding share bytes 0xB1 to 0xB3 as two 12-bit values. Decoded, the MP3 came back at 2,646,016 samples, matching the WAV exactly, so the tag did its job here. A player that ignores it, or an encoder that fails to write it, is where the audible click between tracks of a continuous album comes from.
None of this matters for a lecture or a podcast. It matters a great deal for a live album or a DJ mix, and it is the reason the copy path is worth preferring when it is available: there is no encoder involved, so there is no new padding to account for.
Does M4A play everywhere MP3 plays?
Close to it, with a short list of exceptions worth knowing before you commit.
Everything made this decade plays M4A. iOS and Android both do natively, every desktop operating system does, every browser does, Spotify and VLC and Plex and the stock music app on whatever phone you own all do. The format is twenty years old and has been the default output of the most popular phone on earth for most of them.
The exceptions cluster in two places. The first is older car stereos and standalone hardware, particularly head units from before about 2012, where a USB stick full of M4A files reads as empty. The second is software that accepts audio uploads and validates by extension rather than by content, which refuses an M4A on a list written years ago and never revisited. Transcription services were a common offender here, which is how the journalist in the audio converter guide ended up with four hours of files her service would not take.
A reasonable approach: extract to M4A first, because it is instant and lossless, and keep it as the master. If the destination refuses it, convert that M4A to MP3 once. You have then paid for one generation of loss instead of making the lossy copy your only copy.
How long does an extraction take, and what decides that?
Reading the file, mostly, and then whether an encoder is involved.
The copy path is bounded by disk and memory speed rather than by processing. 0.04 seconds for a 19 MB file is not the audio being worked on, it is the file being read and a new container being written. Scaling that up, a 40 minute lecture recording of a couple of hundred megabytes comes out in a second or two, and almost all of that is the browser reading the file into the tab.
The encode paths are bounded by the encoder. LAME took 0.36 seconds for 60 seconds of stereo audio on this machine, which is roughly 165 times faster than real time, so an hour of audio is around 20 seconds of work. AAC re-encoding from a WebM measured similarly. These are quick enough that the progress bar is mostly there for honesty rather than necessity.
One thing does dominate everything else, and it is not the audio. Loading the source video into the page is the slow step for a large file, because the whole file goes into tab memory. That is the reason for the 500 MB cap: beyond that a tab starts failing in ways that are harder to explain than a stated limit. If you are working with a file bigger than that, trimming it first with the video trimmer is usually quicker than fighting the limit, and the trimming guide covers why that cut is nearly free too.
What happens when a video has more than one audio track?
One track comes out, chosen for you, and the others are dropped without comment. This is worth knowing because it is a quiet failure rather than a loud one.
I tested it with a file carrying two audio streams, a 128 kbps stereo track and a 64 kbps mono one, which is roughly the shape of a recording with a camera mic and a separate lapel mic. Extracting produced a single stream, the 128 kbps stereo one, 950 KB, with no mention anywhere that a second track had existed.
The selection is not random. ffmpeg's documented stream selection rules pick the stream it judges best, which for audio means the highest channel count, so you usually get the one you wanted. But if the quiet mono track was the interview audio and the stereo one was room noise from the camera, you get the wrong thing and nothing tells you.
Multi-track files are uncommon outside professional workflows, and almost nothing from a phone or a screen recorder has more than one audio stream. If you are working with footage from a real shoot, check the stream list before extracting, and expect to use ffmpeg directly with an explicit -map 0:a:1 when you need the second track.
Should you extract the audio or convert the whole video?
Extract, if what you want is the sound. The two operations are not alternatives and people reach for the wrong one regularly.
Converting a video to MP3 is a phrase that appears in millions of searches a month and describes an operation nobody wants. It implies decoding and discarding the picture, decoding the audio, and re-encoding it, which is a great deal of work to arrive at a worse version of something that was already there. The video converter exists for the case where you want a video at the end, in a format something will play. When you want audio, extraction is the operation, and the copy path means it is the cheap one too.
The decision table is short:
| What you want | Use | Cost |
|---|---|---|
| The soundtrack as a file | Extract to M4A | Nothing, stream copied |
| The soundtrack for an editor or transcriber | Extract to WAV | Size only |
| The soundtrack on old hardware | Extract to MP3 | One generation |
| A smaller video, picture included | Video compressor | Depends on CRF, see the compression guide |
| The same video in a format that plays | Video converter | Often a remux, so nothing |
The pattern across all five rows is the one worth taking away: ask whether the operation requires re-encoding, and prefer the one that does not.
What does running this in the browser change?
Where the recording goes, which for audio is usually the whole question.
The extractor runs ffmpeg compiled to WebAssembly inside the page. The video is read from your disk into tab memory, the audio stream is pulled out there, and the result is handed back as a download. No request carries the file, nothing is queued on a server, and no copy exists anywhere for anyone to forget to delete.
The audio people extract is mostly the kind that makes this matter. Recorded meetings, lectures, interviews, consultations, calls with a lawyer or a doctor, voice memos with things in them you would not post. The conventional alternative is to upload the recording to a site you know nothing about, in exchange for an operation that on the copy path is a container rewrite your own machine finishes in under a second.
The trade is the 500 MB cap and the one-file-at-a-time workflow, because a browser tab has less memory than a server and no queue. For a single recording, which is what this is almost always for, that is a limit you will not reach and a privacy guarantee you cannot get any other way.
