Initializing... drag & drop files here
Supports: AVI
This tool extracts the audio track from an AVI video and writes it into an .au file — the Sun Microsystems audio format (also seen as .snd) from the Unix-workstation and NeXT era. The video is discarded; only the sound is kept. AU is a niche target today, so be clear on why you'd want it: a legacy Unix tool, an old Java program, or a retro-computing or academic pipeline that specifically reads the Sun audio format. If you just want the audio to play or share normally, AVI to MP3 or AVI to WAV (the standard uncompressed-PCM choice) is almost always the better pick — AU offers no quality or size advantage over those.
| Property | Value |
|---|---|
| Full name | Audio Video Interleave |
| Origin | Microsoft, November 10, 1992 (Video for Windows) |
| Container | RIFF (Resource Interchange File Format), chunk-based |
| Typical audio inside | MP3, AC-3, or PCM (many other codecs allowed) |
| Holds | Interleaved video + audio streams |
| Role here | Source — the audio stream is extracted, video dropped |
| Property | Value |
|---|---|
| Origin | Sun Microsystems (Unix workstations); later common on NeXT |
| File signature | 0x2e736e64 — the ASCII characters .snd |
| Extensions | .au and .snd |
| Header | Six 32-bit words (24 bytes), network/big-endian byte order |
| Encodings the format allows | 8-bit µ-law (code 1), 8-bit A-law (code 27), linear PCM 8/16/32-bit (codes 2-5), plus float |
| Classic association | 8-bit µ-law at 8000 Hz mono (telephone-grade, lossy) — early Java's only sound format |
| Codec written here | 8-bit µ-law (PCM_MULAW) by default; A-law or 16-bit big-endian PCM (PCM_S16BE) selectable |
| Best for | Legacy Unix/NeXT tooling and old Java audio code |
The .au most people picture is 8-bit µ-law — the lossy companded format SunOS exposed through /dev/audio — and that is what this converter writes by default, at whatever sample rate and channel layout you choose. For full-fidelity output instead, select 16-bit big-endian linear PCM (PCM_S16BE) in the advanced options; 8-bit A-law is also available. What you get out therefore depends on the codec you pick and what was inside the AVI:
PCM_S16BE makes the transfer lossless — the samples land in the AU at full 16-bit precision; the default µ-law still compands them to 8 bits.Either way the AU stores a fixed number of bytes per sample (one for µ-law, two for 16-bit PCM), so the .au is typically larger than the compressed audio occupied inside the AVI. You are paying bytes for the container, not gaining fidelity.
.avi onto the page or click "+ Add Files". Several files can be queued and converted with the same settings.Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically a few hours after conversion — never shared or made public.
No. Converting cannot add detail that was never in the source. If your AVI carries MP3 or AC-3 audio — the usual case — that track was already lossy-compressed, and writing it into AU only makes a bigger file — the default 8-bit µ-law encoding is itself telephony-grade, so it can even shave a little more off. If the AVI's audio was already PCM, selecting 16-bit PCM (PCM_S16BE) in the advanced options makes the AU a lossless copy of it. In neither case do you regain quality the AVI didn't have.
Yes — that is the default. The historic .au people remember from Sun workstations was 8-bit µ-law at 8000 Hz, which is lossy and telephone-grade; this converter writes 8-bit µ-law by default at whatever sample rate and channel layout you choose, so for the strict classic profile also set 8000 Hz and Mono. If you would rather preserve full-bandwidth audio, select 16-bit big-endian linear PCM (PCM_S16BE) in the advanced options instead of companding down to µ-law.
Because AU stores every sample in full. The audio inside an AVI is usually a compressed codec like MP3 or AC-3; the default 8-bit µ-law AU spends one byte per sample per channel — about 5.3 MB per minute at 44.1 kHz stereo, several times a 128–192 kbps track — and selecting 16-bit PCM doubles that. The extra bytes are raw sample data, not added quality.
Only for compatibility with something that specifically expects .au. Early Java was the classic case: its original sound API supported exactly one format — 8-bit µ-law, 8000 Hz, mono, Sun .au files — so applet and desktop audio of that era shipped as AU. Other realistic cases are a legacy Unix or NeXT-lineage program that reads the Sun format natively, or an academic or retro-computing pipeline that documents .au as its interchange format. For listening, sharing, or editing, AVI to MP3 or AVI to WAV is the better choice.
Yes. The AU format stores its header and sample data in network (big-endian) byte order, and the optional 16-bit PCM output (PCM_S16BE) follows that; the default µ-law samples are single bytes, so byte order doesn't arise for them. It matters only if a downstream tool reads the raw bytes assuming little-endian — well-behaved players honor the header and handle it correctly. WAV, by contrast, is little-endian, which is one of the technical differences between the two containers even though both can carry the same PCM samples.
Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically a few hours after conversion — never shared, never made public, with no sign-up and no watermark. In our testing, a one-minute AVI with stereo 44.1 kHz audio produced an .au of roughly 5.3 MB with the default µ-law encoding (one byte per sample per channel), doubling to about 10 MB with 16-bit PCM selected.
Then there is nothing to extract, and the result is an empty or zero-length .au. Some AVI files are video-only, and a few carry more than one audio stream; the extractor takes the first audio stream it finds. If your output is silent, re-check that the source clip actually contains the audio you expect.
Yes. The Audio Sample Rate and Audio Channel controls both default to "Original," which copies the AVI track's native rate and layout into the .au. If a legacy reader expects a specific setup — classic Sun pipelines often assume 8000 Hz mono — change those dropdowns before converting. Downmixing to mono also roughly halves the size of the output, whichever encoding you pick.