When VLC's Convert/Save produces a file with picture but no sound, one cause VideoLAN documents is a container that will not accept your audio codec — its own wiki says that combination "may silently fail".
That phrase is the whole story. When it fails that way there is no dialog and no refusal: VLC still writes a file, and the audio is simply not in there. Every article telling you to tick a checkbox is skipping the question you actually have: why didn't it say anything?
What Convert/Save is really doing
VLC's converter is not a converter in the way HandBrake is. VideoLAN's wiki Transcode page puts it bluntly: "In VLC, transcoding is exactly the same as streaming across a network, except that the output is sent to a file instead of a network." The same page adds that "Transcoding in VLC media player copies the movie to a new file in a different format, so you end up with both the original and new files."
That explains why the settings dialog looks like a streaming panel and why every option is called --sout-something. (That Transcode page carries its own banner reading "This page is outdated and information might be incorrect," so treat the mechanism as durable and any specific value as something to confirm against your build.)
The rule that drops your audio
Here is the paragraph that matters, from the same page:
"Note that when you decide your transcoding settings, only some container formats (muxers) can support some codecs—look at streaming features compatibility matrix to see which supports what. If your current format is incompatible with the muxer you desire, then you must transcode it to something compatible, or choose a different muxer. If you choose an incompatible stream for a given muxer, it may silently fail. You can look for error messages in the messages window to help you debug the failures."
Two things to take from it. First, incompatibility is expected, not exotic — VLC's official documentation says elsewhere that "In a perfect world, you could put any codec in any container format. Unfortunately, there are some incompatibilities." Second, VideoLAN hands you the debugging entry point in the same breath: the messages window, reachable from VLC's Tools menu. That is where the failure you never saw is written down.
Worth knowing: the "streaming features compatibility matrix" that sentence points you at no longer exists — as of 16 September 2026 the page returns "There is currently no text in this page." The document that was supposed to tell you which codec fits which container is gone.
The audio whitelists are narrow
What does still exist is the mux option reference inside VLC's official documentation, which lists the supported codecs per muxer. The audio side is tighter than most people assume:
| Muxer | Audio codecs the docs list |
|---|---|
ts | "MPEG audio, AAC and a52 for the audio stream" |
ps | "MPEG audio and a52 for audio streams" |
mpeg1 | "Supported codecs are MPEG 1 and MPEG audio." |
ogg | "vorbis, flac, speex, a52 or MPEG audio" |
asf | "MPEG audio, and a52 for audio streams" |
avi | "MPEG audio and a52 for audio streams" |
mpjpeg | "No sound track can be muxed in such streams." |
Read the last row again. For the multipart-JPEG muxer, audio is not a setting you got wrong — no sound track can be muxed at all. And ps, the standard .mpg muxer, accepts exactly two audio families. Ask it for anything else and you are in "may silently fail" territory.
Two notes on that table, because getting these wrong is easy:
- It does not cover
mp4,mkvorwebm. That is a gap in the documentation, not a missing feature — VideoLAN's own documentation index warns that "Nota Bene: Parts of this documentation are currently outdated or incomplete." Do not read the absence of MP4 as VLC being unable to write MP4. - The
avimuxer has an official health warning: "The avi muxer in VLC is known to produce corrupt files."
Since the list is incomplete, the reliable way to see what your build allows is to run vlc -H. VideoLAN also explains why no static table can be authoritative: supported codecs "are dynamically assigned by the running program."
The fastest fix: stop transcoding the audio
If your source audio is already in a format the target container accepts, the best move is to not re-encode it. VideoLAN's wiki says so directly, hedge and all:
"If your input streams already matches the encoding that you desire for your output stream, then you don't have to transcode at all (just leave out the transcode settings on the command line, and it will thence not transcode). In the GUI this is called "keep the original track" (I think)."
The "(I think)" is in the original — that is how certain the wiki is about the GUI wording, so verify the option in your own copy. On the command line the same idea is exact: "If vcodec is missing, the video codec will stay the same (same for acodec)." Omitting acodec leaves the audio alone — it does not mean "use a default". Fewer conversions, fewer chances for a muxer to reject something.
If what you needed was a container change from QuickTime to MP4, skip the muxer gamble and do it here:
Try it right here
Runs in your browser. Your file is not uploaded anywhere.
That runs inside this browser tab — the file is read from disk, rewritten locally and handed back, with nothing uploaded. The same converter has its own page at MOV to MP4, and the rest of the set is at all Clapr tools.
VideoLAN is candid about VLC's limits here. Its extract-audio guide says that for plain audio-to-audio jobs "other tools may be even more powerful, faster, or more reliable for the task," and that "Where VLC really shines is for sources which combine video and audio content." If the audio track is all you wanted, extract audio from video does it in the browser, and extracting audio without re-encoding covers the lossless command-line route.
Other causes VideoLAN documents
- Loop is switched on in the GUI. The Transcode page notes that "without the options
--no-repeat --no-loop, you may find that loop options selected in the GUI cause transcodes to fail." That one is covered in VLC Convert/Save not working. - You picked a profile by name rather than by container. VideoLAN's description of the wizard goes no further than "you can give a video codec, an audio codec and a container format" — it publishes no list of built-in profile names, so treat any preset name you read online as unverified and open the profile to check its container and audio codec.
- The sample rate you want is out of range. The transcode module documents its sample rate as an integer in
[0 .. 48000], annotated "(11250, 22500, 44100 or 48000)". The wiki'svlc -Hpage lists the same range for "vlc-4.0.0-dev under Windows", so runvlc -Hto see what your own build exposes.
How to tell it worked
Do not encode a 40-minute file to find out. VideoLAN recommends the short version: "Transcoding takes quite a while, so it's advisable to use an option like --stop-time=30 to only encode the first 30 seconds—this means you can check the file has transcoded correctly, and that the output is of a suitable quality." The wiki notes this trick does not appear to work on macOS, where you press Ctrl-C instead and VLC writes out the segment it already finished.
Keep the messages window open during that short run, then play the sample. A clean log and audible sound together are the confirmation. More container-versus-codec traps live in the fix guides.
FAQ
Why does VLC convert with no audio and show no error? VideoLAN's wiki states that if you choose an incompatible stream for a given muxer, "it may silently fail." The output file is still produced, minus the track that could not be muxed.
Where do I see the actual error? The messages window, in VLC's Tools menu. The same official paragraph points there: "You can look for error messages in the messages window to help you debug the failures."
Is there an audio checkbox I forgot to tick? That is the answer everywhere, but VideoLAN's documentation does not describe such a fix. What it does document is the muxer-versus-codec compatibility rule above — so check the container and audio codec pairing first.
The converted file has no sound in VLC. Is the file bad, or is my VLC? VideoLAN's own (self-described informal) support guide gives a quick split for playback silence: if it happens "With ALL files," the cause "most likely lies within VLC's audio output"; if it happens "Just with a few files," it "most likely lies within VLC's audio decoding." Test another file before blaming the conversion.
Can I just change the container without re-encoding anything? Often, yes — that is exactly the "don't have to transcode at all" case. If the job is MOV to MP4, the converter above does it locally in this tab. Whitelist thinking applies to other tools too; HandBrake's WebM output limits is the same class of problem in different software.
Quotes taken from VideoLAN's wiki Transcode page, its streaming and transcode-module documentation, the Extract audio HowTo and the VLC Support Guide, checked 16 September 2026. VideoLAN marks parts of that documentation as outdated or incomplete — verify anything version-specific with vlc -H on your own build.