Initializing... drag & drop files here
Supports: CAVS
This page extracts the audio track from a .cavs file and writes it as uncompressed PCM in an Audio Interchange container. Before you queue anything, there is one fact about .cavs that decides whether the conversion can work at all, and it is better stated up front than discovered halfway through: a genuine .cavs file is a raw video elementary stream and carries no audio track.
CAVS is the Chinese AVS video codec — AVS1-P2, Jizhun profile, standardised as GB/T 20090.2 and enacted in March 2006. The .cavs extension names the bare coded video bitstream, the AVS equivalent of a naked .h264 or .hevc file. There is no container around it, so there are no other streams inside it: no audio, no subtitles, usually not even a reliable duration. Extraction from a file like that has nothing to find, and the job fails rather than producing a silent file.
.cavs is a raw AVS bitstream — the usual case for files pulled from an encoder, a reference decoder or a broadcast capture chain — there is no audio inside it and this conversion cannot succeed. If the file was renamed from a transport stream or another container that happens to hold AVS video, it may well have an audio track, and everything below applies normally.This is not a limitation of the converter — it is what the format is. FFmpeg, which does the demuxing here, registers cavsvideo as "raw Chinese AVS (Audio Video Standard) video" and registers the cavs codec as decode-only. A raw video elementary stream is a sequence of coded pictures and nothing else.
When an audio target is requested from a source with no audio stream, the encoder has nothing to map, and the job stops with an error to that effect instead of writing an empty file. We reproduced exactly that against a video-only source through the same PCM-into-Audio-Interchange path this page uses: no output file was produced at all.
If your AVS video came out of a broadcast or DVB-style capture, the sound almost certainly still exists — it is in the transport stream the video was carved out of, alongside the video, usually as MP2 or AAC. Convert that file rather than the extracted elementary stream. If all you have is the .cavs, the audio is genuinely not in it, and no tool can recover what was never stored.
| Property | Value |
|---|---|
| Full name | Audio Video Coding Standard, Part 2: Video — AVS1-P2 |
| Standard | GB/T 20090.2, approved by the Standardization Administration of China, in force from March 2006 |
| Profile in general use | Jizhun, the baseline profile aimed at standard-definition and high-definition broadcast |
What the .cavs extension names |
The raw coded video bitstream, with no container around it |
Streams a .cavs file can hold |
Video only |
| Later generations | AVS+ , then AVS2 (also IEEE 1857.4) and AVS3 (IEEE 1857.10) — separate codecs, not .cavs |
| Tool support | FFmpeg decodes AVS1-P2 but has no AVS1 encoder, so these files are read-only in most open tooling |
| Where the files come from | Chinese digital television, IPTV and surveillance equipment, plus encoder and reference-decoder tooling |
.aifc names Apple's AIFF-C, the 1991 revision of the 1988 Audio Interchange File Format that added a compression-type field so the container could hold something other than plain big-endian PCM. Both variants use the same IFF-style FORM wrapper, and the four bytes right after the length field say which one you actually have. Those bytes are set by the codec you pick, not by the filename:
| Audio Codec setting | Bytes 8–11 of the file | Structure written | Data size versus 16-bit PCM |
|---|---|---|---|
| PCM 16-bit Big Endian (default) | AIFF |
Classic AIFF, COMM chunk, no FVER |
Baseline |
| PCM 16-bit Little Endian | AIFC |
AIFF-C, FVER version chunk present |
Same |
| PCM A-law | AIFC |
AIFF-C, FVER version chunk present |
Half |
| PCM mu-law | AIFC |
AIFF-C, FVER version chunk present |
Half |
We verified this by encoding one 44.1 kHz stereo test tone four times, once per codec, and reading the header bytes back. The practical takeaway is counter-intuitive: leaving the default alone gives you a file named .aifc that is structurally a plain AIFF. Every reader that handles AIFF at all will open it, so this is safe rather than broken — but if something downstream specifically checks for the AIFC form type, choose one of the other three codecs.
A-law and mu-law are the telephony companding schemes, packing each sample into 8 bits instead of 16. They halve the file at an audible cost and are a reasonable pick for speech destined for a legacy voice system; they are the wrong pick for music.
Almost certainly that the .cavs file is what it claims to be: a raw AVS video bitstream with no audio track in it. The extraction step finds no audio to work with, so the encoder has nothing to write and the job stops. That is the expected outcome for a genuine elementary stream, not a fault in the file or the converter. The fix is to convert the original container the video was extracted from, not the extracted stream.
AVS is China's home-grown video coding standard, developed by the Audio Video Coding Standard Workgroup of China. AVS1-P2 — the version FFmpeg decodes, in its Jizhun profile — was approved as the national standard GB/T 20090.2 and took effect in March 2006, aiming for roughly H.264-class efficiency at lower decoding complexity. It was deployed in Chinese digital television and in some IPTV and surveillance equipment. .cavs files usually turn up as raw bitstreams dumped from that equipment or from encoder tooling, which is why they carry no container and no sound.
No, and it would not be useful if you could. This page extracts an existing audio track; it does not synthesise one. A silent audio file of matching duration is trivial to make in any audio editor if that is genuinely what a workflow needs, but it carries no information from the source.
For anything you care about, one of the 16-bit PCM options — they are lossless relative to whatever was decoded, and 16-bit big-endian is the historical native form of AIFF. Choose PCM 16-bit Little Endian only if the receiving tool specifically wants the byte order flipped, and expect an AIFF-C structure when you do. Choose A-law or mu-law only for speech going into telephony-shaped systems, since they discard resolution to halve the size.
It resamples. Selecting 48000 Hz on a 44.1 kHz source runs a real sample-rate conversion; the audio is not merely re-tagged. Leave it on Original unless something downstream requires a specific rate, because every resampling step is an extra approximation. Note the list is deliberately short — 8000, 12000, 16000, 24000, 44100 and 48000 — so if you need something like 22050 Hz, do the conversion in an editor instead.
You can queue several files, and they all convert with the same codec, channel, sample-rate and trim settings. That is genuinely useful when the settings should be identical across a batch. It does not change the underlying issue on this route, though: if the files are raw AVS bitstreams, every one of them fails for the same reason.
For lossless PCM, yes — it is uncompressed, well documented, and read by essentially every audio tool including Apple's own. The caveat is size: uncompressed 16-bit stereo at 44.1 kHz runs about 10 MB per minute, which adds up fast. If archival compactness matters more than universal readability, FLAC stores the same samples losslessly at roughly half the size. If you need the AIFF family specifically, keep the default 16-bit PCM and accept the size.
The uploaded file travels over an encrypted connection, is processed on our servers, and both the upload and any output are deleted automatically after a few hours. There is no account to create, no watermark, and files are never shared or made public. If you want to take only a section of a long recording, the Trim control does it during the conversion, so you do not have to cut the file first.