Apple wants to provide you with an “universal container for audio data,” per a patent (number 7912730) at the US Patent & Trademark Office.
Pre the patent, storing audio data encoded in any of a plurality of different audio encoding formats is enabled by parametrically defining the underlying format in which the audio data is encoded, in audio format and packet table chunks. A flag can be used to manage storage of the size of the audio data portion of the file, such that premature termination of an audio recording session does not result in an unreadable corrupted file.
This capability can be enabled by initially setting the flag to a value that does not correspond to a valid audio data size and that indicates that the last chunk in the file contains the audio data. State information for the audio data, to effectively denote a version of the file, and a dependency indicator for dependent metadata, may be maintained, where the dependency indicator indicates the state of the audio data on which the metadata is dependent. The inventors are William G. Stewart, James E. McCartney and Douglas S. Wyatt.
Here’s Apple’s background on the invention: “Standard AIFF, AIFC and WAVE files, which consist of “chunks” of information, are limited to 4 gigabytes. High-resolution audio is now demanding that larger file sizes be possible. For example a 4 gigabyte file with 5.1 (i.e., 6 channels) at 96 KHz sample rate and 24 bits per sample has 41 minutes of play time, and a 4 gigabyte file with 5.1 at 192 KHz sample rate and 32 bit floating point per sample has 15 minutes of play time. With 8, 16, 32 or more channels, the play times become even shorter.
“With AIFF and WAVE files, an audio application has two options when recording. The first option is to record the audio data and then update the audio data size field in the file at the end of the recording session. Applications rely on the size field to correctly parse the file. Thus, if an audio application were to terminate prematurely, or there was a power loss while recording, most applications would be unable to read the file because the size field would be incorrect. The second option is to update the size field repeatedly while audio data is written to the file. This process requires significant interactions with the hard disk on which the file is being stored, which significantly and negatively affects performance. Furthermore, if the recording application were to terminate in the midst of updating the size field, the file is also corrupt and unable to be read properly.
“With the evolution and complexity of modern audio formats, a more generic and robust means needs to be developed to contain these formats. Based on the foregoing, there is a need for an audio file format that avoids the above-identified limitations of existing audio formats.
“The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.”
— Dennis Sellers
