Initializing... drag & drop files here
Supports: AAC
This decodes lossy AAC audio into AIFF, the uncompressed big-endian PCM format Apple built in 1988 and still the natural uncompressed container on macOS. One honesty note first: AAC is lossy, so the AIFF will not sound better than the AAC. It is a faithful, much larger PCM copy of the same decoded audio, and the detail the AAC encoder threw away does not come back. The reason to do this is workflow — a stable uncompressed file to edit, sample, or feed to gear that will not read raw AAC.
.aac files onto the page or click "+ Add Files" to browse. Queue several and they all convert with the same settings.| Property | AAC | AIFF |
|---|---|---|
| Compression | Lossy, MDCT-based | None — uncompressed linear PCM |
| Standardized as | ISO/IEC 13818-7 (MPEG-2 Part 7) and ISO/IEC 14496-3 (MPEG-4 Part 3) | Apple's Audio Interchange File Format, 1988 |
| Built on | MPEG bitstream, commonly wrapped as a raw ADTS stream in a .aac file |
Electronic Arts' IFF chunk format, from the Amiga |
| Byte order | Not applicable to the coded bitstream | Big-endian (WAV is the little-endian equivalent) |
| Typical size | Roughly 1 MB per minute at 128 kbit/s | About 10 MB per minute at 44.1 kHz, 16-bit, stereo |
| Audio quality after this conversion | The reference — whatever the encoder kept | Bit-identical to the decoded AAC; no fidelity regained |
| Editing behaviour | Every save risks another lossy generation | Edit, cut, and fade repeatedly with no further loss |
| Best for | Storage, streaming, listening copies | Uncompressed editing input, samplers, mastering chains |
| Property | Value |
|---|---|
| Developed by | Apple, 1988; the AIFF-C compressed variant followed in 1991 |
| Derived from | Electronic Arts' Interchange File Format (IFF) |
| Payload we write by default | Linear PCM, 16-bit big-endian |
| Byte order | Big-endian in classic AIFF |
| Notable variant | AIFF-C with the sowt codec, which is little-endian PCM with no actual compression — Apple uses it on macOS while still labelling files "AIFF" |
| Size at CD quality | About 10 MB per minute of 44.1 kHz 16-bit stereo |
| Metadata | Name, Author, Comment, Annotation, and Copyright chunks; ID3v2 and XMP can ride in Application chunks |
| Best for | macOS audio work, hardware samplers, uncompressed masters |
No, and it is worth being blunt about it. AAC is a lossy codec: the encoder analysed the signal and permanently discarded the parts it judged least audible in order to shrink the file. Decoding to uncompressed AIFF reconstructs the waveform as far as the decoder can, but the discarded information is not stored anywhere, so no format conversion can bring it back. The AIFF sounds like the AAC and takes roughly ten times the space.
For workflow, not fidelity. Hardware samplers, drum machines, and older studio gear frequently read AIFF and WAV but have no AAC decoder. Decoding once to PCM also gives you a stable working file: you can cut, fade, and process it repeatedly without a fresh lossy re-encode on every save, which is exactly the compounding-loss problem that editing a lossy file directly creates.
Because AIFF stores every sample uncompressed while AAC compresses aggressively, and PCM size is fixed arithmetic rather than content-dependent. Uncompressed 44.1 kHz 16-bit stereo runs at 1,411.2 kbit/s, roughly 10 MB per minute, so a four-minute track lands near 40 MB regardless of how small the source was. A 128 kbit/s AAC of the same track is about 1 MB per minute. The extra bytes are padding out the PCM, not added detail.
They are close cousins and the audio is identical: both are uncompressed linear PCM, both at the same rate and depth produce the same file size. AIFF is big-endian and descends from Electronic Arts' IFF; WAV is little-endian and descends from Microsoft's RIFF. AIFF is the more natural fit on macOS and in Apple's own apps, while WAV is the safer cross-platform default. If WAV suits you better, use AAC to WAV instead.
16-bit linear PCM in big-endian order, which is classic AIFF and what every AIFF-capable editor and sampler expects. That matches the audio-CD standard and is ample for a source that was already a lossy stream — a deeper output would only add zeros, not resolution. Leaving Audio Sample Rate on ORIGINAL keeps the source rate, commonly 44.1 kHz or 48 kHz for music AAC.
That is AIFF-C using the sowt codec: a pseudo-compressed variant that stores plain PCM in little-endian order without actually compressing anything. Apple adopted it as the standard on macOS while still labelling the files simply "AIFF", which is why byte order sometimes appears to contradict the format's own definition. Both variants carry identical audio; classic big-endian AIFF is the more broadly compatible of the two, especially with older samplers.
Not reliably. AIFF can hold metadata in Name, Author, Comment, Annotation, and Copyright chunks, and ID3v2 or XMP data can be carried in Application chunks, but the mapping from MPEG-4 metadata atoms into those chunks is not standardised and many players ignore AIFF tags entirely. Treat the AIFF as an audio working file and keep the tagged AAC if the library metadata matters.
Re-encoding to AAC is a lossy step, so it adds its own generation of loss on top of the original encode — the AIFF is a clean PCM source, but it is a PCM source built from already-lossy audio. If you only need the small file again and never edited the audio, the original AAC is the better copy to keep. When you have genuinely edited the PCM, AIFF to AAC re-encodes the result.
Use FLAC. It stores the decoded PCM losslessly while compressing it, typically to a fraction of the uncompressed size, so it is the better choice for archiving a decoded library. Run AAC to FLAC instead — with the same caveat that a lossless container around a lossy source preserves exactly what the AAC held, no more.
Files upload over an encrypted connection, are processed on our servers, and are deleted automatically after a few hours — no sign-up, no watermark, never shared or made public. Because AIFF output is many times the size of the AAC input, the download is usually the slowest part of the round trip.