AIFC to WAV Converter

AIFC to WAV Converter

AIFC — written AIFF-C in Apple's own documentation — is not a separate audio format so much as AIFF with one extra field: a compression-type tag in the file's COMM chunk that declares how the samples are stored. Most .aifc files that come off a Mac are not compressed at all; they carry the sowt tag, which simply means "PCM, byte-swapped to little-endian". Older files can hold genuinely compressed audio instead. This converter decodes whichever variant you have and writes a standard RIFF WAV that Windows, DAWs, hardware samplers, and web players all recognise.

AIFC (AIFF-C) Format at a Glance

WAV Format at a Glance

How to Convert AIFC to WAV

1. Upload Your AIFC File: Drag .aifc files onto the page or click "+ Add Files". Several files can be queued and converted with one set of settings.
2. Choose the Audio Codec: Expand the options and set Audio Codec. PCM 16-bit is the default and matches CD-standard WAV; PCM 24-bit or 32-bit gives extra headroom for further editing; A-law and mu-law produce the 8-bit telephony variants.
3. Set Audio Channel and Sample Rate: Leave Audio Channel and Audio Sample Rate on "ORIGINAL" to keep the source layout, or fold to MONO and resample (8 kHz through 48 kHz) when the target device needs it. Trim takes a start time and a duration if you only want part of the file.
4. Convert and Download: Click Convert and save the WAV. No sign-up, no watermark.

PCM Bit Depth and File Size

Uncompressed PCM has a fixed data rate: sample rate × bytes per sample × channels. That arithmetic is the whole story for WAV sizing, and it is the same number regardless of what the audio contains.

Frequently Asked Questions

Will converting AIFC to WAV reduce the audio quality?

If the AIFC holds uncompressed PCM — compression type NONE or sowt, which covers the large majority of files macOS writes — the samples are decoded and written back out at the same bit depth and sample rate, so nothing is discarded. If the source used a lossy compression type such as mu-law, MACE or IMA ADPCM, decoding to PCM makes the file portable but cannot recover detail the original encoder threw away.

My AIFC is already uncompressed PCM — isn't this just a rename?

No, and renaming the extension is exactly what breaks these files. AIFC and WAV use different containers (IFF versus RIFF), different chunk headers, and — for the NONE compression type — opposite byte order. The audio is fully decoded and re-encoded into RIFF on our servers; the sample values survive, the file layout does not.

Why does my .aifc file open on a Mac but not on Windows?

macOS decodes AIFF-C through Core Audio, so QuickTime, Music and Finder previews treat it as ordinary audio. Windows players, older DAWs and most web players key off the extension and simply do not register .aifc, even when the bytes inside are the same little-endian PCM a WAV would hold. Converting gives you a RIFF file those programs open without a codec pack.

What bit depth and sample rate does the WAV end up with?

The sample rate follows the source unless you change Audio Sample Rate, and the bit depth follows the Audio Codec setting — PCM 16-bit by default. Our converter writes plain interleaved PCM, so the size is pure arithmetic: at 44.1 kHz, 16-bit, stereo that is 44,100 × 2 bytes × 2 channels = 176,400 bytes per second, which puts a 3-minute track at about 31.8 MB plus a header of a few dozen bytes.

Will the WAV be larger than the AIFC it came from?

If the AIFC was uncompressed, the WAV lands within a few hundred bytes of the original — both store raw samples and only the chunk headers differ. If the AIFC used a compressed type, expect growth: 6:1 and 4:1 schemes such as MACE 6:1 or IMA ADPCM expand back to full-rate PCM, so a 5 MB compressed AIFC can become a 30 MB WAV.

Does the conversion keep the AIFF text and marker chunks?

Basic text metadata such as name, author and annotation can map across to WAV's LIST/INFO block, but WAV has no counterpart for AIFF's INST chunk, so sampler loop points, base note and key range are lost. If those matter — for example when moving sampler content between machines — keep the AIFC alongside the WAV.

How large an AIFC can I convert?

The practical limit is upload size and time rather than anything on the decoding side, and the output side has a hard stop: RIFF stores chunk lengths in unsigned 32-bit fields, so a WAV cannot exceed 4 GiB — roughly 6.8 hours of 44.1 kHz 16-bit stereo. Long recordings that would cross that line should be split first or written at a lower sample rate.

When would I pick A-law or mu-law instead of PCM?

Only when something downstream expects G.711 telephony audio — IVR prompts, PBX and SIP systems, and legacy voicemail platforms typically want 8-bit mu-law (North America and Japan) or A-law (most of the rest of the world) at 8 kHz. They halve the file size against 16-bit PCM but throw away dynamic range, so they are a poor choice for music.

Are my files private when I convert them here?

Files are uploaded over an encrypted connection, processed on our servers, and deleted automatically after a few hours — no sign-up, no watermark, never shared or made public.

Going the other way, or working with a whole folder of Apple audio? See WAV to AIFC for the reverse direction, or the AIFC converter for every other target this format supports.