Creative Communities of the World Forums

The peer to peer support community for media production professionals.

Activity Forums Audio ZOOM H4n Material lost on SD Card

  • Carlo Siegfried

    July 31, 2018 at 8:40 pm

    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

  • Adam Loveday-brown

    August 20, 2018 at 11:41 am

    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:
    I was dealing with a guy called Joe Rogers.

    Good luck!!


    Video production dude, London

  • Michael Angelo

    August 3, 2019 at 7:30 pm

    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:

    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

    March 16, 2020 at 4:39 pm

    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:

    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

    August 22, 2021 at 4:26 pm

    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”


    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

    October 12, 2022 at 12:13 pm

    How did you figure out the segment size?

  • Oriol Nieto

    October 14, 2022 at 7:06 pm

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

  • Maarten Andreas

    April 17, 2023 at 1:05 pm

    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.


    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:

Page 8 of 8

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy