Recovering Data from Edirol R-4

Hi

I've got asked to recover data from an Edirol R-4 whos mains power has gotten unplugged during recording; the WAV files appear on the disk but are 0 kB. Any ideas? I've tried a couple of FAT-32 recovery tools but none of them showed anything useful. A friend of mine told me that he was able to recovery data from a similar event but he didn't recall what software he used. Thanks!

Samuel

> unplugged during recording

FAT tools may be no use. It appears this machine updates the FAT *after* you press STOP.

Get a sector editor/copier. Copy all non-zero sectors to a new file on a PC. Look for "WAV"; IIRC this will mark the header of each WAV file (assuming this too isn't written at STOP-time). Copy from one WAV to just before the next; this will be "a track". Or maybe a track plus some garbage you can readily trim-out in any DAW.

This assumes the files are not fragmented. The actual FAT (not just directory) should indicate where sectors were not written consecutively. If you did not grow up reading FAT, this may be hard to decipher.

The great saving grace: if the tracks are truly uncompressed WAV, then once you know/guess the sample width and rate, you can gimmick the header and just play it. If fragmented, you will have parts of tracks in the middle of parts of other tracks: if not too fragmented, it is tedious but doable to cut-paste back into correct sequences. Zoom way in on the "cut", try to find the usually severe transient where one track butts to the other.

PRR said:

> unplugged during recording

FAT tools may be no use. It appears this machine updates the FAT *after* you press STOP.

Click to expand...

That's depressing. I had expected the folks at Roland/Edirol to know better than that.

JD 'pre-allocate' B.
[and it's not like the two extra sector writes to FAT and WAV header are going to wear out your Flash, at least not on cards produced in the last three years]

Thanks, will try that.

I had expected the folks at Roland/Edirol to know better than that.

Click to expand...

I'm working with Magix Sequoia and they guarantee that one won't loose more than a few ms--that's quite soothing for live recordings. Merging Pyramix (the other big player for classical recordings) will loose the entire recording.

Samuel

I just found out the hard way that the Zoom H2 exhibits the same symptoms (0k WAV files) after briefly losing power due to its stand collapsing somewhat less gracefully than I had intended. The recording wasn't hugely important (or else I'd not have used the H2, particularly not without a backup), but annoying nonetheless.

PRR said:

The great saving grace: if the tracks are truly uncompressed WAV, then once you know/guess the sample width and rate, you can gimmick the header and just play it.

Click to expand...

I had just re-formatted the SD card, so there was no fragmentation. Copied an image of the entire card to disk with dd, added a WAV header with sox, removed the binary junk at the beginning and the echoes of recordings past from the end with audacity and all's well again.

Still, this problem could have been easily avoided by the firmware.

JDB.

In my case I think I'll have to give up. The disk is 40 GB and it has not been formated for a long time--there are numerous valid and deleted WAV files around so at least half of the disk is non-zero. It would be a tremendous effort to collect the data.

BTW, Edirol support was of zero help; they just suggested to run Check Disk.

Samuel

That's just depressing.

Here's some free advice for the likes of Edirol and Zoom, if they're listening: it is trivial to reduce the chances of losing data on a write-mostly device like a dedicated HD/Flash recorder.

• When the customer presses REC (or, on better devices, ARM), allocate the largest file that fits on disk/Flash (2GiB/4GiB for WAV, "all of the free space" for BWF). Don't write any data, just allocate the sectors in the FAT. For bonus points, allocate all free space with such files if you're using WAVs
• Write a WAV/BWF header to this file with a length corresponding to the file's size. Flush the drive's cache at this point
• When RECording, write the audio samples to the data portion of this file. Don't touch the FAT and/or the header just yet
• When recording is STOPped, write a new WAV/BWF header with the correct size, and truncate the file's allocation size in the FAT.

This way, if the power is interrupted at any point, you end up with a valid WAV/BWF file with all of the customer's data, possibly with some garbage at the end (assuming you handle cache flushing properly). As a bonus you minimize FAT sector writes, which on some older media is a Good Thing. And while you could periodically update the file's header to reflect the actual amount of data written, that violates the KISS principle and sets you up for nasty surprises when (not if) your media's built-in controller gets clever with write re-ordering.

The worst case scenario of my proposed approach is that you get a power glitch and can't immediately restart recording because the oversized files need to be trimmed. Hands up everyone who thinks that (a) that's a likely failure mode and (b) that behavior is worse than overwriting data from the recording that was just interrupted.

JD 'not exactly rocket science' B.