.caf files

I have been recording long files in the BWF format. I import these into Audacity (2.3.2). I then string two files into a single file and attempt to store the resulting file (about 6 gb) as a .caf file. Audacity will not do this and tells me that the file is too long for wave or AIFF where the limit is 4 gb.

I tried storing each of the two files as .caf files and this worked OK. I then imported the two .caf files into Audacity and strung them together. I then tried to store the combined files as a .caf file and got the same error message. I am using OSX 10.14.6.

There is a problem with storing large .caf files.

I have been recording long files in the BWF format.

Are you seeing how many oddball formats you can squeeze into one show? As far as I know Broadcast WAV has the same file size limits as regular wave and the only advantage is greatly enhanced meta-data.

I’ve smacked into Core Audio, too. Music Memo APP on the iThings insists on creating those making it amusing to use them for easy production. CAFs are actually very nice and I can understand why they’re used, but not everybody supports them and that brings us back to you.

Does it say anywhere Audacity supports CAF? If I had to guess at it, I’d say Audacity may have partial support and you just hit the partial.

Others will post.


RF64 WAV supports large (> 4 GB) files.
To select RF64, you need to use the “other uncompressed files” option: https://manual.audacityteam.org/man/file_export_dialog.html

I am using BWF format because that is one of the formats used by Metric Halo for
my ULN-8; a format that can excede the 4 gb wave file limit.

I happen to have been keeping my master files in the caf format - and have used
Audacity in the past to construct caf files as large as 32 gb.

Audacity has supported .caf files in the past and recognised that the length of caf files
had no limit. I have now gone back to 2.1.1 on a different one of my Macs and now have
no problems in working with large .caf files.

It seems to me that in recent updates to Audacity (I don’t know exactly when) somebody
forgot that caf files do not have a 4 gb limit.

I consider this to be a bug that should be fixed.


I am minded to agree with you.

I just tested on W10 with the latest 2.3.3 alpha and indeed a large project (7 hours stereo) exported to .caf format dies indeed trop the 4gb limit error (wrongly).

I also tested on an older Audacity 2.2.0 and was able to export the same project to .caf format successfully - and I then re-impoted it OK

A couple of releases ago we introduced the error trap for WAV and AIFF files limiting them to the 4gb limit thay have prior to export (based on the project length and stero/mono) - CAF must have accidentally got swept up in that. Before we introduced that trap, Audacity would merrily go ahead and export overlong files, apparently successfully, but with corrupted data - unbeknown to the user.

So not only is this a “bug” - it is a “regression” on previous older versions of Audacity (i.e something is broken that used to work). I will log this regression bug on our bug-tracker later today.

Thanks for the report tcdk - much appreciated,


Indeed it does - but in that later Audacities, it too (wrongly) falls foul of the 4gb size trap - I just tested this on 2.3.3.


This page in the Manual: Other uncompressed files Export Options - Audacity Manual
has nothing explicit to say about CAF - but CAF is definitely one of the Headers available in the dropdown menu, so the app definitely knows about it.

Plus, it used to work (based on my tests this morning)

So, I’ll be updationg the 2.3.3 alpha Manual soon to show the available headers - thus documenting the availability of CAF.


On this page in the Manual: Other uncompressed files Export Options - Audacity Manual

It states: “The RF64 size limit is about 16 exabytes, making it suitable for very long multi-channel files.”

Does anybody know the actual size limit for RF64 - and for CAF files before I log the bug later today - as I suspect we don’t want to just remove the 4gb limit we maywant to trap the actual limit (if any) for these formats ?

Or do we consider 16 exabytes to be so big as not worth bothering with an error trap ?


And I note there are several other formats available in the “Other uncompressed audio files” that may have size limits - and those limits may not be 4gb.
Can anybody cast any insight onto the other formats in this list ?

Other Uncompressed Files.png
Any data gratefully received.


Wikipedia says “approximately 16 exabytes”.
2^64 bytes works out as 15.9999999967 exabytes, so the figure will be very close to 16 exabytes.

CAF files also use 64-bit addressing, so they are probably also about 16 exabytes max.

Yes. 16 exabytes is over 16 million terabytes, which is more than a million times bigger than the biggest hdd currently available.

In practical terms, both RF64 and CAF can be considered to have no size limit.

The maximum size of RAW files are limited only by the underlying file system. For NTFS, that is “approximately 16 exabytes”.

W64 has a 64 bit header, so I think that can also be considered to have “unlimited” file size.

MAT4 and MAT5 supports files bigger 4GB, though I don’t know what the actual limit is. Audacity shouldn’t limit MAT4 or MAT5 to 4 GB.

The other formats appear to be “legacy formats”. Legacy applications that require these formats are probably limited to 4 GB or less even if the format supports bigger files.

I have logged this as P1 regression Bug #2200

Uncompressed exports in formats that have no (realistic) size restriction fail the 4GB trap for WAV & AIFF

One again - many thanks for the bug report tcdk - very much appreciated :slight_smile: :sunglasses:


And I’ve now also updated the alpha Manual for the upcoming 2.3.3 Audacity release - I added some stuff in there explicitly about CAF - and I added Glossary links for CAF, RF64 and RAW formats.


Wow, the developr who made ther 4GB error trap has already picked this up and fixed it. :smiley: :sunglasses:

I have only tested on W10 so far - but there it’s looking good - so I’m confident this will be fine for the upcoming 2.3.3 release.