Manatee

The exported video has no sound. Six causes, in order of likelihood

· 6 min read

The export completes without error. You play the file and there is nothing. The source had audio, so something dropped it along the way.

Before changing any settings, find out whether the audio is missing from the file or merely not reaching your speakers. Those are different problems and the second one is embarrassingly common.

Step zero: is there an audio stream at all?

ffprobe -v error -show_entries stream=index,codec_type,codec_name,channels \
  -of default=noprint_wrappers=1 export.mp4

A healthy file prints a block for the video and a block for the audio:

index=0
codec_name=h264
codec_type=video
index=1
codec_name=aac
codec_type=audio
channels=2

If there is no codec_type=audio block, the audio genuinely is not in the file, and causes one to four below apply. If there is one, the audio exists and something in playback is at fault, which is causes five and six.

Cause one: the stream was never mapped

This is the most frequent cause when a conversion was run from the command line, and it surprises people because it happens silently.

The moment you use -map for anything, ffmpeg stops including streams automatically and includes only what you name. Map the video and forget the audio, and you get a silent file with no warning:

ffmpeg -i in.mov -map 0:v -c:v libx264 out.mp4      # silent, and no error
ffmpeg -i in.mov -map 0:v -map 0:a -c:v libx264 -c:a aac out.mp4   # correct

If you are not doing anything that needs -map, leave it out entirely and the default stream selection picks the best video and audio for you.

Cause two: the container will not carry that codec

Containers accept a limited set of codecs. Put an incompatible audio codec into an MP4 and the audio is dropped or the file refuses to build.

The common collision is PCM audio, which lives happily in MOV and WAV and is not valid in MP4. Copying streams from a MOV with PCM audio into an MP4 fails on the audio while the video succeeds:

ffmpeg -i in.mov -c copy out.mp4          # video copies, audio may vanish
ffmpeg -i in.mov -c:v copy -c:a aac -b:a 192k out.mp4    # correct

Re-encoding just the audio to AAC while copying the video is fast, since only the small stream is processed. Container versus codec explains the distinction that causes this whole category of problem.

Cause three: the source has multiple audio tracks

Files from cameras, screen recorders and editing tools often carry several audio tracks: a camera mic, an external mic, a separate system audio track. Default stream selection picks exactly one, and it may not be the one with sound in it.

List what is there:

ffprobe -v error -select_streams a -show_entries stream=index,channels,codec_name \
  -of default=noprint_wrappers=1 in.mov

If several appear, name the one you want, counting from zero within the audio streams:

ffmpeg -i in.mov -map 0:v -map 0:a:1 -c:v copy -c:a aac out.mp4

To keep every audio track in the output:

ffmpeg -i in.mov -map 0 -c:v copy -c:a aac out.mp4

Screen recordings are the classic case here: a track for the microphone and a track for system audio, with the silent one selected by default.

Cause four: the source was silent to begin with

Worth ruling out before blaming the export. A screen recording made without granting microphone access, or with system audio not captured, contains a valid audio stream carrying silence. ffprobe shows the stream, so it looks fine.

Measure the actual level rather than trusting the stream’s presence:

ffmpeg -i in.mov -af volumedetect -f null - 2>&1 | grep -E "mean_volume|max_volume"

A max_volume of -91.0 dB or similar means digital silence. The export is faithful; the recording was empty. Nothing downstream will recover audio that was never captured.

Cause five: the player, not the file

If ffprobe shows a healthy audio stream and volumedetect shows real levels, the file is fine.

Check that the audio codec is one your player supports. Some players handle a narrow set. Try the file in a different player before assuming anything. Check macOS output routing too, in System Settings under Sound, since a stray Bluetooth device claiming output is a genuinely common explanation for a file that seems silent.

Cause six: the audio is there but inaudible

Levels can survive an export and be far too quiet, particularly when a source was recorded with a low input gain and an export normalised nothing.

ffmpeg -i quiet.mp4 -af loudnorm=I=-16:TP=-1.5:LRA=11 -c:v copy fixed.mp4

loudnorm applies broadcast-style loudness normalisation, bringing the track to a consistent level without the pumping that simple amplification causes. -c:v copy leaves the picture untouched.

A working order

  1. ffprobe for an audio stream. Absent means the file lost it; present means playback.
  2. If absent, check your -map usage.
  3. Check container and codec compatibility, especially PCM into MP4.
  4. List all audio streams; pick the right one.
  5. volumedetect on the source to confirm it was not silent.
  6. If present and audible in ffprobe terms, test another player and check output routing.

When the source file is damaged

If the source will not report its streams properly, or reports an audio stream with no duration, you are dealing with a damaged file rather than an export setting, and no amount of mapping will help.

Manatee reads whatever survives in a damaged video or audio file and writes a clean copy, working from a duplicate so the original is untouched, which gives an export something coherent to read. It handles the container and codec pairing itself, so the PCM-into-MP4 trap does not arise. It cannot restore an audio track that was never recorded, and it will tell you that rather than producing a silent file and calling it a success. How to check whether a video file is corrupted is the quicker test to run first.

Questions

The audio works in QuickTime but not in a browser. Almost certainly a codec the browser will not decode. Re-encode the audio to AAC, which is universally supported, while copying the video.

Why does -c copy sometimes drop audio silently? Because it tries to place the existing stream in the new container, and if the container rejects that codec the audio is discarded. Specify -c:a aac when changing containers unless you are certain the codec is valid in the destination.

My export has sound on the Mac and none on a phone. Check the channel layout. A 5.1 track that a phone will not downmix can play as silence. Force stereo with -ac 2.

Does re-encoding audio lose quality? Once, slightly, and inaudibly at 192 kbps AAC for speech and most music. Repeated re-encoding does accumulate, so keep the source file.