©2019 Open Acoustic Devices

Sep 17

File encoding question - fixing corrupted wav files

10 comments

Main question: What is the encoding used for wav files? Unsigned PCM 8-bit, or is it another type?

 

Context:

I accidentally formatted my sd card with data I had yet to download. I was able to recover using a recovery wizard (Recuva), but my files are now corrupted. They have the same file size, but most audio players give an error message about a missing codec. I found a suggestion to change to a RAW format and import into Audacity. Using the defaults this works and I can barely hear recorded sounds but only through a significant amount of white noise. This indicates the the data is there. (I had downloaded about half of the data - 9 days of recording - before some technical glitches, so all was not lost, but it would be nice to get the full dataset back.)

 

The default file specification in Audacity is:

Encoding: Unsigned 8-bit PCM

Byte order: Little-endian

Start offset: 0 bytes

Sample rate: 44100 Hz

 

Are these the correct file properties for AudioMoth wav files?

They are signed 16-bit little-endian PCM samples. The WAV file header is always 360 bytes long and the data starts immediately afterwards. The first four bytes of each file header is 'RIFF' so in the worst case, dumping the file contents as binary data and reading through sequentially will recover all the data. Let us know if you need some help with this.

Sep 17

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

This file has all the data in it but no header. If I add the appropriate WAV file header it is readable again and I can hear birdsong in it.

 

https://www.dropbox.com/s/hsbo8fvcptycw7k/20190801_171400.WAV?dl=0

 

If would probably be easiest to work directly from whatever comes out of the Recuva app. Can you post one of those files.

Sep 18

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!

This one plays fine directly and has the header attached but is quite noisy. Is that what you found?

Sep 24

@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 file seems to have a different problem in that it is all zeros.

 

 

I'll have a go at writing a C app to recover the files directly from the SD card.

Alternative, where are you based? It might be easier to post me the original SD card and then I can extract them directly from there.

 

 

Sep 25

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!

If you email me at alex.rogers@cs.ox.ac.uk I can give you the address. It's probably worth doing as other people may run into the same issue and it would be quite useful to have a way to recover data AudioMoth recordings from a corrupted SD card.

Sep 26

Will do.

New Posts
  • Hi, I have purchased an AudioMoth to detect the ultrasonic sound emitted by bats. And I would like to know how can I detect i) count number of bats ii) bats' flying direction. I am doing a project to contextualize bat data through different actuators of Arduino. Using LEDs, speakers, motors, etc to visualize bat data. For example, if frequency = 45kHz, LED will light up; if more bats, the motor will spin faster, etc. How can I do that? And can I transfer the data live, and wireless, using a raspberry pi and upload it to the cloud? Again, how can I achieve that? Finally, is there any guide to manipulating the bat ultrasonic wav. file to human audible sound or visualize through spectrogram? Any tutorial for that? I am trying to use Adobe Audition. Many Thanks!
  • Hello, we deployed AMs with 64GB cards (formatted to FAT32 with a Mac) and 3 x eneloop 1900mAh AA batteries. Calculated they should last ~8-9 weeks at our recording schedule. Have just found that the first 8 we retrieved all ceased recording within a day of each other, 4 weeks after deployment. The cards only have 19GB of data each, so probably not a card issue. Individual testing of AA batteries pre- and post-deployment showed average voltage of 1.34 each prior, and now each AM had at least one battery with voltage as low as 0.06-0.21V (but others up to 1.14V). Stumped, as a colleague had the same set- up with a slightly longer daily recording schedule and longer deployment, with no issues. Am I right in thinking: 1) there is some critical minimum threshold in battery voltage, below which the AMs won’t work, despite our calculations they should have lasted twice as long? 2) if we decrease the amount of data collected per day they would last longer, and 3) does ticking or unticking the ‘enable low battery cut-off’ box in the configuration app make any difference to this? 4) is there a large error around the mAh drawdown prediction on the app that could explain our predicted vs actual data collection period?
  • Hi, in all my recordings there's a "clicking" noise (26-28kHz). This is an issue that I had before with some recordings but now the noise is louder and it is present in all recordings. The batteries are Energizer AA (new) and the SD card is the SanDisk Extreme 32GB. Is there Anything I can do to make the "clicking" noise disappear?
Before posting, be sure to check the FAQ.