Record continuously for 10h?

Question

Hello,

I come back to you after this discussion: https://www.openacousticdevices.info/support/configuration-support/how-to-create-300-sec-files-in-continuous-recording

Indeed, I went into continuous recording all night: 20:00 to 06:00 without cycle of recording and sleep.

I do get two files, but unfortunately not the "right" ones.

I get a file from 8:00 p.m. to 10:58 p.m. and a file from 2:00 a.m. to 2:51 a.m.

Have you had this problem or do you have a solution?

My settings: 384 kHz, medium gain and no cycle + firmware 1.4.1.

Thanks in advance,

Adrien CHARBONNEAU

Alex Rogers · Accepted Answer

Long duration recordings at 384kHz are quite energy intensive so we generally use Energizer Lithium batteries for this - https://data.energizer.com/pdfs/l91.pdf

Alex Rogers · Answer

Ah, well spotted! I couldn't understand how the files could be the wrong length and yet still start at the correct time if there was no warning message about shutting the file prematurely due to a low battery voltage. There is no way for the file to close early without this message.There is also a FAT32 file size limit of 4GB due to the use of a 32-bit integer in the file size description.This has been a potential bug from the very first versions of the firmware but hasn't shown up before as previously it was very hard to make continuous recordings this size - you had to manually edit the record and sleep durations. Now that you can just disable the sleep/record cycle it's very easy.We'll have to think about how to fix this. In the short-term I guess it can just have to be a warning in the configuration app if we detect that this condition will be exceeded. We can at least make the firmware limit the maximum size of the WAV files that it generates to just under 4GB so that the files are closed correctly.

davidlee_malvern · Answer

@Adrien

Alex was barking up the wrong tree regarding your original problem!

The real issue is that the length of the data chunk in a wave file is saved as a 32bit integer, which imposes a limit of 4GB - which corresponds to just over 1hr33min at a sample rate of 384kHz.

The AudioMoth will happily continue to stuff samples into the file beyond this limit but when it comes to write the header the maximum data size it can record is limited to only 4GB. The actual size recorded will depend on how the firmware handles overrun of the 32bit integer and is likely to be very much smaller than 4GB. My experience suggests that it resets to zero, so that the recorded data size will be the actual amount of data in the file modulo 4GB, however the numbers you posted suggest that the actual situation may be more complex.

If you check the sizes of the your files from the other night I predict that they will be 16,200,001 and 10,800,001KB (corresponding to 6 and 4hr).

So whilst all the data is actually present in the files, a sound editing application will only recognise the amount of data encoded in the 32bit integer written by the AudioMoth. If you import as raw PCM data then the software will generally do better and recognise 4GB. However the full amount of data can be recovered if you divide the files into chunks each containing less than 4GB of samples and either fix the headers or import the files separately as raw PCM.

You should be able to record files up to 90min long at 384kHz rising to over 2hr if you sample at 256kHz.

EDIT: If you need to rescue data by dividing over-large files then GSplit is a good tool for the job: www.gdgsoft.com/gsplit/

davidlee_malvern · Answer

Alex Once again you fix one problem that only affects a small number of users and at the same time bugger up the device for everyone else!Why on earth have you changed the default mode to record continuously? Given that we could always increase the Recording Duration if we actually wanted to record  arbitrarily long files it would appear to be a totally stupid idea! Please can you leave the default mode alone and just fix the bugs in the previous version.

Alex Rogers · Answer

We've released an updated version that addresses this issue now. It will correctly close the file and start another one when the 4.3GB limit is reached. We're also going to update the configuration app to detect and warn about files that might go over this limit.