Convert Files to AU Online for Free

Create a Sun/NeXT AU file only after decoding the source and choosing an AU encoding the receiver supports.

TO
  1. Add a file Choose or drop it here
  2. Pick the format Change it whenever needed
  3. Download the result After conversion completes

Convert Files to AU by Choosing the Destination Encoding Before Writing

Convert files to AU when a Sun, NeXT, legacy workstation, emulator, or specialised tool requires the .au sound format. “Any to AU” is not a promise that arbitrary source bytes can be wrapped unchanged in an AU extension. The source must first be detected and decoded; only then can a converter select an AU encoding, sample rate, and channel layout that the receiver accepts. A compressed source such as MP3, AMR, AAC, or WMA needs decoding, while PCM source data still needs representation and byte-order checks.

AU is a container with an encoding field. It may store mu-law, A-law, linear PCM at several widths, floating point, or less common values. Select a conservative format from the target's documented support rather than assuming every AU reader understands every encoding ID. Preserve the original source: turning a lossy recording into PCM AU improves editability but cannot restore earlier losses.


A Valid AU Starts With .snd and Six Big-Endian Header Words

A modern Sun/NeXT AU header has six 32-bit big-endian words: the .snd magic, data offset, data size, encoding, sample rate, and channels. The fixed header is 24 bytes. The data offset can be greater than 24 because an optional description field may be stored before the payload. A writer must calculate that offset and the available payload correctly; an AU reader uses it to decide where audio begins.

All numeric header values are big-endian, and multibyte AU audio is commonly big-endian too. This differs from a standard PCM WAV's RIFF fields and sample convention. A source-to-AU conversion therefore normally writes a new header and may need to change the byte order of decoded PCM samples. Copying a WAV file's header or little-endian sample bytes directly into AU produces an invalid or noisy result.


AU Encoding IDs Determine the Required Conversion Path

Common AU values include 1 for 8-bit G.711 mu-law, 2 for 8-bit linear PCM, 3 for 16-bit linear PCM, 4 for 24-bit linear PCM, 5 for 32-bit linear PCM, 6 for 32-bit IEEE float, 7 for 64-bit IEEE float, and 27 for 8-bit G.711 A-law. The number must truthfully describe the bytes written. A destination declaring 16-bit linear PCM cannot contain an MP3 stream, float data, or mu-law bytes.

Destination choiceWhen it fitsRequired verification
mu-law, ID 1Legacy telephony-oriented AU receiver.Companding intentionally applied.
16-bit PCM, ID 3Conservative editing/playback workflow.Big-endian sample bytes.
24/32-bit PCMReceiver explicitly supports the depth.Correct byte width and size.
Float, ID 6/7Known float-capable receiver.Numeric representation matches ID.
A-law, ID 27Specific G.711 delivery requirement.Do not call it lossless.
Unknown requirementNo destination documentation available.Test a small 16-bit PCM AU first.

Decode Source Codecs Before AU Packaging Rather Than Guessing a Remux

A compressed source must be decoded into samples before it can become linear PCM AU or another AU coding. A lossless source may preserve decoded sample values, while a lossy source does not regain removed detail. Containerised inputs add another boundary: a media file may contain more than one stream, and an audio track must be selected and decoded before AU settings can be applied.

Even an uncompressed source may need conversion. WAV PCM is little-endian; conventional AU linear PCM is big-endian. AIFF and AU both use big-endian conventions but have different headers and metadata structures. Never infer safe remuxing from the word “PCM” alone: check integer versus float representation, width, rate, channels, and byte order.


Set AU Rate and Channel Layout for the Receiving System

Preserve rate and channels when the receiver accepts them. Resampling is a deliberate signal-processing step, not an upgrade; it creates new samples at the requested rate. Changing mono to stereo by duplication adds no spatial information, and a multichannel-to-stereo conversion needs an explicit downmix policy. The AU header's rate and channel fields must agree with the sound payload and selected encoding.

