Zero size .wav files

Jeeves · 10-21-2019, 04:42 PM

I've used Reaper happily for a few years now, but now I need help, or need to report a bug.

Last week, I used Reaper to record a multi track concert performance. I recorded the rehearsal (as I usually do for backup), then the live performance. When I came to edit the show, I found some of the .wav files have a zero size. The rehearsal was perfect, but the start of the live show was lost.

In detail, I was recording two stereo tracks at 96k to an external USB drive from a Windows 10 laptop using Reaper v5.79/x64 and Dante Virtual Sound Card, a configuration that has worked flawlessly for over 2 years.

There were no error messages, or any other indication that there was a problem. As indicated above, the rehearsal recording was fine. The concert recording ran for about 75 minutes, so a new file was created approximately every 31 minutes.

However, the first 3 files of the recording ended up with a size of zero, two from one track and one from the other. The later files are fine.

Has anyone come across this situation before? Maybe there is a problem with the drive...

I have another, critical recording to make tomorrow. I have replaced the USB drive, and will record to two drives from two laptops, but I would really like to know what happened last week.

Can anyone shed light on this?

serr · 10-21-2019, 05:14 PM

I remember someone posting a similar thread a while ago around here and the conclusion was that Windows was caching files locally when using external drive volumes. The scenario was Windows either crashed or was interrupted by an unexpected shutdown and the temp cache never got written. It was either a poor choice for default made by the Windows team or it was easy to end up setting and not realize. So... a bug in your OS.

Jeeves · 10-21-2019, 05:46 PM

Thanks Serr, for your very prompt response, but I see 3 problems with your conclusion:
1. Windows did not crash or exhibit any unusual behaviour (not that that is conclusive in itself).
2. Reaper continued to record the remainder of the concert successfully and continued to run throughout the concert without indicating any problem.
3. Continuous flashing of the drive activity light suggests that there is continuous write activity to the external drive (as opposed to cashing the data elsewhere).

At the end of the concert, Reaper asked if it should save all 9 files, reported no problems in doing this, then happily saved the Reaper project before I closed the application. All nine files appear in the directory, along with the peaks files, and the file names include the relevant date and time information - it's just that the file size shows as zero, and on later opening of the project, Reaper reports those files as being off-line.

I'm more inclined to believe some sort of failure in the drive's structure.

Jeeves · 10-21-2019, 05:49 PM

Sorry, not 9 files, 6 files.

lunker · 10-21-2019, 06:33 PM

May or may not be relevant:

For the first time in more than 10 years, I had a corrupt RPP file this weekend. (Luckily, I could recover it from the automatic backup copy)

When I compared the corrupt file to the backup, the last several lines (maybe 1/4 of the file) were missing. Even though I saved the RPP before exiting Reaper, it appears that the file wasn’t completely written right away, and I accidentally shut off the power strip before the PC had completely finished shutting down (total brain cramp -- I started the shutdown but got hurried/distracted and hit the power button without thinking).

So perhaps the files weren’t written yet when you shut down?

Jeeves · 10-21-2019, 07:27 PM

Well, I did exit Reaper just after saving the project, and shut down the laptop shortly after Reaper closed, (but not in a great hurry), so your theory could apply here (though the rpp file was OK).
Perhaps we could ask the software authors if there is any way that Reaper could exit before it knows that any file close action is completed.

serr · 10-22-2019, 11:19 AM

Quote:

Originally Posted by Jeeves

Thanks Serr, for your very prompt response, but I see 3 problems with your conclusion:
1. Windows did not crash or exhibit any unusual behaviour (not that that is conclusive in itself).
2. Reaper continued to record the remainder of the concert successfully and continued to run throughout the concert without indicating any problem.
3. Continuous flashing of the drive activity light suggests that there is continuous write activity to the external drive (as opposed to cashing the data elsewhere).

At the end of the concert, Reaper asked if it should save all 9 files, reported no problems in doing this, then happily saved the Reaper project before I closed the application. All nine files appear in the directory, along with the peaks files, and the file names include the relevant date and time information - it's just that the file size shows as zero, and on later opening of the project, Reaper reports those files as being off-line.

I'm more inclined to believe some sort of failure in the drive's structure.

I didn't make any conclusions initially...
But I'll make a couple now.

#2. That would still follow if the OS were caching the files. Reaper wouldn't and shouldn't know about this. It would be a transparent cache by the OS.

#3. Were you watching it during while it would have been writing the files in question?

If the drive were genuinely failing, you would get a write error or device not responding error. The "pinwheel of death" as people like to call it. (It just means an unexpected wait for one of the hardware devices in the system.)

So... Reaper saw the handshake for a successful write.
The cache for any external volume feature being turned on by default as other Windows users discovered would explain everything.

My conclusion is that if your filesystem shows a file of 0 size, that file is really 0 size now. It still could have a root cause of drive failure. (The scenario being that the file was complete and intact at the end of that night but suddenly not there when you next fired up that drive.)

