OK, someone has obviously too much free time on their hands
[{POST_SNAPBACK}][/a]

CAF files have several advantages over other standard audio file formats:

    * Unrestricted file size

      Whereas AIFF, AIFF-C, and WAV files are limited in size to 4 gigabytes, which might represent as little as 15 minutes of audio, CAF files use 64-bit file offsets, eliminating practical limits. A standard CAF file can hold audio data with a playback duration of hundreds of years.
   
    * Safe and efficient recording

      Applications writing AIFF and WAV files must either update the data header’s size field at the end of recording—which can result in an unusable file if recording is interrupted before the header is finalized—or they must update the size field after recording each packet of data, which is inefficient. With CAF files, in contrast, an application can append new audio data to the end of the file in a manner that allows it to determine the amount of data even if the size field in the header has not been finalized.

    * Support for many data formats

      CAF files serve as wrappers for a wide variety of audio data formats. The flexibility of the CAF file structure and the many types of metadata that can be recorded enable CAF files to be used with practically any type of audio data. Furthermore, CAF files can store any number of audio channels.

    * Support for many types of auxiliary data

      In addition to audio data, CAF files can store text annotations, markers, channel layouts, and many other types of information that can help in the interpretation, analysis, or editing of the audio.

    * Support for data dependencies

      Certain metadata in CAF files is linked to the audio data by an edit count value. You can use this value to determine when metadata has a dependency on the audio data and, furthermore, when the audio data has changed since the metadata was written.

[17:43] <DEATH> hmm, now that people rip DVD-A, hell is gonna break loose about WAV size limit
[17:43] <DEATH> was hard to hit with CD sources
[17:45] <DEATH> would be nice if someone came with new PCM container and all encoder authors agreed on that
[17:45] <DEATH> otherwise we're gonna have very nice compatibility issues
[17:46] <DEATH> something that is simple enough for all random encoders to be able to accept it as input
[17:46] <rjamorim> Yeah, it would require to be a simple container, not some overkill
[17:47] <rjamorim> Up to creating that, Peter?;)
[17:47] <DEATH> well matroska libraries are C++ and C zealots among codec authors will never accept that
[17:47] <DEATH> we need something similar to WAV but with 64bit headers
[17:48] <DEATH> some spoony audio editor has some WAV mutation that supports >2GB (soundforge?) but i never really figured that
[17:49] <DEATH> WAV actually got improved with WAVEFORMATEXTENSIBLE headers (which noone supports, bah)
[17:50] <DEATH> but that's still 2GB-capped by specs (while all sane parsers should accept up to 4GB but specs say 2GB)
[17:51] <joemauch> i wonder what the audio engineer's who store the format in PCM use for a container then
[17:52] <JensRex> .raw?
[17:52] <Garf> most high end audio editing programs have proprietary formats
[17:52] <DEATH> hmm
[17:52] <Garf> which store marks and such
[17:52] <DEATH> is there PCM in MP4 specs
[17:52] <rjamorim> DEATH: No point hacking WAV, imo. I think someone should create a new, very bare bones container that just holds unlimited amounts of data
[17:52] <rjamorim> No RIFF fagotry and the like
[17:52] <DEATH> rjamorim: agree
[17:52] <DEATH> WAVEFORMATEXTENSIBLE is legal though
[17:52] <DEATH> but again noone supports it
[17:52] <rjamorim> Yeah, but it's sort of a hack over original WAV
[17:52] <rjamorim> right
[17:53] <rjamorim> that's the problem
[17:53] <rjamorim> That's why I emphasize of bare bones. Then you either support it, or it breaks horribly
[17:53] <rjamorim> No optional features and the like
[17:53] <DEATH> WAVEFORMATEXTENSIBLE simply uses MS-assigned format tag to tell app reading the header to read extended data which includes GUID for data type (so no more need to stupidly register format codes with MS to use them), channel setup flags, and so on
[17:53] <rjamorim> aha
[17:54] <DEATH> most important part for me is channel mask
[17:54] <rjamorim> Yeah, MP4 would be a nice solution if it supported PCM.
[17:54] <rjamorim> Although I believe that even MP4 is a little overkill for what we need
[17:55] <DEATH> and mp4 libraries are mostly C++
[17:55] <DEATH> Menno's C library is a mess
[17:56] <rjamorim> A simple format would also make things easier to convince software authors to support it.
[17:56] <rjamorim> "here, add these 100 lines of pure ANSI C to your project and we'll love you forever"
[17:57] <DEATH> yes

Quote

    * Safe and efficient recording

      Applications writing AIFF and WAV files must either update the data header’s size field at the end of recording—which can result in an unusable file if recording is interrupted before the header is finalized—or they must update the size field after recording each packet of data, which is inefficient. With CAF files, in contrast, an application can append new audio data to the end of the file in a manner that allows it to determine the amount of data even if the size field in the header has not been finalized.

