AIFF, IFF and Apple’s 1988 answer to the sample file
AIFF is older than most people assume. Apple published it in 1988, three years before Microsoft and IBM defined WAV, and did not invent the structure from scratch: it borrowed Electronic Arts’ Interchange File Format, the chunked layout the Amiga world had standardised on. That heritage is visible if you ever open an AIFF in a hex editor, where the file opens with a FORM chunk containing a COMM chunk describing the audio and an SSND chunk holding the samples.
For thirty years it has been the uncompressed format on the Mac side of the fence. Logic Pro and GarageBand bounce to it, QuickTime writes it, sound-effect libraries built for Mac studios ship in it, and CD-ripping software written for classic Mac OS filled hard drives with it. If an AIFF has arrived in your files, a Mac almost certainly made it.
Being uncompressed means the audio is stored exactly as it was captured, with no perceptual coding anywhere in the chain, and it means the file is large. A three-minute stereo track at CD resolution occupies roughly 30 MB. That is fine while the file is a working master and awkward the moment it needs to be emailed, uploaded to a review portal, or carried on a phone.
Big-endian samples, sowt and the AIFF-C variant
Here is the genuine technical difference between AIFF and WAV, and it is one you will never notice. AIFF stores its sample values big-endian, most significant byte first, because it was designed for the Motorola 68000 processors in Macs of the period. WAV stores them little-endian for Intel’s benefit. The same audio, the same numbers, written in the opposite byte order.
Apple’s own move to Intel processors made that inconvenient, which is why so many Mac-authored files are actually AIFF-C using the sowt identifier: the word “twos”, as in two’s complement, spelled backwards, which is a joke about byte order that has now outlived several processor architectures. It means little-endian samples in an AIFF container.
None of this reaches you. FFmpeg reads the header, works out the byte order and the encoding, and hands the decoder a normalised signal. The reason it is worth knowing is that files described as AIFF-C sometimes alarm people into thinking they are compressed and lossy. Usually they are neither.
Turning an AIFF bounce into an MP3
- Drop your
.aiffor.aiffile onto the box above, or click Choose a file to pick it from your device. - Set the MP3 bitrate. It opens on 320 kbps (highest quality), the top of the three rungs offered here, so step down only when file size matters more than headroom.
- Click Convert AIFF to MP3. A progress bar with a Cancel button replaces the button while FFmpeg encodes.
- Download the MP3. It keeps your original name with the extension swapped, so
mix-v7.aiffcomes back asmix-v7.mp3.
The 320 kbps default from an uncompressed source
The ladder on this page runs 320, 256 and 192, and it opens on the highest rung. Coming from uncompressed audio the encoder has the full recording in front of it rather than what a previous encoder left behind, so the extra bits genuinely go somewhere. Read that as a reason to be generous rather than as a rule, because it is the ladder that decides where a page opens: the WAV converter is fed uncompressed audio too and opens on 192, from a lower ladder of 320, 192 and 128.
256 kbps (great quality, smaller) is the sensible step down when you are converting a lot of material or when the destination has limited storage. In a direct comparison it takes attention and decent headphones to separate it from 320. 192 kbps (smallest file) belongs to rough mixes, reference bounces, spoken word and demos, where the file is going to be listened to once on a phone speaker and then deleted.
Whichever rung you choose, it becomes a single bitrate argument to libmp3lame. Nothing else in the chain touches the audio: no normalisation, no filtering, no sample-rate games beyond what MP3 itself requires.
AIFF next to WAV, and which one you actually have
In everyday use the two formats are interchangeable, and the choice usually came down to which application wrote the file rather than to any decision you made. Both store linear PCM, both are bounded by 32-bit chunk size fields so neither suits a multi-gigabyte recording, and both are what an editor or a sampler wants to see.
AIFF does have one charming oddity: the sample rate in the COMM chunk is stored as an 80-bit extended-precision floating point number, a format from the Motorola maths coprocessors of the era that almost nothing else in computing still uses. It has caused decades of small bugs in third-party readers and never once mattered to a listener.
If the file you have is a WAV rather than an AIFF, WAV to MP3 handles it, though that page opens on 192 kbps from a 320, 192 and 128 ladder rather than the 320, 256 and 192 one here. Broader comparisons across the whole set live in the audio converter and editing tools guide.
Loop points, markers and the metadata left behind
AIFF carries structures MP3 has no place for. Marker chunks store named positions in the file, and instrument chunks store sustain and release loop points that hardware and software samplers read when they load a sound. Attached artwork, which FFmpeg surfaces as a video stream, is dropped by the -vn flag this converter passes before encoding.
So the MP3 is a listening copy and only that. Keep the AIFF whenever the file is a master, a sampler instrument or anything that will be edited again, and hand out the MP3. If the copy needs shortening after the fact, Cut MP3 trims it without a second encode, and the editing pages on the audio tools hub take the MP3 from there.