Very big files cut off at 7.09GB (7,620,480,044 bytes)

PRE-NOTE: you can save time by generating silence instead of noise and probably still get the same bug

reproduction steps:

  1. generate 12hrs noise (it is mono 44100Hz 16bit)
  2. create new mono track, select it
  3. generate 12hrs noise (it is mono 44100Hz 16bit)
  4. click top track, convert to stereo
  5. export/export as wav

expected result:

file is 12hrs long

actual result:

file is 5:14:12 long (7.09 GB (7,620,480,044 bytes))


duration confirmed by vlc, sox, windows explorer

both tmp folder and export folder are on ntfs partition with 180gb free.
2.2.2 windows 10 64bit

fun fact:

  1. I was able to create a 6hr long mono noise track correctly and it is only 1.8GB in size.
  2. Mono 12hr also works (3.72GB).
  3. Stereo 6hr (duplicating 1st track instead of steps 2 & 3) also works (3.54 GB (3,810,240,044 bytes)).
  4. Stereo 6hr (duplicating 1st track instead of steps 2 & 3) does not work (7.09 GB (7,620,480,044 bytes))
  5. Silence (generate/silence) 24hr mono 44100Hz 16bit ends up as a 10:28:24 file (7.09 GB (7,620,480,044 bytes))

This appears to be a file size issue, not a duration issue.

I always used the fuzzy values of 3GB and 6GB. That’s where the WAV addressing scheme runs out of zot (technical term). Some legacy systems and services will not recognize a WAV file over 3GB. So, in my opinion, you should never plan on unconditionally stable WAV files over 3GB. I have a portable, personal stereo recorder that uses the 3GB value for extended recordings (2.78-something something??)

This also bumps into the recommendation of not using Audacity as a surveillance recorder—to include using it to record six hours of music or other “air checks.”

As I understand it, Broadcast WAV does the same thing. It’s enhancements are more bookkeeping: environment tags, editing info, etc.

I recently ran into Apple Core Audio (CAF), which appear to be WAV files without the limits. Of course, nobody can open them.


Thank you for the info about limitations. I had no idea!

From Wikipedia:

The WAV format is limited to files that are less than 4 GiB, because of its use of a 32-bit unsigned integer to record the file size header (some programs limit the file size to 2 GB)[citation needed]. Although this is equivalent to about 6.8 hours of CD-quality audio (44.1 kHz, 16-bit stereo), it is sometimes necessary to exceed this limit, especially when greater sampling rates, bit resolutions or channel count are required. The W64 format was therefore created for use in Sound Forge. Its 64-bit header allows for much longer recording times. The RF64 format specified by the European Broadcasting Union has also been created to solve this problem.

However, the limitation in Audacity seems to have a different origin, since saved files can go way beyond 4GiB.

If a user tries to save a file that will exceed the file size limitaiton (which appears to be about 7GB), then the user should be warned or the action should not be allowed.

If I save a stereo 12h file as w64, then it gets cut off at the same file size and can’t be played in VLC (foobar2000 can do it though even though it doesn’t show the file’s duration). If I save 10 minutes as w64, then I see the duration (vlc still can’t play it).

There seems to be something else that limits file size other than WAV-specific things.

However, the limitation in Audacity seems to have a different origin, since saved files can go way beyond 4GiB.

Wikipedia is correct. There is a 4 byte (32-bit) ChunkSize field I the [u]WAV file header[/u]. With 32-bits, you can’t “count higher” than 4,294,967,295. (And, there are a couple of other 4-byte Chunk Size fields.)

WAV spec doesn’t define what happens with a invalid WAV file. I agree it would be “nice” to get a warning. Typically, the most-significant bits are simply lost and the file-size “rolls over”. So a ~5MB file would be reported as ~1MB, etc. …So the file playing time looks “random”, and depending on the software some “random” amount of data may be lost.