AVRECORDER RECORDING SKIPS SOFTWARE
In practice however, almost all software expects the "fmt " subchunk to be the first subchunk. See this enthusiast webpage for more information about some of the various subchunk identifiers in use today in the wild, and information about their payload structure.įrom a purely RIFF perspective, subchunks need not appear in any particular order in the file, or at any particular fixed offset. It is usually found in WAVE files that use a compressed codec, such as μ-law. "fact" is the next most common subchunk identifier. "data" - the subchunk with this identifier has the actual audio bytes in its payload."fmt " - the subchunk with this identifier has a payload which describes the basic information about the audio's format: sample rate, bit depth, etc.There are a minimum of two subchunks that must always appear in every WAVE file: The WAVE file format reserves certain subchunk identifiers (or "names") as being meaningful to the WAVE format. "fmt "), and a 4-byte little-endian unsigned integer specifying the number of bytes in the subchunk's data payload - the subchunk's data payload follows immediately after its 8-byte header. RIFF subchunks have an 8-byte header: 4 bytes for an identifier/name field which is traditionally filled with human-readable ASCII characters (e.g. Reading WAVE files properly must really begin as an exercise in locating and identifying RIFF subchunks. In fact, finding the audio bytes in a WAVE file must be done by finding the location and size of the "data" subchunk within the RIFF this is the correct way to locate the audio bytes within a WAVE file. For example, I have seen software that assumes that the audio bytes always begin at offset 44 - this is an incorrect assumption.
There is a fair amount of software out there that treats the WAVE format much more rigidly than it ought to, and I suspect the library you're using may be one of those pieces of software. The identifier "FLLR" is "non-standard" and so should be ignored by any software which encounters it. The subchunk is usually about 4000 bytes long, but its actual length can vary depending on the length of the data preceding it.Īdding arbitrary subchunks to WAVE files is generally considered spec-conformant because WAVE is a subset of RIFF, and the common practice in RIFF file processing is to ignore chunks and subchunks which have an unrecognized identifier. I assume "FLLR" stands for "filler", and I assume the purpose of the subchunk is to enable some sort of data alignment optimization. This is what the first 128 bytes of the file look like: 1215N:~/Downloads$ od -c -read-bytes 128 testFile.wavĠ000020 020 \0 \0 \0 001 \0 001 \0 037 \0 \0 200 > \0 \0Ġ000040 002 \0 020 \0 F L L R 314 017 \0 \0 \0 \0 \0 \0Ġ000060 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0Īny idea what I need to do to make sure a correct WAV header is written out by AVAudioRecorder?Īpple software often creates WAVE files with a non-standard (but "spec" conformant) "FLLR" subchunk after the "fmt " subchunk and before the "data" subchunk. The recording succeeds- I can play the file etc, and I can read in the samples using AudioFile services, but I can't validate it because I can't open the file with Python's wave module.
forKey:AVLinearPCMIsFloatKey] Īfter that, I'm just making a call to recordForDuration to actually do the recording. These are the settings I am using to record the file: forKey:AVFormatIDKey] However, python's wave module returns "fmt chunk and/or data chunk missing" when trying to open the wav file that is saved by AVAudioRecorder. To ensure that I'm reading in the samples from the file correctly, I'm using python's wave module to see if it returns the same samples. I'm working on a project on the iPhone where I'm recording audio from the device mic using AVAudioRecorder, and then will be manipulating the recording.
0 kommentar(er)
