To convert video to audio correctly, the source file must contain a decodable audio track, fit inside the tool's documented size, duration, and dimension limits, and produce a WebM file with an Opus audio track that your downstream player accepts. A "correct" conversion is not just one that finishes without an error message; it is one whose output container, codec, duration, and silence profile match the job you actually wanted to do. Many failed or partially failed runs come from mismatches between the file extension and the codec inside, silent videos that pass a size check, or downstream players that don't read the output format. The Video to Audio Converter in your browser plays the local file in real time, captures its audio with the MediaRecorder API, and packages that audio into an Opus WebM file. Knowing how the tool records, what it will refuse, and what the resulting file actually contains is what makes the result verifiable rather than guessable.
What "Correct" Means in a Video to Audio Conversion
Correctness here has four parts: the source has audible content, the tool actually extracts that content, the file you save opens and plays to its full timeline, and the output format fits what your next step expects. If any of those four is off, the conversion is "wrong" in a way that matters, even if no error message appears.
The audio-track check is the most common silent failure. A clip that has been edited, re-exported, or downloaded with its sound stripped can still look like a normal video, and the tool will surface an explicit failure rather than producing a silent WebM. According to the product contract, a video with no audio track fails explicitly instead of generating a silent file, which is the behavior you want for verification: a clear stop beats a hidden zero.
The format check is the second most common silent failure. A filename that ends in .mp4, .mov, or .m4v only identifies the container; the codec inside the container still has to be one your browser can decode. The product documentation states that "a filename or MIME type only identifies a possible container; the browser must still support the codecs inside it." If decoding fails, the tool stops with a visible message instead of producing a broken file.
Why a Video to Audio Conversion Can Fail
The tool fails loudly in six documented cases: a video with no audio track, unsupported recorders, empty output, invalid duration, excessive dimensions, and canceled work. Each of these is paired with a visible message rather than a corrupt download. Two of the six are worth flagging up front because they map to the most common user errors.
A video with no audio track fails explicitly. This protects you from saving a 0-byte or silent Opus WebM and then wondering why the timeline reads zero. When this happens, the message tells you the source had no decodable audio, and you can re-export the source with audio before trying again.
A file with dimensions above the gate fails too. The tool's contract defines the gate as "no larger than 4096 pixels on either side, and no greater than 3840 × 2160 pixels in total area." A 4K vertical clip at 2160 × 4096 sits inside the 4096-per-side cap only when the longer side is at most 4096 and the total pixel count is within bound; an 8K master or a large square at 4000 × 4000 can violate the total-area rule even if each side is under 4096. Knowing this prevents the surprise of a refusal on a file that "should fit."
Container and codec mismatches are a third failure path. A .mov file with an exotic audio codec, or a .webm file recorded with a video codec your browser cannot decode, will be refused. The extension is necessary but not sufficient.
Browser support is the fourth. Safari and some other browsers may not expose captureStream or a compatible MediaRecorder format, which is a tool requirement, not a file requirement. Switching to a current Chromium-based or Firefox browser usually resolves this.
Run the Conversion Step by Step
The verified procedure has three operator steps and one browser-side step that runs in the background while the tab stays open. Follow them in order.
- Choose one supported local video with an audio track. Pick an MP4, WebM, MOV, M4V, or Ogg file up to 500 MiB whose decoded video is no longer than five minutes, no larger than 4096 pixels on either side, and no greater than 3840 × 2160 pixels in total area.
- Select Extract audio and keep the tab open while the video is processed in real time. The browser plays the file from start to end while MediaRecorder captures the audio track; a one-minute video normally takes about one minute to process.
- Check the duration and file size, then download the Opus WebM audio file. The tool patches the WebM container with the measured duration so compatible players can show a finite timeline.
The "keep the tab open" instruction is the most important part of step 2. The capture happens during playback, and switching tabs, closing the window, or navigating away interrupts the recording stream. A progress label follows playback time, and Cancel is available if you need to stop the current job.
File Limits That Gate the Tool
Every limit in the contract is there to bound memory, playback time, and browser resource use, and each one can independently stop the conversion. The list below mirrors the verified contract and is the right thing to check before clicking Extract.
| Limit | Maximum |
|---|---|
| Source file size | 500 MiB |
| Decoded video duration | 5 minutes |
| Larger side dimension | 4096 px |
| Total pixel area | 3840 × 2160 |
| Accepted extensions | MP4, WebM, MOV, M4V, Ogg |
| Output container | WebM |
| Output audio codec | Opus at 128 kbps |
If a file sits outside any single row of this table, the tool will stop with a visible message rather than guess. A separate question is whether the codec inside the accepted extension is supported; the contract states explicitly that a filename or MIME type only identifies a possible container, and the browser must still support the codecs inside it.
For files that exceed the duration or the dimension gates, a desktop audio editor with its own export settings is the right next step. The tool is built around a bounded, local browser path; it does not promise format support that the current browser cannot provide, and it does not bypass DRM, platform access controls, protected streams, remote URLs, or copyright restrictions.
What the Output Actually Is
The download is a WebM container with an Opus audio track at 128 kbps, not an MP3, WAV, AAC, or FLAC file, and not a lossless copy of the original compressed audio packets. This is one of the most common points of confusion: a "correct" conversion here means accepting that the output is Opus in WebM, and confirming that the downstream player or editor reads that format.
The reason is implementation-driven. The tool uses the browser's built-in MediaRecorder and the first supported Opus WebM MIME type it finds. MP3 encoding would require a separate codec dependency, which the tool deliberately avoids to stay small and fully local. Re-encoding may change quality and file size relative to the original, so an Opus WebM is not byte-for-byte equivalent to a "demuxed" copy of the source audio even when the source audio was also Opus.
A useful secondary check is to confirm the output is recognizable: open it in a current browser or in a player such as VLC, which reads Opus in WebM, and confirm that the duration matches the original video's duration rather than zero. The MediaRecorder interface MDN documentation describes the same recording path the tool uses, with the output MIME type negotiated from the formats the browser supports.
Confirming the Result After It Downloads
The product contract is explicit that "the generated WebM container is patched with the known media duration so downloaded files can report a finite timeline in compatible players." That is the verification step you should actually run, and there are three concrete checks worth doing on the saved file.
First, confirm the duration. Open the file in a compatible player and check that the timeline matches the source video. A zero or near-zero duration means the duration patch did not take, which usually means a player that predates the patch format is in use.
Second, confirm the audio actually plays. Play the file from start to end and listen for the same content as the source. A silent file in a player that reports a duration is the signature of a no-audio-track source that the tool refused earlier; if you reach this step, the source had audio and the recording caught it.
Third, confirm the file size is non-zero and matches the rough order of magnitude you'd expect. At 128 kbps, a one-minute Opus WebM is roughly 1 MB, give or take container overhead, and a five-minute file is roughly 5 MB. A file that is dramatically smaller than that is a red flag worth re-checking; a file that is dramatically larger is unusual but not necessarily wrong because variable-bitrate encoding can push above the nominal bitrate during complex passages.
For a deeper walk-through of the post-conversion check, the result verification guide for video to audio conversions covers opening the Opus WebM, scrubbing the timeline, and reading the file properties to confirm the recording actually captured what the source video carried.
For a deeper look, see Repeat a Video to Audio Conversion on Local Files.