But this WAS mentioned as a recent Windows faux pas that bit someone else on this forum in the ass and lost them a live recording. So I'm passing that along.

Reaper writes an end of file mark with every block of data written to the drive. That means the recording and file would be intact up to the point of power failure, should that happen. It's either it was being cached somewhere else and never got copied at the end by the OS or the drive really did fail between powering it off that night and powering it on later.

If you think the drive is corrupt... Recovery techniques like reading the whole drive as data and sifting through for what looks like files would be the thing to try.

Good luck and my condolences for the loss.

lowellben · 10-22-2019, 12:06 PM

I'm about to make your life better OP

Here is what I suggest ASAP.

Go to device manager and find the USB drive.
Go to policies.
Change write-caching policy.
Enjoy no more zero files.

lunker · 10-22-2019, 01:26 PM

Thanks!

I just did.

clepsydrae · 10-30-2019, 09:59 AM

Hey serr --

Quote:

Originally Posted by serr

If the drive were genuinely failing, you would get a write error or device not responding error. The "pinwheel of death" as people like to call it. (It just means an unexpected wait for one of the hardware devices in the system.)

...do we know that this is true for reaper? E.g. reaper has that unfortunate behavior where if the disk fills up when recording or rendering it doesn't complain and instead appears to have worked fine (here, here, and here, and my sig :-) ) which makes me wonder what it actually does if there is some other kind of failure while recording?

clepsydrae · 10-30-2019, 10:01 AM

Jeeves -- how close to full is the disk you are recording to? E.g. when you finish a session, how much free space is there, and what is the total project size you just recorded?

I'm wondering about contrived scenarios where e.g. you record to reaper's default location, and at the end you say "save these files" or "save project here", which triggers a second copy to be made (at the final project destination) and that causes the disk to fill which causes zero-length files, and reaper maybe doesn't mention it...

karbomusic · 10-30-2019, 10:22 AM

Quote:

Originally Posted by clepsydrae

Hey serr --

...do we know that this is true for reaper?

Running out of space for a non-system/OS disk write isn't a storage failure in the truest sense of the word so I think it's a good ask and may not be logged by the system.

CreateFile() which is likely what gets used here, will create a zero-byte file IIRC if you call it and not subsequently call WriteFile() to write data but it's just a side point. That's why I was curious about the create time and modified times of the files in question which I think the OP answered. I do think there is something obvious we don't yet know.

It would be smart to double check the Windows application and system event logs if not mentioned already. Because if such a failure did get logs, that's where it will be.

serr · 10-30-2019, 10:34 AM

Quote:

Originally Posted by clepsydrae

Hey serr --

...do we know that this is true for reaper? E.g. reaper has that unfortunate behavior where if the disk fills up when recording or rendering it doesn't complain and instead appears to have worked fine (here, here, and here, and my sig :-) ) which makes me wonder what it actually does if there is some other kind of failure while recording?

I'll modify that to: You would get an error if you tried to record to a directory that wasn't there or a device that wasn't responding at the time you pressed record.

I guess I haven't ever tried running out of drive space during a recording or render. Evidence sounds damning... Maybe I'll have to try it.

insub · 10-24-2019, 06:51 PM

Quote:

Originally Posted by Jeeves

At the end of the concert, Reaper asked if it should save all 9 files, reported no problems in doing this, then happily saved the Reaper project before I closed the application. All nine files appear in the directory, along with the peaks files, and the file names include the relevant date and time information - it's just that the file size shows as zero, and on later opening of the project, Reaper reports those files as being off-line.

If the ReaPeaks files are intact, I think REAPER should be able to rebuild the audio files from them. I'm pretty sure I've recovered audio this way before.

I'm not familiar with Dante equipment. Do you have to use a router with it? Perhaps there was a Dante network failure?

serr · 10-24-2019, 07:01 PM

The peak files are image files to let you view waveforms without reading live from the actual audio all the time. They're a bit low res - notice how the view switches to live when you zoom in to the sample level.

There are some creative audio apps that will generate audio from waveform images but it's going to be telephone-like crude.

Jeeves · 10-29-2019, 09:22 PM

Here's some more evidence that might point to a disk drive problem, though I'm still not totally convinced.
I've now had time to look at earlier recordings on that drive. There were three concerts that I'd not yet processed. Each was multiple sessions, (stop and save at intervals in the performance).
The oldest event was fine, all files present and correct.
The next had one file of zero length, as before, at the start of the session, and should have been a gigabyte size.
The next had every .wav file of zero length, and over two sessions. Note that only .wav files were impacted, peaks files were OK, and whereas for the other recordings it was always gigabyte files, this was all the files.
So, the problem ran over three totally different events at different venues on different days. I would suspect physical damage to the disk drive during transit, impacting the file management tables on the drive, but why only .wav files?