I did a recording of about 8h 5m (timer). But sometimes after that the computer must have crashed, because i needed to reset it (didn’t woke up from standby). After reboot and restarting Audacity, it offered me to recover the data which I gladly accepted. It took a while - but as far as I can tell, it worked. I checked the start and end and everything seems to be fine (total length is also exactly 8h 5m, like i specified using the timer).
Now the first thing I wanted to do was to save the uncut recording to a WAV-file (44.1 kHz, 16 bit, stereo) - just to be sure not to mess something up. The export finished without any errors, producing a file with about 4.7 GB file size. After that I closed Audacity.
BUT unfortunately players (VLC or MPC-HC) only show and play 1h 19m. So the data seems to be there, but not accessible.
I re-imported the file using the raw data option, providing the correct settings for the format. It takes very long, but works fine. Like before I can access the whole recording. I checked the position at 1h 19m - but there are only some seconds of (intended) silence, which is part of the recording - no cracks or something like that. Audacity itself can play that section without any problems. Afters cutting about 10m from the end and a few seconds from the beginning, I again tried to export the file as WAV. Again there are 4.6 GB written, but now only 1h 09m(!) are accessible by players. Strangely the problem “moved” exactly 10 minutes, the same amount I cut from the end at 7h 55m to 8h 5m. If I export as AIFF at least MPC-HC shows the full/correct length - but still can’t play beyond the mentioned time.
Finally I found a work-around by exporting as FLAC - which workes just fine (using ffmpeg to convert back to WAV - because that’s what I need).
But still I’m wondering what could be the problem?
Software: Windows 7 x64, Audacity 2.0.6
Hardware: Intel Quadcore CPU, 8 GB RAM, Realtek OnBoard sound card (using the SPDIF IN for the recording)
If the sample rate is 44100 Hz (the default in Audacity) and the recording is stereo, that works out as about 12 hours.
You are very lucky
The reason that you got away with it is because you are using a 64 bit operating system, but it is still not really a “valid” WAV file (it does not comply with the WAV format specification). Had you been on a 32 bit OS the WAV file would have irreversibly corrupted.
I’m pleased that works for you, but it is not a very reliable workaround. There have been a lot of problems for the guys that make the Flac encoder/decoder to make it work reliably when the uncompressed size if greater than 4 GB, and as far as I’m aware it is still a bit flaky.
but please note that it still does not comply with the WAV format specification. If the resulting WAV file imports correctly into Audacity, then ffmpeg has probably converted it to RF64.
A “better” (more reliable) workaround is to export it in sections (for example, 2 files of around 2.4 GB each). One way to do that is to select half of the track in Audacity, then use “Export Selected Audio”, then repeat for the other half.
That’s what I did now - and it worked as expected!
Also the FLAC file I exported before created some warnings (“sample/frame number mismatch in adjacent frames”) when I used ffmpeg to transcode it to other formats.
Now using the RF64 file as input these warnings are gone, too.
Yes that’s true, but BWF can get round that by linking the data across several files. This means that even 32 bit apps with no special support for the format (just normal WAV file support) can still play each of the linked files in full. An application that supports BWF would play continuously through the links.
I’m not clear - are we talking abut the size of the input data? There seems to be a lot of contradictory information in circulation about that. Flac 1.3.0 (which Audacity 2.0.6 uses) was supposed to add support for input from RF64, so one might think that 4 GB of raw PCM would not be a problem, but perhaps it still is?
It’s been said that eac3to can definitely accept input larger than 4 GB for FLAC encoding.
There seems to be a lot of contradictory information in circulation about that.
That’s what I mean by “a bit flaky”. The 4 GB limit issues for Flac should all be fixed now, but in my other life I still sometimes encounter 4 GB limit problems, and it is often difficult to pin down exactly when, where or why the problem occurred. Fortunately this is becoming much less common, but I’m still cautious around 4 GB, especially when expensive work is involved.