Convert AIFC Files Online for Free

An AIFC Extension Identifies an AIFF-C Container, Not One Audio Codec

Convert AIFC files after identifying the actual data they contain. AIFC, or AIFF-C, is the compressed extension of the AIFF family, but “compressed” does not describe a single codec. Its COMM chunk identifies a compression type. That type may mean ordinary PCM with a particular byte order, floating-point samples, companded speech coding, or another supported representation. The .aifc suffix alone cannot tell a receiver what it must decode.

This makes AIFC conversion a detection task before it is a destination-selection task. A target format can preserve decoded samples only if the source compression type can be read. A lossy source should be decoded once and then converted from that PCM result; a lossless PCM or floating-point source should be kept intact until the output choices are confirmed.

Do not rename AIFC to AIF or WAV. The new name leaves the AIFC form and codec description unchanged, so applications that depend on the correct header can still reject or misinterpret it.

FORM AIFC and FVER Establish the AIFF-C File Context

AIFF-C uses an IFF FORM wrapper whose form type is AIFC. Chunks have a four-character identifier and a big-endian size field. AIFC includes an FVER Format Version chunk, which appears only in AIFF-C and identifies the defining format-version context. A parser should locate chunks by their IDs rather than assume fixed offsets, because optional chunks can occur and chunk data can require padding.

The required structural context is separate from the audio payload. A file can have a valid FORM and FVER but still contain a compression type the receiving tool does not support. Conversely, a tool that supports AIFF PCM may not support every AIFF-C form. Inspect the real form type and decoder capability before planning a batch.

If an application reports a missing common chunk or invalid header, check the complete transfer and chunk alignment before attempting conversion. An extension change cannot repair absent or mis-sized structural data.

COMM Adds a Compression Type and Name to Core Sample Properties

Like AIFF, AIFC uses COMM to describe channels, number of sample frames, sample size, and sample rate. In AIFC it additionally carries a four-character compression type and a human-readable compression name. Those fields tell the decoder how to interpret sound data; the numeric sample-size field alone does not reveal whether bytes are signed integers, floats, companded values, or another coded representation.

The SSND chunk holds sound-data offset and block-size fields followed by payload bytes. A converter has to honor COMM and SSND together. If the reported frame count, channels, or compression type conflicts with the source payload, duration may be implausible or audio may fail to decode. Verify these properties in an audio inspector before choosing output quality settings.

COMM values describe the source; a new destination may have different header rules and tag conventions. Treat conversion as decode plus output encoding or PCM writing, not as a blind chunk copy.

NONE and sowt Explain Why AIFC Is Not Always Actually Compressed

The NONE compression type denotes uncompressed PCM in conventional big-endian AIFF-C representation. The historical sowt type—“twos” spelled backwards—identifies little-endian PCM. It is a byte-order variation, not perceptual compression. AIFC header fields remain big-endian even when the sowt audio samples are little-endian, so a converter must distinguish header interpretation from the payload’s sample byte order.

A NONE-to-sowt or sowt-to-NONE operation can preserve the sample values when implemented correctly, but it still rewrites the file structure and must be tested. Treat neither as proof that every AIFC file can be directly remuxed: other compression types need a codec-specific decode, and the destination may not support the same representation.

If a supposed PCM AIFC plays as noise, inspect the compression type and byte order rather than assuming the audio is damaged. A little-endian payload interpreted as big-endian PCM is a common representation error.

fl32, fl64, ulaw, and alaw Set Different Source Quality Boundaries

Common AIFC compression types include fl32 and fl64 for 32-bit and 64-bit floating-point audio, and historical ulaw/ULAW and alaw/ALAW types for G.711 mu-law and A-law companded audio. Floating-point source may be useful for an editing workflow, while companded speech coding has its own quality and bandwidth limits. The destination should be selected from the real source representation, not simply the AIFC suffix.

Optional AIFC Chunks Need Preservation Checks Beyond the Audio Payload

AIFC can contain optional annotation, name, marker, application, or comment chunks in addition to structural and sound-data chunks. A new target may use a different metadata system entirely. Successful audio conversion does not mean markers, NAME-like information, artwork, rights notes, cue data, or application-specific fields have moved.

Keep a manifest recording source path, FORM type, FVER presence, COMM compression type, rate, channels, conversion settings, and any required markers. Open the output in the actual editor or library and verify the information it needs. Preserve the original AIFC when optional chunks are part of the project record.

A waveform alone proves only that some audio was read. It does not prove the intended take, channel arrangement, or editorial context survived.

Recover AIFC Compatibility by Inspecting, Decoding, and Testing the Receiver

Is every AIFC file lossy?
No. NONE and sowt are PCM forms; fl32 and fl64 are floating-point forms. ulaw and alaw are companded source types with different limits.

Why can an AIFC file fail in an AIFF player?
The player may support standard AIFF PCM but not the AIFC form or its COMM compression type.

Does sowt mean audio was compressed?
No. It identifies little-endian PCM data while AIFC header fields remain big-endian.

Can conversion restore ulaw or alaw detail?
No. Decode to PCM for editing, but lost source detail is not recreated.

What should be checked after conversion?
Check duration, compression or output codec, rate, bit depth, channels, markers, and playback in the intended receiver before deleting the source.

For batch recovery, first group files by actual COMM compression type rather than filename. Test one representative from each group through the intended conversion route. If a decoder rejects a type, preserve the original and locate a tool that explicitly supports that codec; forcing a rewrite risks producing silence or mislabeled data. For successful exports, compare beginning, middle, and end playback and retain the conversion record with the original AIFC.

A practical inspection sequence is to read FORM type first, confirm FVER for AIFC, read every COMM property including the four-character compression type, and then determine whether the available decoder recognizes it. After decoding, compare the number of channels, rate, duration, and audible programme before writing a destination. This avoids a common error: treating the printable compression name as a guarantee that the receiver supports the codec. The four-character type, actual implementation, and destination requirements all matter.

When the source contains floating-point samples, choose the destination sample representation deliberately. A PCM export may be appropriate for a receiver that requires it, but it is a workflow decision with possible precision and size consequences. When the source is mu-law or A-law, preserve a source copy and document that decoded PCM is an edit or compatibility representation, not recovered linear master audio.