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 | 16-bit big-endian linear PCM (the AU muxer default, lossless) |
| Best for | Legacy Unix/NeXT tooling and old Java audio code |
The .au most people picture is 8-bit µ-law at 8 kHz — the lossy companded format SunOS exposed through /dev/audio. This converter does not down-convert to that by default; it writes 16-bit big-endian linear PCM into the AU container, which is the muxer's default and a lossless encoding. What you get out therefore depends on what was inside the AVI:
Either way, AU's linear PCM is uncompressed, so the .au is typically larger than the 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's linear PCM only makes a bigger file that sounds identical to the original. If the AVI's audio was already PCM, the AU is a lossless copy of it. In neither case do you regain quality the AVI didn't have.
No. The historic .au people remember from Sun workstations was 8-bit µ-law at 8000 Hz, which is lossy and telephone-grade. This converter writes 16-bit big-endian linear PCM by default — the AU container's lossless default — preserving full-bandwidth audio rather than companding it down to µ-law. If a specific legacy tool requires exactly 8-bit µ-law, this output will not match that encoding; you would need a tool that lets you force the µ-law codec.
Because AU's linear PCM is uncompressed. The audio inside an AVI is usually stored with a compressed codec like MP3 or AC-3, which is far smaller than raw PCM. When that track is written out as 16-bit PCM, every sample is stored in full, so the .au commonly grows several times larger than the compressed audio occupied in the AVI. The extra bytes are uncompressed 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 16-bit PCM this converter writes follows that. 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 16-bit/44.1 kHz audio produced an .au of roughly 10 MB, since CD-quality stereo PCM runs about 10 MB per minute regardless of how compact the audio was inside the original AVI.