Convert WAV to AIFF

WAV is Microsoft’s RIFF format and stores its multi-byte numbers little-endian, lowest byte first. AIFF is Apple’s IFF format and stores them big-endian, highest byte first. Both wrap uncompressed PCM audio and both describe it with a chunk holding the channel count, the sample rate and the bit depth. Everything else about them is the same idea expressed by two companies who were not talking to each other in the late 1980s.

So this conversion is arithmetic rather than encoding. Each sample is written out with its bytes in the opposite order and a new header is built around the result. Nothing is analysed and nothing is judged. A 16-bit source therefore comes out the same length as it went in, to within a few dozen bytes of header; a 24-bit one comes out at two thirds the size, because the samples are rewritten at 16 bits.

AIFF dates from 1988 and became the uncompressed format Mac audio software assumed. Logic Pro, the sampler formats that preceded it, Sound Designer, and the CD-authoring tools that produced Red Book discs all treated AIFF as the native thing and WAV as the import. Studios wrote house standards around that and the standards outlived the reason.

Today the requirement almost never comes from the application. Current Logic opens a WAV without comment. It comes from a template somebody set up years ago, a delivery specification, a hardware sampler that only ever learned one format, or a library or mastering house that asked for AIFF on the order form. That is a real requirement even when it is not a technical one, and satisfying it is what this page is for.

AIFF stores its sample rate in a type no current language has: an 80-bit IEEE 754 extended float, with a sign bit, a 15-bit exponent biased by 16,383, and a 64-bit significand whose leading bit is written out explicitly rather than implied. It is the single reason most people reach for a library to produce an AIFF at all.

It is also the reason this conversion needs no extra download. The sample rates that actually occur — 44,100, 48,000, 8,000 — are represented exactly by that encoding, so the header can be assembled with a few lines of arithmetic instead of a codec. The audio itself never passes through a compressor in either direction.

There is a single genuine incompatibility between the two formats below the byte-order level, and it catches people writing their own converters. WAV stores 8-bit samples as unsigned values from 0 to 255; AIFF stores them signed, from −128 to 127. A single byte has no order to reverse, so copying it across unchanged looks correct and produces loud static.

Handled here by shifting the values rather than the bytes. It matters for old game audio, telephony captures and archived 8-bit material, and for nothing else — every recording made this century is 16-bit or deeper and the question never arises.

The PCM written here is 16 bits per sample. If your WAV was 16-bit — CD rips, most exports, most recorders in their default mode — the conversion changes nothing at all about the audio. If it was 24-bit, those extra eight bits per sample are not carried through, and you should know that before it becomes a surprise in a session.

For a delivery file destined for a CD, a sampler or a library submission, 16-bit is the target anyway and this is the correct output. For a working master in a 24-bit session, convert to FLAC instead — it keeps the depth the source had, compresses to about half the size, and Logic and every other current DAW reads it.

A WAV is a container of chunks and only one of them is the audio. Recorders and editors write others: an INFO block with a title or a date, cue points and region markers, and in broadcast and post-production a Broadcast Wave chunk carrying the timecode that lets a file be dropped back onto a timeline at the right frame.

The conversion rebuilds the container around the samples, so none of that survives. For music and general audio it is nothing to worry about; for post-production it can be the most valuable thing in the file. If a WAV carries timecode you rely on, keep it and treat the AIFF as an additional deliverable rather than a replacement.

There are two files with this extension in circulation. Plain AIFF is uncompressed, which is what everything means by AIFF and what this page produces. AIFF-C, sometimes seen as .aifc, is a later variant that allows compressed data inside the same structure, and its contents can be anything from mildly compressed to a codec the receiving program has never heard of.

The distinction is why an AIFF is a safe delivery format and an AIFF-C is not. When a specification says AIFF it means the uncompressed one, and a file that opens in one program and fails in another is usually AIFF-C in disguise. Nothing here will produce one.

Where nothing forces the decision, the tiebreakers are practical rather than technical. WAV has broader support outside the Mac world, and anything you might hand to Windows software, a web tool or a transcription service will take it first. AIFF has slightly better metadata conventions in Apple software, and it is what a Mac-centred studio expects to receive.

Neither has an audio advantage, so a workflow that is entirely inside Logic can reasonably standardise on AIFF and one that crosses platforms should standardise on WAV. What is not worth doing is converting back and forth repeatedly to keep both — the files are identical in content and each copy is another 10 MB a minute.

Drop up to a hundred WAVs and each becomes its own AIFF, returned together as a ZIP. The conversion is byte manipulation rather than encoding, so a batch of stems finishes quickly and the browser is doing arithmetic rather than analysis.

The per-file ceiling is 100 MB, which uncompressed works out at a little under ten minutes of stereo. Stems, takes and songs sit comfortably inside it; a full concert recording or a long interview does not, and those need splitting in an editor first or converting with a desktop tool.