Convert FLV to AIFF Online for Free
Extract the selected FLV audio stream into an uncompressed AIFF sound file with clear format and timing checks.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
Convert an FLV Audio Track to an AIFF Sound File, Not a Renamed Video
An FLV-to-AIFF conversion produces an audio-only derivative. FLV is a timed-media container: it can carry audio, video, script data, and other tag payloads. AIFF is a chunked sound-file format built to describe audio samples. The conversion therefore has to locate the requested FLV audio stream, decode that stream to PCM samples, and write a new AIFF file. Changing an .flv filename to .aiff cannot perform any of those steps.
Pictures, FLV tag timestamps, video codec configuration, and video-only context are intentionally absent from the result. Keep the original FLV when the video remains important, when an audio event must later be checked against picture, or when another delivery format may be needed. An AIFF can be a useful edit, review, or interchange copy of the sound, but it is not a replacement for the multimedia source.
Before exporting, identify the actual audio track, codec, sample rate, channel layout, language where applicable, duration, and intended receiver. A file described casually as “an FLV” does not promise AAC, stereo, 44.1 kHz, or even an audio track. This inspection prevents a convincing-looking AIFF that contains the wrong commentary track, a downmix nobody requested, or no decodable audio at all.
The Nine-Byte FLV Header and Its Tags Explain Why Stream Inspection Comes First
An FLV file starts with the ASCII signature FLV, a version byte, type flags, and a 32-bit DataOffset. In ordinary version-1 files the DataOffset is 9, but a reader should honor the stored value rather than assume it. The flags indicate whether audio and video tags are present; they do not describe every codec or prove that a usable track exists. A previous-tag-size field and then individual tags follow the header.
A tag header identifies a type, payload size, timestamp, extended timestamp byte, and stream ID. Audio, video, and script-data tags are separate timed pieces of the file. The timestamp is in milliseconds, with the extended byte expanding the timestamp field. That tag timeline is relevant when checking an extracted sound against the original programme: it is not an AIFF sample clock that can simply be copied into a target header.
Script-data tags commonly use AMF, Action Message Format, to carry fields such as duration, dimensions, codec IDs, keyframe positions, or other producer metadata. Those fields can be useful clues, but they are not a substitute for examining the audio payload. Metadata can be missing, rounded, stale, or describe the file broadly rather than the selected sound. Use the decoder’s stream report and audible tests as the conversion authority.
FLV Audio Headers Need Codec-Aware Decoding Before PCM Can Reach AIFF
The first byte of a conventional FLV audio payload is an AudioTagHeader. Its high four bits are SoundFormat; lower fields nominally identify SoundRate, SoundSize, and SoundType. SoundFormat distinguishes possibilities such as linear PCM, ADPCM, MP3, Nellymoser variants, G.711 forms, AAC, Speex, and device-specific cases. These are routing fields, not a universal recipe for interpreting every sample byte. Some codec values have special rules that override or make parts of the nominal rate and channel fields uninformative.
AAC needs particular care. When SoundFormat is 10, the next byte is AACPacketType: zero is an AAC sequence header and one is raw AAC data. The sequence header supplies codec configuration needed to decode following AAC access units. It is not audible PCM and must not be written into AIFF sound data. Conversely, raw AAC payload is compressed audio that requires AAC decoding. The FLV header convention can indicate 44 kHz and stereo for AAC, but the actual AAC configuration remains the source of truth for real sample rate and channels.
Video details such as AVC/H.264 packet type are irrelevant to selecting the audio essence. A conversion should not infer sound properties from the video codec, frame dimensions, or keyframes. If a source has no audio tags, or has an audio codec the conversion path cannot decode, the accurate outcome is to report that limitation—not to create silence or claim that video data became an AIFF recording.
AIFF Uses FORM, COMM, and SSND Chunks to Describe the New PCM Stream
A classic AIFF file is an IFF-style form. It starts with FORM, a 32-bit form size, and the form type AIFF. Within the form, chunks have an identifier, a size, and data; odd-sized chunk data is padded for alignment. The essential Common chunk, COMM, describes the sound: number of channels, number of sample frames, sample size in bits, and sample rate. The rate is stored as an 80-bit extended floating-point number, not as an FLV timestamp.
The Sound Data chunk, SSND, carries an offset, block-size field, and the actual sound data. For ordinary uncompressed AIFF PCM, multibyte samples use big-endian byte order. This matters after decoding. A 16-bit sample written little-endian while COMM says it is ordinary AIFF PCM can make audio sound severely distorted despite an apparently correct duration. Channel count, bits per sample, rate, and SSND byte order need to agree with one another.
Sample frames are not the same as bytes or video frames: one sample frame contains one sample for each channel. For example, a stereo PCM output has two channel samples per frame. The COMM frame count, target rate, and channel count should make sense against the decoded duration and output size. Probe the finished file in an independent reader, then audition it rather than treating a successful file write as proof.
AIFC Changes the COMM Contract Through a Declared Compression Type
AIFF-C, commonly called AIFC, is related to AIFF but is not merely a different extension. Its form type is AIFC, and its COMM chunk includes a compression type and compression name after the core common fields. AIFC can identify compressed audio or a PCM representation with a particular convention. The NONE compression ID is used for uncompressed big-endian PCM; other IDs make a different promise to a decoder.
When a receiving application specifically asks for standard uncompressed AIFF, write an AIFF form with PCM fields it accepts instead of supplying an AIFC file renamed .aiff. If it explicitly asks for AIFC, determine the exact compression identifier, byte-order expectation, sample rate, bit depth, and channel policy it documents. The filename is weak evidence; FORM type and COMM contents are the decisive facts.
Neither AIFF nor AIFC magically improves a lossy FLV source. Decoding AAC, MP3, Speex, or another lossy source and saving PCM avoids a further lossy encode at this stage, but it cannot restore audio detail removed earlier. The larger resulting file reflects uncompressed samples, selected rate, channel count, and precision—not newly recovered quality.
Choose Extraction Settings From the Source and the Receiving Workflow
| Decision | Inspect in FLV | AIFF consequence |
|---|---|---|
| Track choice | Audio tags, language, commentary, and audible content | Export only the intended programme; do not silently choose another track. |
| Codec configuration | SoundFormat plus AAC sequence header or other codec-specific data | Decode correctly before writing PCM; compressed payload cannot be copied into SSND. |
| Sample rate | Actual decoder report, not only nominal SoundRate bits | Write the matching 80-bit COMM rate or document one deliberate resample. |
| Channels | Actual audio configuration and intended layout | Set COMM frames/channels consistently; downmix only on purpose. |
| PCM layout | Decoded sample precision and channel order | Write big-endian samples that agree with COMM sample size. |
| Timeline | Tag timestamps and recognizable source events | Check first, middle, and last audible points after extraction. |
Preserve the decoded source rate and channels when the target accepts them. Resampling to a bigger number cannot create missing high-frequency information, and an automatic stereo-to-mono fold-down can alter dialogue level, phase, and music balance. If a receiving system requires a specific rate, channel count, or bit depth, state that as a deliberate target transformation and listen for its effect.
For material synchronized to picture, compare a recognizable cue near the start, one around the middle, and one near the end while the FLV remains available. This three-point test distinguishes a bad selected stream, an unintended trim, a sample-rate mistake, and genuine source timing behavior. Do not add arbitrary silence just to force a rounded displayed duration to match.
Approve an FLV-to-AIFF Delivery Only After Format, Audio, and Receiver Checks
Inspect the source before conversion and inspect the target after it. Confirm that the input actually contains the selected audio, then confirm that the result identifies as AIFF or the requested AIFC variant, reports the intended sample rate, channels, bit depth, frame count, and duration, and decodes without errors. Open the file in the application that needs it, not only in the application that created it.
Does this keep FLV video?
No. AIFF is an audio file. Preserve the FLV if pictures, video timing, captions, or visual context remain relevant.
Why can’t FLV AAC be copied directly into AIFF?
AAC is compressed coded audio; AIFF SSND data for ordinary AIFF is PCM. The AAC sequence header and raw access units must be decoded before target PCM is written.
Why does an AIFF sound wrong even though its duration looks right?
Check sample byte order, COMM rate, sample size, channels, and whether the correct FLV audio codec/configuration was decoded. A valid-looking duration does not prove correct PCM interpretation.
Is AIFC the same as AIFF?
No. AIFC declares a compression type in COMM. Use the exact form and representation required by the receiving application.
Will uncompressed AIFF improve compressed FLV audio?
No. It can avoid another lossy encoding pass after decode, but it cannot reconstruct information removed by AAC, MP3, or another lossy source codec.
Record the source name, selected stream, decoder-reported properties, output form type, any resampling or channel change, and receiver test result. That concise provenance note makes a later review possible and helps distinguish a well-formed audio derivative from a file that was merely given a familiar extension.