Convert FLAC to AIFF

This belongs before anything else on the page, because it is the one loss a reader coming from a lossless archive would not think to check. The PCM written here is signed 16-bit, always. A 24-bit FLAC — the normal depth for a studio master, a high-resolution purchase or a careful transfer — is reduced to 16 bits per sample on the way through, and no later step recovers the difference.

On playback this is inaudible; 16 bits at 44,100 Hz is what a CD holds and what most listening has always been. In a session it is not nothing. Twenty-four bits exist so that gain changes, summing and limiting have room to work without the noise floor rising into audibility, and a master that will be processed further should keep them. If your destination genuinely needs 24-bit AIFF, a desktop converter is the correct instrument and this page is not.

A great many destinations for this conversion specify 16-bit and nothing else. An audio CD is 16-bit stereo at 44,100 Hz by definition. Most hardware samplers, groove boxes and older studio units read 16-bit PCM because that is what their converters and their memory were built around. Broadcast and library delivery standards frequently name it outright.

For those, the reduction is not a compromise but the specification, and doing it here saves a step. What is worth avoiding is a chain where the depth drops more than once, or drops on the way into a session that then runs at 24 or 32 bits internally — the session depth governs the mix, not the sources in it, so a 16-bit AIFF sits inside a 24-bit project without any further loss.

FLAC is a Xiph format, released by Josh Coalson in 2001 and maintained by Xiph.Org since 2003, and Apple came to it late — macOS 10.13 and iOS 11 added native playback in 2017. Logic will import one today, and so will most current software, but the requirement usually comes from somewhere older or lower down: a hardware unit whose firmware implements PCM and no decoder, a template written when nothing on the Mac read FLAC, a delivery standard that names AIFF because the studio that wrote it did.

Hardware is the least negotiable of those. A sampler does not have a FLAC decoder because somebody would have to write and maintain one, and it will never gain the ability. When a device asks for AIFF, converting is the entire answer and there is no argument to be had. Software that merely prefers AIFF is different, and importing the FLAC directly is usually the better move where it works.

Nothing here resamples. A 44,100 Hz FLAC produces a 44,100 Hz AIFF, a 48,000 Hz one produces 48,000, and a 96,000 Hz high-resolution master produces 96,000 at 16 bits — an unusual combination but a legal one. That is the correct behaviour: resampling is a decision with audible consequences and should be made deliberately in an editor, not silently by a converter.

It also means the CD-authoring case has one condition. An audio CD is 44,100 Hz and nothing else, so a 48 kHz source will produce a 48 kHz AIFF that your authoring tool must resample or will refuse. Check the rate of the masters before converting a disc's worth, because a mixed set of rates is the version of this problem that surfaces at the burn stage.

An AIFF is a sequence of chunks and the one written here holds exactly two. COMM states the channel count, the frame count, the bit depth and the sample rate; SSND holds the samples. There is no ID3 chunk, no ANNO chunk, no NAME chunk and no artwork.

So the FLAC's tag block ends at the boundary — title, artist, album, composer, date, catalogue number, replay-gain values and any embedded cover are all absent from the result, and no later tool can recover them from the AIFF. Inside a session that is entirely correct, since the file is a region on a timeline and not a library entry. Going the other way, write down what matters first.

A FLAC stream header carries an MD5 of its decoded audio, computed at encode time. It is the reason a FLAC is an archive rather than a smaller copy: a decoder can reconstruct the samples years later, hash them, and prove nothing has rotted. AIFF has no such field, and a corrupted AIFF is still a structurally valid AIFF.

That sets the filing rule for this conversion. The FLAC remains the archive copy and the AIFF is a working file — regenerable in a minute, and safe to delete when the session is finished. Replacing a checksummed master with an uncompressed working copy loses both the verification and half your disk, which is a poor trade in both directions at once.

The registry records eight channels as the ceiling for FLAC and eight for AIFF, which is a rare exact match. Mono, stereo, quadraphonic and 7.1 all pass through with their layouts intact, and there is no case in this direction where a channel has to be discarded or summed into another.

For post-production that is the useful part: a 5.1 stem archived as FLAC arrives in the session as a 5.1 AIFF. What does not travel is any channel-order or speaker-assignment metadata beyond the count itself, because the COMM chunk records how many channels there are and not what they mean. A multichannel file should be checked against the session's expected order rather than assumed.

Uncompressed 16-bit stereo at 44,100 Hz 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. FLAC typically halves that, so the AIFF is roughly double the file you started with. A four-minute track at 22 MB becomes about 42 MB.

The 100 MB cap applies to what you drop, so the practical limit is around twenty minutes of CD-quality FLAC per file. That is comfortable for tracks, stems, hits and cues and insufficient for a concert or a long interview, where an editor should split the source first. The constraint is the tab's memory rather than an allowance, so there is no tier that raises it.

Writing AIFF costs no dependency. The samples are muxed as a WAV and then rewrapped by ten lines of arithmetic — the header rebuilt big-endian, the sample rate written as the 80-bit extended float the format insists on, and each sample's bytes reversed. No WebAssembly encoder is fetched, unlike the MP3, AAC and FLAC targets on this site.

Decoding the FLAC happens on your own machine too, so a conversion here moves nothing across the network in either direction. For unreleased masters, client material or anything under an embargo that is the property worth having, and it is checkable rather than promised: open the network tab, run a conversion, and watch nothing leave.