ZOOM H4n Material lost on SD Card

[Carlo Siegfried]

Dear Adam!
Thankyou for our reply and your findings! I am excited to hear what the company in the UK can do…
Good luck + best wishes
Carlo

[Adam Loveday-brown]

Hi All.

The company I used in Epsom UK were able to successfully recover all of my lost data! This was for a multitrack recording:
Stereo LR
Mono 1
Mono 2
Mono 3

For some reason the Zoom H6 unit shut down without loosing power, but it didn’t correctly finalise the recording.

This thread has been invaluable in making this happen, and the engineer wouldn’t have gotten there without all the work of everyone on here, so thank you. This has really saved my bacon.

The company are called OnTrack. It’s a proper company, I went there. It’s all very CSI. They take data protection very seriously:
https://www.ontrack.com
I was dealing with a guy called Joe Rogers.

Good luck!!

Adam

Video production dude, London

[Michael Angelo]

Had the same issue as everyone here, power cut off, then after putting in new batteries the next recording is corrupt. I used the mac disk image trick with Audacity to access the raw data and reveal the sound is there:

https://zoomforum.us/viewtopic.php?t=17991

Unfortunately when Audacity recovers the audio it not only repeats but cuts out every 5 seconds or so on both the originally corrupted audio file but also on all the other previous recorded audio files on the card so hoping there is some way to parse the data correctly and fix this?

Would be so grateful for any help !

– MA

Harvest the compromises…

[Oriol Nieto]

Hi all,

I had the same problem (i.e., recovering a raw file with 2 stereo tracks from a Zoom recorder and split it into two different stereo WAVs), and I managed to write a little Python script to successfully do the job.

You may find it here:
https://github.com/urinieto/rawzoom/blob/master/notebooks/Convert%20RAW%20to%20WAV.ipynb

The trick was that segments alternate in size every two contiguous segments. So, the raw signal looks like this:
– track1_segmentsize1
– track2_segmentsize1
– track1_segmentsize2
– track2_segmentsize2
– track1_segmentsize1
– …

In my case, where the input was recorded at 44.1kHz, the amount of audio samples for the two segment sizes are:
segmentsize1 = 131072
segmentsize2 = 139264

This will likely be different if you have a 48kHz input signal (might be a matter of multiplying it by the ratio 48 / 44.1).

Happy to help running the script in case Python is not a language you speak ☺

Hope this helps!
Oriol Nieto
Twitter: @urinieto

[Lee Nicklen]

This is an old thread, I know. But, there is a solution and it works.

So, this is for anyone who finds this thread and has lost a recording due to removing power from a Zoom [H2 or any other] recorder without stopping the recording first.

The program is called TestDisk & PhotoRec. And it’s GNU software license, meaning it’s free. But works on a donation process. So, please donate – if you can! I did!

Here is the site:

“TestDisk Download – CGSecurity” https://www.cgsecurity.org/wiki/TestDisk_Download

 

It recovered my recording (MP3 VBR) automatically without having to do or tell the code anything. It’s very clever, and will automatically be able to find the data file and know that its header/chunk data when it’s save properly is missing and so therefore must be the file that needs recovering.

 

I used the Windows 64bit version. No need to install anything, just extract program files and run the program.

 

Enjoy! 👍😊

[Jason Stockton]

How did you figure out the segment size?

[Oriol Nieto]

By listening to the audio, visualizing the samples in Audition, and by some trial and error 🙂

[Maarten Andreas]

Anyone that got their recording back by means of PhotoRec or any of the many commercial or spyware-loaden tools on the internet, they just got really lucky.

Why?

What happened in those lucky cases is the undelete/recovery program recovering a file that existed prior your most recent recording. And this now undeleted file that predates your 0-bytes recording happened to be in the same location as were your latest lost 0-bytes recording was written. Or maybe partially overlap with it.

FAT16/32 operate like a book index, stored as a tree: At the front of the drive there’s a root node that always exists, which points to other nodes, which point to other nodes etc. much like branches of a tree. Now when you delete a file, only the chain of connections from this root node to the node holding the file information is severed somewhere. But even though the branch is no longer connected to the root, it remains there, floating around, until it gets overwritten by something else.

So on deleting a file the node holding the file information and the pointers to where the data is stored is still there, it’s just no longer connected to the root node. Both this node holding information and the data elsewhere pointed to by this node remain on the drive until they are overwritten by the creation of a new file.

It is these severed nodes that recovery programs go look for. They have predictable shapes & sizes, hence an automated process can spot them.

When you hit record on the Zoom, none of these structures are written. The recorder starts writing data to disk but there’s no pointer to it yet. Headers & pointers are all written when you hit the stop-button. But during the recording, the device does write data already somewhere on the disk, but no node describing a start & end exists.

If PhotoRec or something else recovers anything, you just got lucky because it found a set of nodes that were describing a file you have created & deleted before. It has nothing to do with the 0-byte file(s). Just by sheer luck, the data of this prior created & deleted file happened to be stored in the location your new but unfinished/lost recording was written to.

If this prior created & deleted file started at the exact same spot and is equal or greater in length than your lost recording, you get your data back. If it’s shorter or starting points not match, you only recover part of your lost recording.

If you get lucky, your tool recovers a node of a much older and already deleted recording that by sheer coincidence partially overlaps with your latest but corrupted recording. It not actually recovered your lost recording, it recovered an older file that was in the process of being overwritten by your last recording.

I can say with certainty, none of these tools will really work for this particular problem.

For more information & howto recover your data, read here: https://github.com/merethan/zoom-H4n-recovery