Will do.

I just had a thorough look through the uncorrupted sample set, and there are very few that are usable. They seem to be partially muted. I think the best decision here is to scrap the data set. I had 12 units out last year and have looked through about 10 sample sites from my most recent field season and haven't run into this kind of data quality issue yet, so I am a little surprised. I think that there was something about the way I set up the unit or the microphone was faulty or something along those lines. I would be happy to send you the sd card via post - from Maryland, USA, but I just don't want to waste your time on this one. Thanks so much for the offer to look further into it!

@Alex Rogers After trying to figure out why that link played, I see that I just plainly sent a file from the wrong folder. I sent you a file that was in the folder of un-corrupted files. Here is a truly corrupted file: https://www.dropbox.com/s/htbozf0ktblempp/20190713_075300.WAV?dl=0 I think the noisiness is a different problem, and appears to be unique to this recorder. I have been trying to use sox commands and other ways of editing the header, but I haven't had any luck.

That's great news. That file I sent was out of Recuva, and I only changed the file extension. But here's another one that I haven't changed at all. https://www.dropbox.com/s/0u4oj1g9sij0rz9/20190704_103800.WAV?dl=0 If you have an opinion on the easiest way to add the header I would appreciate it. I've found a few plausible methods through internet searching, but this will be my first go at it. Thanks!

Thanks. I could use some help. I was hoping that just assigning the correct encoding type would help in Audacity, but I couldn't hear anything when set to signed 16-bit PCM (as opposed to when I used unsigned 8 bit PCM). Any suggestions for application or R package (tuneR function?) that could help me do as you suggest - dump file contents as binary and read sequentially - would be much appreciated. Here is an example file that I've changed the file type to RAW. This is a 60 sec recording with all the AudioMoth default recording options. https://www.dropbox.com/s/wshc3p4q0i9r0kc/20190801_171400.RAW?dl=0

Hi Olivier, I did test out the cheap one Ultra microSDXC for a few days outside my apartment and listened to a few sample recordings and found that it did ok. Although it was a really short set of recordings and I did not analyze the data in depth, so I couldn't really test them out. In another post, there was a report of no difference between the SDXC and the cards on the recommended list. Regardless, I was feeling skittish and ended up finding a better deal on the SanDisk Extreme microSDHC, which was only US$3 more expensive, and so I am going with that. https://www.bhphotovideo.com/c/product/1375051-REG/sandisk_sdsqxaf_032g_gn6ma_extreme_microsd_32gb.html. It's on the recommended list and I don't want to risk my data. So in the end, no real conclusion on the Ultra microSDXC (which appears to satisfy the speed class 10 requirement, but was not recommended for whatever reason)! Sorry to hear you lost your data. Based on my memory of reading through these discussion boards the AudioMoth team mentioned that the issue with the cheaper cards is that they are able to record the sound, but the more inexpensive cards may at times be overloaded and have to overwrite small sections. This means that in your case you should have recorded at least something, whether a jumbled mess or not, some data should show up no matter how cheap the card. This makes me think that the issue is not the card, but something else. Best,Adam

Interesting. thanks.

Thanks for reporting your experience.

Hi, it's been a while since this post, but if you get this, could you tell me if these cards worked for you in the long run? Did you use just one or several? Thanks

Thanks for the info!