Initializing... drag & drop files here
Supports: XVID
Xvid is an open-source MPEG-4 Part 2 (Advanced Simple Profile) video codec, first released in 2001 and almost always wrapped in an AVI container alongside an MP3, AC-3, or AAC audio track. AU is a much older container: Sun Microsystems introduced it for Unix workstations, NeXT adopted it, and it became the default audio format for early Web pages and Java applets. The reason to extract Xvid audio specifically to AU is interoperability with software that still expects the .snd magic-number header rather than RIFF (WAV) or MP4.
javax.sound.sampled reads many formats, but .au remains the safest bet for legacy applets, JNLP demos, and university coursework that still ships from Sun's old reference packages.audiotool, audioplay, and SunOS desktop sound services natively read AU. If you're maintaining a museum-grade Solaris box or a NetBSD audio pipeline, AU avoids the pkgsrc gymnastics of installing a modern decoder.auread/auwrite work with AU more reliably than newer formats. Researchers digitising Xvid lecture recordings often archive the audio as AU for long-term reproducibility.| Property | Xvid (in AVI) | AU |
|---|---|---|
| Type | Video codec in AVI container | Audio container |
| Origin | Xvid project, 2001 (GPL) | Sun Microsystems, late 1980s |
| Codec / encoding | MPEG-4 ASP video + MP3/AC-3/AAC audio | μ-law, A-law, linear PCM 8/16/24/32-bit, ADPCM |
| Magic header | RIFF....AVI |
.snd (0x2E736E64) |
| Default sample rate | Inherited from source audio (often 44.1/48 kHz) | 8000 Hz historically; any rate supported |
| Typical use | DVD/DVR rips, late-2000s anime fansubs | Unix sound, Java applets, telephony prompts |
| Browser playback | None natively; needs VLC or codec pack | Safari historically; otherwise transcode |
| Active development | Stable since v1.3.7 (Dec 2019) | Specification frozen; still readable everywhere |
| Use case | Audio Channel | Sample Rate | Encoding intent |
|---|---|---|---|
| Asterisk / IVR prompt | Mono | 8000 Hz | μ-law (G.711) — drop straight into dial-plan |
| Java 1.1 applet audio | Mono | 8000 Hz | 8-bit μ-law — maximum legacy compatibility |
| Spoken-word archive | Mono | 22050 Hz | Linear PCM — clearer voice without doubling size |
| Bioacoustic / lecture rip | Mono | 44100 Hz | Linear PCM 16-bit — research-grade fidelity |
| Music extract for Unix | Stereo | 44100 Hz | Linear PCM 16-bit — CD-equivalent |
| Studio master | Stereo | 48000 Hz | Linear PCM — match the source video track |
If your source AVI carries MP3 or AC-3 audio and you transcode to linear-PCM AU, the AU is uncompressed and will land roughly 8-10x bigger for the same duration. To shrink it, pick a Constant Bitrate preset (64-128 kbps) so the encoder uses a compressed AU profile, or drop the sample rate to 22050 Hz mono if the content is voice. Telephony-grade 8 kHz μ-law AU is actually smaller than 128 kbps MP3.
Pick μ-law at 8 kHz only if the consumer is telephony, an IVR, or a Java 1.1 applet — those systems literally cannot play anything else, and the format is locked to that envelope by G.711. For everything else (Unix workstations, modern Java, audio archives, Praat/MATLAB), 44.1 kHz linear PCM is a better default: it preserves voice clarity and music transients, and every AU decoder written since the late 1990s reads it.
Almost always, yes. Xvid is an MPEG-4 ASP video codec, not a container — the bitstream needs a wrapper. AVI was the dominant choice during Xvid's heyday (2003-2010) for compatibility with DivX hardware players. You'll occasionally see Xvid in MKV or MP4, but if your file ends in .xvid or .avi, this converter accepts it and pulls the audio track out for transcoding.
Yes — open the Trim section, enter a start time and duration (HH:MM:SS.mmm). Only the trimmed range is decoded and re-encoded, which is significantly faster than converting the full clip and editing afterwards. This is especially handy when you only need a 10-second voice line from a 45-minute Xvid lecture.
Native browser support for AU has effectively disappeared. Safari historically played AU via QuickTime, but no current browser ships an AU decoder by default. If you need browser playback, convert to WAV or MP3 instead — see Xvid to MP3 or Xvid to WAV. AU is the right choice when the consumer is server-side software, a desktop audio tool, or a legacy Java/Unix environment.
8 kHz sampling has a Nyquist limit of 4 kHz, so anything above that — sibilants, music harmonics, room ambience — gets filtered out. That's by design for telephony (G.711 was tuned for the 300-3400 Hz voice band). If the muffling is unacceptable, raise the Audio Sample Rate to at least 22050 Hz; the file gets larger but the high frequencies return.
The AU container supports μ-law, A-law, linear PCM, and ADPCM encodings per Sun's spec. The default for compressed AU output here is μ-law (the North American / Japanese telephony standard). If your downstream system requires A-law (the European E1 standard), check the encoding the receiver expects — for purely European telephony pipelines, you may need to post-process with ffmpeg -acodec pcm_alaw to switch the codec field after this conversion.
Yes. Add multiple files via the "+ Add Files" button or drag-and-drop a batch. Each file converts with the same Audio Channel, Sample Rate, and File Compression settings you pick — useful for converting a folder of training videos into a uniform set of IVR prompts. Each file processes independently in your browser, so a slow one won't block the rest.
Both are old uncompressed-audio containers, but AIFF (Apple/SGI, 1988) uses big-endian linear PCM and was tied to early Macs and IRIX, while AU (Sun, late 1980s) supports μ-law / A-law / PCM and dominated Unix workstations and early Java. If your target platform is macOS or audio-production software, prefer AIFF; if it's Solaris, NetBSD, IVR, or Java legacy, prefer AU.