For linear PCM, expected data size is duration times sample rate times channels times bytes per sample. Compare that estimate with the written payload. A mismatch may expose a header error, wrong offset, unexpected source duration, or truncated conversion. For mu-law or A-law, use the chosen companded representation rather than a PCM width assumption.


Keep Description Data and Source Provenance Outside Assumed AU Mappings

The AU area between byte 24 and the data offset may contain description information, but not every source tag maps there or is read by every player. Decide what must survive: title, original filename, date, case reference, cues, or project notes. Keep an external manifest when those data matter, and test output in the intended target rather than treating a successful local preview as a preservation guarantee.

For batch work, retain source checksum, detected codec/container, selected AU encoding ID, rate, channels, output data size, and receiver result. This creates a recovery path if later testing requires a different AU mode. Regenerate from the original source instead of transcoding a previous lossy AU output.


Check an AU Delivery at Header, Audio, and Receiver Boundaries

Can every file be converted to AU without decoding?
No. Codec and container inputs need a capable decoder; then the AU encoding must be selected and written truthfully.

Why does an AU output sound like static?
Check encoding ID, data offset, sample width, and big-endian order. PCM bytes in the wrong order commonly sound wrong.

What is the minimum AU header size?
Twenty-four bytes, but audio can begin later when a description field is present.

Does converting lossy audio to PCM AU improve it?
No. PCM AU can avoid new losses afterward but cannot restore details absent from the source codec.

What proves an AU is ready?
Inspect .snd, offset, encoding, rate, channels, and data size, then test beginning, middle, and end in the actual receiver.

A robust source-to-AU workflow detects and decodes the input first, writes a truthful big-endian AU header and payload second, then verifies technical fields and audible landmarks in the real destination. This separates source support from AU packaging and target compatibility, avoiding the common mistake of treating a legacy extension as a simple file rename.

Before generating a large collection, inspect one source from each real codec and container group. Note whether it decodes to integer PCM, floating-point audio, or an inherently lossy speech representation. Write a small AU test using the exact rate, channels, and encoding ID planned for delivery. Check its header fields with a format-aware inspector, then open it with the actual legacy application. A player that merely plays generic AU files may still reject a 24-bit, float, or non-default sample rate.

If a receiver requires 8-bit mu-law, apply companding only after decoding the source and clearly label the output as a compatibility derivative. If it accepts 16-bit linear PCM, that is often a more straightforward editing destination, but it still needs big-endian sample bytes. Match the target's documented expectation, not a filename convention. When the required AU encoding is unknown, do not guess from the source type; obtain a representative accepted file or test a controlled sample first.

Audit failure symptoms separately. A file rejected immediately can have an invalid magic, offset, header size, or unsupported encoding. A file that plays noise can have correct structural fields but wrong sample byte order or a false encoding declaration. A file that ends early can have a data-size mismatch, truncated source decode, or a channel/rate calculation error. These observations are more useful than performing repeated blind conversions, because each identifies the boundary that needs correction.

For future recovery, retain source and output checksums, the source codec report, output AU encoding number, description-field choice, byte size, and target test result. If output settings later change, regenerate once from the retained source. This avoids companding, resampling, or lossy encoding a compatibility derivative for a second time and makes the final AU's limitations explicit to the next user.

Header arithmetic deserves a final inspection. The data offset must include the fixed 24-byte header plus any description bytes, and it must point to the first actual sample. For PCM AU, compute expected payload bytes from the chosen rate, channel count, duration, and bytes per sample before writing the data-size field. If the source contains frames from a compressed codec, calculate the output against decoded samples rather than the compressed file length. A write that succeeds with an offset beyond the file end or a data size that cuts off the last samples is structurally wrong even if one forgiving player emits sound.

Target support should drive the final choice between mu-law, linear PCM, and float. Mu-law and A-law are companded G.711 forms intended for specific compatibility cases; their eight-bit code values are not raw linear amplitudes. Float AU can preserve a floating-point decoded mix only if the target documents it. Linear PCM is often broadly understandable, but 16-bit, 24-bit, and 32-bit are different payload widths. State that selection alongside the source conversion because a later editor cannot reliably infer why a particular AU was made from the filename alone.