Convert Files to CAF Online for Free
Create a Core Audio Format file only from supported, decodable audio and document the target codec, chunk structure, byte order, packet timing, and metadata.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
Convert Supported Audio to CAF Only After Confirming What the Input Really Contains
Convert files to CAF when a compatible Apple Core Audio workflow requires a CAF container. “Any” means audio inputs that the conversion path can actually read and decode—not every filename, document, protected file, damaged upload, or unknown extension. First identify the source container and codec, decode supported audio to samples, then write an explicitly chosen CAF representation. Changing a filename to .caf does not create the required header, Audio Description, or Audio Data chunks.
CAF is a container, not a promise of losslessness. It can store linear PCM, float, AAC, and other declared audio formats. A PCM CAF from a decoded PCM source can avoid a new lossy codec stage. A CAF containing AAC or another lossy target is a new encoding decision. A lossy source cannot regain its removed detail merely because the new CAF uses a 64-bit chunk size or a PCM target.
Before conversion, decide why CAF is needed: very long PCM work, a Core Audio tool requirement, a specific supported codec, or metadata/marker handling. Then choose target PCM or compressed format based on the final receiver rather than assuming the CAF extension itself solves compatibility.
CAF Requires a caff Header Followed Immediately by a desc Audio Description
A valid CAF starts with the file type caff, a version, and flags. CAF v1 uses version 1. Each following chunk has a four-character type and a signed 64-bit data-section size. Container fields use big-endian network byte order. The first chunk after the file header must be the Audio Description chunk, desc. It records the sample rate, format ID, format flags, bytes per packet, frames per packet, channels per frame, and bits per channel needed to interpret audio data.
The Audio Data chunk, data, is also required and contains an edit count plus audio payload. Its size can be -1 only when data length is unknown, in which case it must be the final chunk. CAF can describe large files because chunk sizes use 64 bits, but that does not eliminate receiver limits, storage constraints, or the need to test whether a particular tool can open the selected rate and channel arrangement.
A converter must build coherent desc and data values from the selected target. A source’s header fields are input facts, not values that can be copied blindly into a CAF with a different target codec or sample layout.
Select Linear PCM, Floating Point, or a Supported Compressed CAF Target Deliberately
Linear PCM is a common CAF target for editing and further conversion. CAF supports 16-, 24-, and 32-bit signed integer PCM and 32- or 64-bit float PCM, with payload byte order described by format flags. For PCM, one packet contains one frame and bytes per packet equals bytes per frame. Twenty-four-bit output may be packed in three bytes per sample or unpacked/high-aligned in four, so target packing must be stated and verified.
Compressed CAF is different. Compressed packets are opaque until decoded, and bits per channel is zero in the description. Variable-bit-rate or variable-frame-rate CAF must have a pakt Packet Table. Some codecs require a kuki Magic Cookie with decoder-specific configuration; AAC is an example. Use a compressed CAF only when the receiving Core Audio workflow supports the selected codec, profile, timing information, and cookie data. Do not claim a compressed target is lossless because its outer container is CAF.
If an input cannot be decoded by the available path, stop and identify the source codec. Do not substitute a different file and label it as a successful CAF conversion.
Keep Source Rate, Channels, and Sample Semantics Unless the Target Requirement Changes Them
Source sample rate, channels, sample type, and duration are separate from the choice of CAF. Preserve them when target support permits. Resampling is justified by a documented delivery or session requirement, not by a belief that a larger number restores source quality. Upconverting a narrowband voice source does not create wideband recording detail. Similarly, copying mono into two channels produces a larger file, not stereo information.
A required downmix needs a defined channel matrix and an audible test. Selecting the first two source channels can remove centre dialogue or create phase problems. For PCM sources, choose target integer/float depth and byte order from the final application. For lossy or compressed sources, decoding produces samples but does not remove earlier artifacts; a PCM CAF preserves those decoded samples, while a new compressed CAF adds a second codec decision.
| Input or target choice | CAF consequence | What to validate |
|---|---|---|
| Supported source codec | Determines whether samples can be decoded | Inspect actual stream, not extension. |
| CAF target codec | PCM/float representation or new compressed stream | Match the final Core Audio receiver. |
| desc fields | Audio interpretation and timing | Verify rate, format, packets, channels, and bits. |
| PCM byte order | Payload sample values | Read format flags, not just container endianness. |
| Packet Table | Variable-packet size or timing interpretation | Require it where VBR or VFR applies. |
| Magic Cookie | Decoder configuration for certain codecs | Preserve/create it only for supported target codec. |
Separate CAF Container Byte Order From the Byte Order of PCM Audio Payloads
CAF file and chunk headers are big-endian. The PCM samples inside data may be either big- or little-endian, as indicated by the linear PCM format flags in desc. Float versus signed integer is another independent flag. Confusing these layers can create a file whose chunk structure appears valid but whose waveform is noise or distorted amplitude. A target writer must signal the same byte order it actually writes.
Inspect a representative decode after construction. Confirm target rate, channel layout, depth, byte order, frame count, duration, and sound. If the source is 24-bit, also confirm whether target samples are packed or unpacked; the bytes-per-packet value must agree. Fix a mismatch in the target desc or payload writer before processing a batch.
Container byte order is not an aesthetic preference. It is an interpretive requirement, and a correct answer depends on the target format description rather than a generic assumption about Apple audio files.
Map Metadata, Markers, and Source Provenance to CAF Only When the Data Is Real
CAF can carry optional Strings, Marker, Region, Information, Overview, Peak, and application-defined chunks. Some metadata relates to the Audio Data edit count, so edits can make it stale. A source may have title, artwork, cue points, timestamps, or application data that has no one-to-one CAF equivalent. Do not invent markers, descriptions, or artwork during conversion merely to make the output seem complete.
Keep a manifest for source identity, actual source codec, rate, channels, original duration, selected CAF codec and desc fields, any resampling/downmix, packet/cookie details, and receiver test result. Copy basic labels only from verified source information. If a target recipient needs source cues, test marker/region behaviour in that recipient rather than assuming it accepts every CAF optional chunk.
If audio is already approved and only tags need correction, update the appropriate metadata layer without re-encoding a lossy audio stream. Retain the source where complete provenance matters.
Approve File-to-CAF Output With Target Codec, Chunk, Duration, and Playback Tests
Can every uploaded file be converted to CAF?
No. The input must be supported, genuine audio that the conversion path can decode. A filename, encrypted file, corrupt upload, or unknown codec is not enough.
Is CAF always lossless?
No. CAF is a container. It can store PCM or float losslessly, but it can also store AAC or another compressed format.
Why can a CAF file use little-endian samples?
CAF headers are big-endian, but desc format flags define linear PCM payload order. The container and samples must be interpreted independently.
When do I need a Packet Table?
CAF requires it for variable-bit-rate or variable-frame-rate audio. Constant PCM does not need variable packet descriptions.
Will conversion preserve every source marker and tag?
Not automatically. CAF optional chunks differ from other metadata models, so preserve important source context in a verified mapping or companion manifest.
For a batch, group inputs by actual source codec, rate, and channel arrangement. Test one representative from each group: decode it, inspect caff/desc/data structure, confirm target codec and byte order, compare duration, validate packet/cookie needs, and open the transferred result in the final Core Audio application. This identifies an unsupported source, target description mismatch, metadata loss, or receiver limitation while clean sources are still available for a controlled new output.
A final source-to-output waveform spot check is especially useful after large-file creation: it exposes a mistaken data-size or end-of-file boundary before the CAF becomes a workflow dependency.