Getting audio out of a video without losing anything

They want the audio from a video and assume MP3 is the format to ask for. Nobody has told them that the file already contains a finished, compressed audio track that can simply be lifted out untouched — and that asking for MP3 throws a generation away for no reason.

Ask for .m4a, not .mp3. The soundtrack inside almost every MP4 is already AAC, and AAC is legal inside an .m4a container, so the audio can be lifted out and rewrapped without any encoder running at all. Every compressed frame survives exactly as the camera or the editor wrote it. Ask for MP3 instead and the audio has to be decoded and compressed a second time, which throws away a generation of detail for nothing. The video-to-audio tool defaults to the copy for that reason, and tells you on screen which of the two it did.

What is actually inside an MP4

MP4 is a container, not a codec. It is an index plus a pile of numbered chunks, and the chunks belong to separate streams. A phone recording holds two: a video stream, usually H.264 or HEVC, and an audio stream, almost always AAC, usually somewhere between 96 and 256 kbps and lower still when it is a mono voice track. Screen recordings, Zoom exports, drone footage and Premiere exports all follow the same pattern.

That matters because the audio in the file is not raw. It is finished, compressed AAC, exactly the kind of thing an .m4a file contains. An .m4a is the same MP4 box with the video stream missing. Getting the audio out is therefore a filing job, not a conversion: drop one stream, keep the other, write a new index.

One footnote on the PCM row: an uncompressed camera track copies straight into a .wav when it is little-endian, which most are. A big-endian track gets rewritten byte by byte instead, which is still lossless, because no sample value changes.

What a stream copy actually does

The FFmpeg incantation is -vn -c:a copy. The first flag drops the video, the second says do not decode the audio, just move it. No decoder runs, no encoder runs, and no sample is ever unpacked and compressed again.

With no per-sample work, the cost is reading bytes and writing bytes. A copy of a two-hour lecture takes about as long as the file takes to read and write. A re-encode of the same recording does not, because it has to push every sample through a decoder and then an encoder in a single-threaded WebAssembly build.

Measured on a real fixture here: a two-second H.264 and AAC MP4 produced a 33,502-byte .m4a with no encoder invoked at all. The same file taken to MP3 ran every sample through a decoder and then an encoder, and what came out was a second-generation copy of audio that was already lossy.

The ceiling is memory, not time. The converter runs inside a browser tab with roughly a 2 GB address space, so it warns above 300 MB and refuses near the limit. Video files reach those sizes easily, and they are exactly the class that upload-based converters cap hardest, with their per-file size ceilings and their daily job counts.

The honest caveat: the container is rebuilt

You will read elsewhere that a stream copy produces a byte-for-byte identical file. It does not, and we checked rather than assuming.

So the precise claim is that the audio is identical, every compressed byte and every decoded sample, while the container's metadata is rewritten. That is stronger than the myth it replaces, because you can check it yourself with a hex comparison in about a minute. It also means the output's checksum will not match the source file's, which is worth knowing before you go looking for a match.

When it cannot be a copy

A copy is only legal when the codec is already permitted inside the target container. Three cases come up often:

• WebM with Opus audio. Most browser-recorded video and a lot of web video carries Opus. An .m4a is expected to hold AAC, and the copy whitelist here lets nothing else in. This build cannot write Opus files either, because the good Opus encoder crashes the WebAssembly core and substituting the experimental one would quietly hand you a worse file. Opus reads in perfectly, so the answer here is a re-encode to M4A or MP3, and the tool says so rather than pretending.
• MKV. Matroska accepts anything: AAC, FLAC, AC-3 or DTS off a disc rip. The tool reads the codec first and offers a copy only when the codec allows one.
• Anything you want as WAV, FLAC or AIFF from a compressed source. Decoding is mandatory in that direction. The output is an exact rendering of what the AAC decoder produces, which is not the same as an exact rendering of what the microphone heard.

The one case where video to MP3 really is a copy

A few old containers carry MP3 audio directly. A DivX-era AVI, an FLV pulled off an old hard drive: if the audio track is already MP3, writing it out as .mp3 is a rewrap and nothing is re-encoded. That is the only route by which "video to MP3" is not a second lossy pass, and almost nothing made this decade qualifies.

Everything modern will re-encode on its way to MP3. There is no way around that, and no converter has one.

Choosing MP3 anyway, and picking a sane bitrate

Plenty of reasons survive the argument. A car stereo, a transcription service with a fixed format list, a client who asked for MP3 and will not be talked out of it. The only question left is how much the second pass costs, and that is mostly the bitrate.

Match the source rather than exceeding it. If the MP4's AAC track runs at 128 kbps, asking for 320 kbps MP3 makes the file two and a half times larger and adds no detail, because the detail was discarded by the AAC encoder before you arrived. At 192 kbps and above, most listeners in blind tests cannot reliably separate an MP3 from its source on a single pass. For speech from a screen recording or a meeting, 96 or 128 kbps is honest and small. The converter shows the source bitrate before you commit, and warns when the number you picked is higher than the number the file had. There is more on what that second pass costs in does converting lose quality, and a fuller comparison of the two formats in M4A versus MP3.

Doing it without this site

If FFmpeg is already installed, one line does the job:

ffmpeg -i clip.mp4 -vn -c:a copy audio.m4a

Swap audio.m4a for audio.aac if something specifically demanded a raw AAC stream. If FFmpeg refuses with an error about initialising the output stream, the codec is not legal in that container and you need a re-encode instead.

On a Mac, QuickTime Player's File → Export As → Audio Only writes an .m4a with nothing to install. Apple does not document whether that path copies the track or re-encodes it, so if that matters, use FFmpeg or the tool here, both of which say which one happened. VLC can do it on any platform, but its profiles re-encode unless you stop them. On Windows and Linux the path is Media → Convert / Save, and the profile editor's Audio codec tab carries a Keep original audio track box. On a Mac the same dialog is File → Convert / Stream. The wording moves between VLC versions, so read the tab rather than counting clicks.

What this cannot do

The tool takes a file from your disk. There is no URL field and there will not be one, so this is not a YouTube to MP3 converter and it cannot fetch anything from a streaming service. Nothing here opens DRM-protected video either. A file with a lock on it stays locked.

Our phone app cannot do this one at all: its file picker accepts audio files only, so an MP4 will not open in it. Pull the track out in the browser with the video-to-audio tool or straight from the converter on the home page, then use the app for the trimming, fading and merging that usually comes next once the audio is on your phone.