How NOT to use a Zoom H4N

I’ve been happily using a Zoom H4N digital recorder since last October to record audio such as interviews. I use it primarily with a AT875 shotgun mic, which requires phantom power. It’s no problem, because the Zoom has a mode that provides it. But I’ve noticed the price you pay for using phantom power, at least with my AT875, is reduced battery life. WAY reduced. I generally can expect about two hours max of record time. And if you’re using rechargeable alkaline batteries, that drops to less than half an hour, as I discovered this morning.

But here’s a far worse discovery that I made today, which amounts to a serious design flaw with the Zoom: if you’re recording when the batteries die, you lose everything recorded on the clip up to that moment (it saves a 0 kb file, rather than a file with your data in it).

Bottom line: the Zoom H4n is a great recorder. Just don’t EVER let it run out of batteries, and it eats them like candy, at least if you’re using it with phantom power and an AT875.

18 thoughts on “How NOT to use a Zoom H4N

  1. Dan

    I’m less concerned about how fast it goes through batteries than I am disappointed that it loses the entire session when the power dies. This seems like a major design flaw to me. My JVC HM100 has run out of batteries a couple times while I’m shooting and it has some kind of graceful internal process that allows it to first save the file and then go black. (I’ve tested this by pulling the battery while shooting and discovered that in that case, it does NOT save the file).

  2. Shamar

    I have a slightly different problem. The battery did not die but I still lost everything. Has this happened to anyone else?

    1. chris kehnle

      ****this is not my original idea***** from Creative cow****** not looking for credit***********

      but it may be helpful

      I picked this up off of another post after my batteries died on Zoom 4hn at the end of a 1 hour interview. IT WORKS! Even if it reads 0 on your card!

      Dear H4n Mac users,

      I thought all was lost. My batteries ran out during a shoot (phantom power drain horror) and when I got back to the studio the file came up as 0kB. But thanks to hints from forum member aumeta I’ve managed to recover it. I thought you all should know it can all be done on a mac using freeware. Follow these steps:

      1. As soon as it happens remove the SD card and don’t use it. Unknowingly, I did use it, but for less time than I had previously recorded, so I was still able to rescue a large portion of my file. The SD card works a lot more like a tape than you might imagine. So when the batteries fail, it will start recording the next file at the start of the file that failed when your batteries went. This means if you’ve recorded, say, a 25 minute track, then the batteries have run out, and then you’ve recorded 2 more 2 minute tracks on the same card with new batteries, that you can still recover the last 21 minutes of your track. Clearly, it’s better to recover all of it, so next time, carry a spare SD card, and stop using the battery damaged one!

      2. Back in the studio, plug in your SD card into the card reader so it mounts.

      3. then open
      What we’re going to do is unlock some advanced features on another utility Disk Utility

      4. Once Terminal has started up copy and paste this in:
      defaults write advanced-image-options 1
      then press return

      5. Now open
      Applications>Utilities>Disk Utility

      6. Select your SD card in the list of drives, then click the New Image button

      7. What we’re doing is making a copy of the entire SD card, including all the empty bits. This allows the audio program we’ll use which can read RAW files to read the entire disk image as one enormous audio file.
      So, in the Image Format tab select “Entire Device” and have encryption set to “None” and save your disk image to a drive big enough to hold it.
      instructions with pictures are here (ignore the last section about file juicer it will not help your problem

      8. Now you’ve got a file that you can open in your audio program. One that can do it is a piece of freeware called Audacity which I found out from the forum post by johnsantic.
      Download the Mac version from here:

      9. Here I’ll adapt John Santic’s instructions from this post which saved some files for me which we’re’n’t 0kB (
      “The normal way to load an audio file into Audacity is to use the typical “File > Open” command. But they have another way to read in a file in case the header is damaged or missing. This uses the “Project > Import Raw Data” command. The next step is to select your new disk image in the dialog box that opens.

      10. Another dialog box should open which asks for audio parameters, this should be the same as the way in which you recorded the file:
      In my case this was:

      – Signed 24-bit PCM (ie 24 bit WAV on the zoom)
      – Little-endian [this means the audio data in the file is least-significant-byte first – it will be the same whether you recorded at 24 or any other bit rate]
      – 2 Channels (Stereo)
      – Start offset = 910 [this is the normal size of an H4n header, you should also try 0 and 2 if you are at 24-bit, or 0, and 1 for 16-bit]
      – Amount to import = 100%
      – Sample rate = 48000

      After you click “Import”, Audacity reads in the file. What you’ll probably find is large blocks of interference with audio files inbetween. If you find your lost recording, select that section, then use the command “File > Export” and save it under a different file name, with the same settings as your other original sound files. Joy! OK so you’ll probably lose a tiny bit at the end and at the start, but I’m sure you’ll live having recovered the vast majority of what you thought was lost forever

      11. If you don’t find your audio file in there this time do not despair. Instead just go back to the start of part 10 and enter in a different start offset (0, 1 or 2) and you’ll find a different portion of the audio you recorded will appear. I found my lost file on the second attempt when I set it to 0. Just keep on trying.

      I thought I’d messed up the whole project. Now I’m full of the joys of life, and thought I should share it with you all.




      Post subject: Re: Ran out of Battery and found only a 0Kb file? There’s hoPosted: Wed Jul 11, 2012 4:11 pm

      new to this board

      Joined: Sun Jul 08, 2012 6:12 pm
      Posts: 1
      I just wanted to affirm Jimmybulb’s post. Thank you! and to anyone else who did the behind the scenes work to make recovery possible, you rock! I spent 4 hours troubleshooting and downloading random freeware programs, but when I found this post, all was saved except about 15 seconds that were somehow corrupted. I ran the process twice through to see if the file would come out clean but it didn’t so I’m guessing somewhere in the process of my Zoom H2 becoming unplugged, the file became corrupted. I’m not really sure. I was recording a wedding and it finished. Because my batteries were dead, I had confidently plugged my zoom H2 into a power strip thinking it was the ultimate, safe source of power. Well, the sound board just happened to be plugged into this power strip and the sound engineer unplugged it after the wedding. The zoom power was cut off before I could stop recording. Note to self – set up at least 2 layers of good quality audio backup if possible.

      A couple helpful notes.
      1. Don’t stop trying if you get an audacity file that is ALL interference. You probably got the audio parameters wrong. The sample rate, offset, stereo or mono, little endian all seems to matter. I tried multiple settings before I got the right one and sometimes the audio came out as all interference (LOUD interference) or super slow low voices.
      2. All the freeware recovery programs I tried didn’t do what I wanted. Most recover deleted files, pics, etc.. not fix audio files without a header.
      3. I tried 0 for the offset, and it came out as pure interference. 1 and 2 both worked in my case. I was recording 16bit, stereo, at 44kHz.
      4. DEFINITELY choose a low percentage to import to test first. Setting it at 5% for about 7.4GB of a card only took about 30 sec to process on my macbook pro.

      Good luck!

  3. John

    I use my ZOOM H4N at least twice a week. Each recording session last AT LEAST 8 hours. When the DURACELL RECHARGEABLE batteries die, ( anywhere from 5 to 8 hours, depending on how new the battery is ),, I NEVER LOSE THE FILE.

    I used to lose files using the old H4 model, when the batteries are suddenly removed if the recorder falls, hits the floor, and the batteries were ejected. ( THIS WAS DURING MY NOVEL RECORDING DAYS WHEN I DIDN’T SECURE THE H4 PROPERLY )


  4. John

    My friend has the H5, and he lost a 12 hour file, when the power cord was suddenly disconnected.
    * You should ALWAYS have FULLY CHARGED BATTERIES in ANY machine when using wall power as a back up.

  5. John


  6. Maarten Andreas

    Guys & gals, I had the same problem and I figured it out!

    My Zoom H4n (firmware v1.90) had its power cord pulled while recording internal mics & line inputs (4 channels), which netted me a file 0 bytes in size. And I recovered it!

    The bad news: I can say with certainty that no file recovery program on the internet is going to help you in the event of power loss (net adapter pulled, batteries dead), pulling the card too soon, or any other reason for not having closed down the recording properly (which includes a faulty SD card). Don’t spend your time on it, don’t risk installing spyware and what not. Recovery is a manual process, of which I have not (yet?) dreamed up an automated mouseclick mouseclick done process for. Recovery is a manual process involving you.

    The good news: The reason I can say the former with certainty is because I figured out how the thing works, and how to recover data.

    Summary (TL;DR):
    You probably read this before, but to repeat it once again: If you experience a failure of any kind to gracefully stop the recording, your data is still there, somewhere, on the SD card. DO NOT START ANOTHER RECORDING AFTER YOU HAVE EXPERIENCED YOUR FAILURE! If you’re in the situation where your file shows 0 bytes in size when you put the card in your PC, data is still there, somewhere, provided it was not overwritten by you starting another recording. If such happens, swap out the SD card for another, go figure out the recovery later. Or make what’s called a disk image of the first and only partition (or entire SD card if you can’t figure it out) and get into the disk image later. (More on what a disk image is and why further below.)

    For the low price of me getting to keep your SD card and you sending two special beers from your country along, I’ll do it for you. Contact me on

    TL;DR technical details for the leet geeks:
    Zoom H4n firmware formats cards as FAT32, uses 512 byte sectors, 64 sector clusters, writes chunks of data alternating between 16 and 17 clusters in size. In 4CH mode it writes two .wav files, which it interleaves/multiplexes 2×16 clusters (16 clusters for each file), 2×17, 2×16, 2×17 etc. sequentially in one lengthy strip of data. Until a proper stop is done, no pointers in the File Allocation Table where the stream of data begins, no RIFF/Wav header prefixed to the stream; all written on hitting the stop button. So to find the start of the stream load the entire image of the partition (not disk, partition! much easier calculating) into for example Audacity by using the load raw data function (44.1kHz., 16bit, little endian, stereo), find the start of the audio you’re after, and calculate the start point in seconds into a byte offset in the disk image. All recordings start on a cluster boundary, so pick the nearest start of a cluster when you calculated your byte offset. Extract the data from your now precise on the cluster boundary-offset to another file (hex editor, dd, sleuth kit whatever), and demultiplex that with the C++ program pasted at the end. You now have your two stereo .wav files.

    The story:
    There’s a very sad design choice in the firmware of the Zoom H4n (other models are probably very similar) in that it writes all metadata the moment you hit stop. There’s nothing but raw (random looking) data written to the SD card, until you hit stop. No magic recovery program on the internet can help you, as there’s nothing an automated process can go look for. It will find old recordings you deleted before, but not the one you just lost.

    By saying metadata, I refer to any sort of location information in the File Allocation Table (FAT) system or any sort of RIFF/Wav header. I spend a lot of time looking for it, there’s none. Zero. All there is, is a filename in the index, with no data assigned to it, hence it being 0 bytes in size. All the metadata stuff is written when you hit stop, or when the file limit size is reached and a new file is created. Your recording is somewhere on the SD card, but no pointers to it, no header in front of it.

    Which means it is very hard to write a computer program to recognize where your data is. Writing such a program would involve it being able to differentiate a voice or music instruments from noise and clicks. And being able to do so at different audio settings (sample rate, resolution, channels). But locating the data is possible by means of utilizing a super flexible & programmable neural network! The key tool employed in this recovery is you yourself, your brain.

    But first, some on how the writing process works: As mentioned, the Zoom H4n (mine has fw v1.90) basically dumps raw data from the ADC’s (analog-digital converters) straight to the SD card. But, as I found out, it does so in a predictable pattern. When the device is in 4CH mode, it writes two stereo .wav files. Those two files are written almost like the SD card is a tape-deck, in that it writes a chunk of the first file, a chunk of the second file, a chunk of the first file etc. in a continuous strip. So it writes two chunks (one of each file) continuously while recording. Once you hit stop, it writes to the File Allocation Table (FAT) what chunk belongs to the 1st file, what chunks to the 2nd.

    If there’s an idea popping up in your mind now going “so, something somehow even numbers is first file, uneven something must be second file!”, then you are absolutely right.

    Before we go into this pattern, a few details on how the FAT32 filesystem works: The Zoom H4n wants SD cards formatted with a FAT32 filesystem and it very much likes to do the formatting itself. Reason for this, is that FAT32 can be used with multiple parameters, but the Zoom firmware wants a specific set of them due to how it writes data to SD card. Also it wants a very specific set of directory names to be there before commencing recording, which it makes during formatting.

    The main parameters it cares about are sector size and cluster size. Any storage medium, which includes hard disks and SD cards, is essentially like a tape deck in that it has a start and an end, with places in between. All any storage media can do is save & read what’s called bytes. Zeroes and ones. We call a group of 8 zeroes or ones a byte. A byte is the most elementary unit of data in a computer.

    What filesystems like FAT32 do is providing a mechanism to manage this enormous strip of bytes, into what we now know as files and directories. A filesystem functions like an index, for example bytes 956 to byte 3065 are /groceries/shoppinglist.txt, and bytes 5364 to 5631 is /school/todo.txt

    In FAT16/FAT32, those bytes are not referred to individually, but by what Microsoft has named sectors and clusters. How big they are is configurable when you format a drive/card/thumbstick with your PC. The Zoom H4n wants to format SD cards itself because it wants a sector to be precisely 512 bytes and a cluster to be precisely 64 sectors (which makes a cluster 32768 bytes in size).

    When the Zoom H4n is recording 4 channels at 44.1kHz samplerate and 16bit resolution, as mentioned above it writes two stereo .wav files interleaved. It writes 16 clusters of data for the first .wav file, 16 clusters of data for the second .wav file, 17 clusters of data for the first file, 17 clusters of data for the second file, then the cycle start over.

    16 clusters is 524288 bytes. When sampling at 44100 times a second, with 16bits (two bytes) of resolution times two because stereo, each second of audio takes 2 bytes * 2 channels * 44100 samples = 176400 bytes. If we divide 524288 bytes by 176400 bytes we find that each chunk (16 clusters) is about ~2.97215 seconds worth of data.

    For those of you who already managed to load their disk image into Audacity and listen to their lost recording that way, you noticed the audio cuts back and forth between mics and line-in every 3 seconds or so. Now you know why: You are listening to a strip of stored data which is the two .wav files interleaved (multiplexed).

    So, how to get this strip of data and demultiplex it?

    I’m a little short on time now so I will edit & expand this section later (and deliver on my promise I would tell you what disk images are), but for now, you’ll have to do with the TL;DR (too long; didn’t read) summaries above. Then use the C++ program I wrote below to cut up your multiplexed stream of data into two files, which you can then load as raw data into Audacity. Find a programmer friend or ask your neighbour if you can’t figure it out! For the low price of me getting to keep your SD card and you sending two special beers from your country along, I’ll do it for you. Contact me on

    I have to get to work now cya later!

    #include // memset()

    #define ZOOM_FAT32_SECTOR_SIZE 512 // In bytes
    #define ZOOM_FAT32_CLUSTER_SIZE 64 // In sectors
    #define ZOOM_INTERLEAVE_SIZE 16 // In clusters
    #define ZOOM_INTERLEAVE_SIZE_DEVIATION 1 // Zoom H4n v1.90 alternates between writing 16 clusters of each file, writing 17 clusters of each etc.

    using namespace std;

    int main(int argc, char *argv[])
    string infile;
    string outfile[2];

    // Count of arguments is the program name itself, plus the arguments to it;
    // from argv[1] and onward is interesting to us
    case 2: // One argument in addition to the program name
    infile = argv[1];
    outfile[0] = infile + “.m.wav”;
    outfile[1] = infile + “.i.wav”;
    case 4: // Three arguments in addition to the program name
    outfile[0] = argv[1];
    outfile[1] = argv[2];
    infile = argv[3];
    cout << "Usage: [outfile_mics outfile_line] infile" << endl;
    return 1;

    cout << "Demuxing file " << infile << endl;
    cout << "to files" << endl << outfile[0] << endl << outfile[1] << endl;

    ifstream interleaved(infile);
    ofstream deinterleaved1(outfile[0], ios::out | ios::app | ios::binary); // Input-output stream,
    ofstream deinterleaved2(outfile[1], ios::out | ios::app | ios::binary); // out, append, binary

    for(uint32_t i = 0; !interleaved.eof(); i++)
    if((i / 2) % 2 == 1)

    char buffer[chunksize];
    memset(buffer, 0, chunksize);

    cout << "Writing chunk " << dec << noshowbase << i; // No endl
    cout << " starting at offset " << hex << showbase << interleaved.tellg() << endl;, chunksize);

    if(i % 2 == 0)
    deinterleaved1.write(buffer, chunksize);
    deinterleaved2.write(buffer, chunksize);

    cout << "Deinterleaved " << dec << noshowbase << interleaved.gcount() << " bytes" << endl;

    return 0;

    That's it for now folks! Soon up on github too. But got to get to work now.

    1. Maarten Andreas

      Took me a while to deliver on my promise of completing the howto & story! My bad for that, life got hectic.

      I have taken today for writing up a doc with the code over at GitHub:

      As I write this it only covers 16-bit recordings but tomorrow or next week I’ll write up the details on 24-bit recordings. The text & the program code is a work in progress, so check GitHub for changes!


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.