And still apple thinks it is important to make an other container format which is better then all the others  [a href="index.php?act=findpost&pid=312814"][{POST_SNAPBACK}][/a]

Great, another container format  

Why doesnt anyone choose a single format and stick with it. If im making an mp3 wrapped in ogg with a nice id3v2.xyz tag in the middle of it, im wondering how much programs can actualy recognize the format, even when it is 100% compliant.

Even the wav standard isnt fully supported by many program.  The wav container already can contain full images.  But somehow people think because of the 2GB size problem its necesary to create a full new container format to support all kinds of unused features. 

And still apple thinks it is important to make an other container format which is better then all the others  .
[a href="index.php?act=findpost&pid=312814"][{POST_SNAPBACK}][/a]

Quote

Great, another container format  

Why doesnt anyone choose a single format and stick with it. If im making an mp3 wrapped in ogg with a nice id3v2.xyz tag in the middle of it, im wondering how much programs can actualy recognize the format, even when it is 100% compliant.

Even the wav standard isnt fully supported by many program.  The wav container already can contain full images.  But somehow people think because of the 2GB size problem its necesary to create a full new container format to support all kinds of unused features. 

And still apple thinks it is important to make an other container format which is better then all the others  .
[a href="index.php?act=findpost&pid=312814"][{POST_SNAPBACK}][/a]

2GB size limit is a serious problem, it can be easily exceeded with data ripped from DVD audio disc - for an example, fully compliant WAV file can store only about 20 minutes of 96/24bit/5.1 material. If you seriously don't know what you're talking about, why do you even bother posting ?
[a href="index.php?act=findpost&pid=312818"][{POST_SNAPBACK}][/a]

Sorry, but think i DO know what im talking about.  The 2gb limit is a reall problem with a really easy solution. This problem is not a reason to implement a different container format for every audio format.  FYI i have examined and programmed and tested a program to read wav's and i noticed many (almost all) programs dont even interpret the value of wBitsPerSample correct. So when even a "simple"  format as wav isn't applied correct, i think it wont become better when there are 10 container formats floating arround, which are all much more complex then the wav format.  


PS im not very good in writing english, since its not my native langue, but that doesnt mean i dont know what im talking about.
[a href="index.php?act=findpost&pid=312823"][{POST_SNAPBACK}][/a]

FYI i have examined and programmed and tested a program to read wav's and i noticed many (almost all) programs dont even interpret the value of wBitsPerSample correct.

That seems incompatible with the Packet Table required for VBR encoding, unless I missed something.
[{POST_SNAPBACK}][/a]

Packet Table Chunk

CAF files that contain variable bit-rate (VBR) or variable frame-rate (VFR) audio data contain audio packets of varying size. Such files must have exactly one Packet Table chunk to specify the size of each packet.

You can identify CAF files containing VBR or VFR audio by their Audio Description chunk. In such files, one or both of the mBytesPerPacket and mFramesPerPacket fields in the Audio Description chunk has a value of 0. See “Audio Description Chunk”.

The content of the Packet Table chunk describes, and therefore depends on, the content of the Audio Data chunk. See “Audio Data Chunk”. The packet table must always reflect current state of the audio data in a CAF file.

A CAF file with constant packet size can still include a Packet Table chunk in order to record certain information about frames (see “Packet Table Description”).

I think it would be great if a library that could play CAF back was released on Windows/Linux, but I'm not sure if the specification is complete enough to write one.  I haven't read it too closely yet.[{POST_SNAPBACK}][/a]

Quote

Great, another container format  

Why doesnt anyone choose a single format and stick with it. If im making an mp3 wrapped in ogg with a nice id3v2.xyz tag in the middle of it, im wondering how much programs can actualy recognize the format, even when it is 100% compliant.

Even the wav standard isnt fully supported by many program.  The wav container already can contain full images.  But somehow people think because of the 2GB size problem its necesary to create a full new container format to support all kinds of unused features. 

And still apple thinks it is important to make an other container format which is better then all the others  .
[a href="index.php?act=findpost&pid=312814"][{POST_SNAPBACK}][/a]

2GB size limit is a serious problem, it can be easily exceeded with data ripped from DVD audio disc - for an example, fully compliant WAV file can store only about 20 minutes of 96KHz/24bit/5.1 material. If you seriously don't know what you're talking about, why do you even bother posting ?

Additionally, WAV is used to pipe data to all sorts of commandline encoders, introducing issues with encoding very long streams, even with no physical temporary WAV files involved.
[a href="index.php?act=findpost&pid=312818"][{POST_SNAPBACK}][/a]

My first problems with 2 GB/4 GB limit:
[a href="index.php?act=findpost&pid=312932"][{POST_SNAPBACK}][/a]

What are the benefits of this format over existing "complex" formats?
[a href="index.php?act=findpost&pid=312986"][{POST_SNAPBACK}][/a]