Convert MP3 to AIFF

MP3 compression works by deleting parts of a recording that a model of human hearing says will not be missed. Those parts are not stored compactly somewhere in the file; they are gone. AIFF then does the opposite job perfectly — it stores every sample it is given, without compression, exactly as handed over.

Put together, the result is a large file containing precisely the audio the MP3 contained. That is a useful thing to have when something downstream demands uncompressed PCM, and it is not an improvement by any measure. If the recording exists somewhere in better shape, that copy is what belongs in the session.

AIFF is Apple’s uncompressed format, from 1988, and Mac audio tooling grew up assuming it: Logic and the sampler formats that preceded it, CD-authoring applications, and studio house standards written when those tools were the only ones. Current Logic will import an MP3 perfectly well, so the requirement usually comes from somewhere else — a template, a delivery specification, or a piece of hardware.

Hardware is the least negotiable of those. Samplers, groove boxes and older studio gear implement PCM and nothing else, because a decoder is firmware somebody would have to write and maintain. When a device says AIFF, converting is the whole answer and there is no argument to be had with it.

Uncompressed CD-quality stereo costs 176,400 bytes a second — about 10 MB a minute — whether the minute is an orchestra or silence, because every sample is written out as a plain number. An MP3 at 192 kbps costs 1.44 MB a minute and one at 128 kbps costs 0.96.

So the multiplier is set by the source bitrate: roughly seven times from a 192 kbps file and about ten from a 128 kbps one. A four-minute track goes from around 5.8 MB to about 42 MB. There is no setting that changes this, because AIFF performs no compression at all — which is the entire reason anything asks for it.

An AIFF is a series of chunks, and the one produced here holds exactly two: COMM, which states the channel count, the frame count, the bit depth and the sample rate, and SSND, which holds the samples. Nothing else is written.

That means every ID3 tag on the MP3 — title, artist, album, year, artwork, comments — is absent from the result, and no later step can recover it from the AIFF. For a file going into a Logic session, a sampler slot or a CD-authoring timeline this is entirely correct and nobody will notice. For anything destined for a music library, note the metadata somewhere before converting.

An audio CD is 16-bit stereo at 44,100 Hz, and nothing else. The conversion here keeps the sample rate the MP3 had and writes 16-bit PCM, so a 44,100 Hz MP3 produces exactly the file an authoring tool wants.

A 48,000 Hz MP3 — normal for audio pulled out of a video — produces a 48,000 Hz AIFF, and the authoring tool then has to resample it or will decline the file. Nothing on this page resamples for you. Check the source before converting a whole disc’s worth of tracks, because a mixed set of rates is the version of this problem that appears at the burn stage.

The PCM written here is 16 bits per sample. On a lossless source that would be a decision worth examining, since a 24-bit master has depth that 16 bits cannot hold. On an MP3 it is not a decision at all: the source has no additional depth to preserve, and padding to 24 bits would produce a larger file with no more information in it.

Sixteen bits at 44,100 Hz is also what most of the destinations for this conversion actually specify — CD authoring, sampler slots, delivery standards. If a session is running at 24-bit, the AIFF will sit in it as a 16-bit file and behave normally; the session depth is about the mix, not about every source in it.

MP3 encoders work in fixed blocks and add a short run of silence at each end of the recording to fill the last one — usually a few dozen milliseconds. Players that read the encoder’s padding information trim it; an uncompressed file has no such information, so the silence becomes part of the samples.

For a track dropped into a timeline this is invisible. For anything cut to a precise length or meant to loop — a sampler hit, a one-shot, a bar of a loop — it is the first thing to check, because the file no longer starts where the recording does. Trim it in an editor after converting; the AIFF preserves the padding as faithfully as it preserves everything else.

Both hold identical uncompressed PCM and neither has an audio advantage; they disagree about byte order and the shape of the header, nothing more. If a specification names one, use that one. If nothing does, the tiebreaker is where the file is going.

AIFF is the safer choice inside a Mac-only workflow and for anything handed to a studio that asked in those terms. WAV is the safer choice the moment a Windows machine, a web tool, a transcription service or a game engine is involved. What is not worth doing is producing both and keeping both, because each copy is another 10 MB a minute of the same audio.

Files are capped at 100 MB each. That cap applies to what is dropped, and an MP3 is small enough that it will rarely matter — but the AIFF being assembled from it is around 10 MB a minute, so a long recording turns into a great deal of memory inside a browser tab.

For songs, hits, stems and prompts this is comfortable, and a hundred can be converted in one drop and taken as a ZIP. For a concert recording or a long interview, split it in an editor first. Nothing is uploaded at any point, so the constraint is the tab’s memory rather than an allowance anyone could raise.