There are a whole lot of different file-compression methods out there: MP3, FLAC, OGG, AIFF, etc and each of these can have their own variations in parameters. I'm interested in:

  • What file format you are using
  • What tool(s) you are using to do file conversions, if your recorders are not recording in that format (some sensors can record directly in FLAC, for example)
  • Have you tried multiple file formats? How did you settle on the one you currently use?
  • Do you use multiple file formats for multiple use cases? (e.g. one for analysis, another for web hosting)

7 Answers 7


There is a similar post about compression here with some helpful answers on different options & explanations of them.

Does the file format of audio recordings (e.g. .wav vs .mp3) matter if you are performing acoustic analyses on them?

I personally always use WAV files, as this is the predominant method used in passive acoustic monitoring & what ARUs like Swifts, Audiomoths, etc. write files with.


SoundTraps use X3 file compression which we often find leads to around a x4 lossless compression (depends on noise). Unfortunately, SoundTrap host software is the only easy option to decompress the resulting .sud files and there is no way to re-compress wav files. However, Ocean Instruments (makers of SoundTraps) are writing a C# library to allow easy access to the X3 algorithm (there are already some on GitHub e.g. in Rust) and we are writing an equivalent Java version to directly integrate X3 into PAMGuard.

So it's not there yet but this an excellent compression algorithm that may become a common standard.

As a side note; it would be great if anyone wanted to start a MATLAB. Python and/or R library...


I use the flac format for storage and the wav format for analysis. I jump from one to another using the function wav2flac in R (seewave package). In order for the function to work you need to install the software "flac frontend" first. Wav2flac will call for it.


For us, because we pay for storage space from our host University's research computing department, file storage efficiency is somewhat important to minimize long-run costs. Because of this, our protocol is to keep recordings that are not currently being analyzed saved in FLAC, and keep only active projects in WAV. We use ffmpeg and the windows FLAC frontend executable for file conversion.


I ended up to use my own compression (obviously). I was starting with the original X3 compression from Mark Johnsons DTAG toolbox. In the end I simplified it by removing the RICE encoding that only kicks in low bit numbers. So I ended up with a simple non-destructive packaging scheme.

The idea is simply:

assume you data are all 32 bit integer, but your ADC is only 24 bit, so you pack 4 words (16 bytes) into 3 words (12 bytes). so far so good, but how does is in practice work? take a block of samples (in my case 128 samples), find the greatest value (in absolute terms) and pack the 128 words such that leading zeros and leading ones are removed. Each block get a small header, which not only contains the compression info but also time stamps and other useful information. (All is inspired by X3)

To read the files I have then a special loading program decoding the data on the fly. Obviously this compression works only with integer, but ADC gives me integers.


Here is a paper on Marks method: https://asa.scitation.org/doi/10.1121/1.4776206

Johnson, M., Partan, J., & Hurst, T. (2013). Low complexity lossless compression of underwater sound recordings. The Journal of the Acoustical Society of America, 133(3), 1387-1398.

  • This citation is really helpful - thanks for adding here!! I think that it really complements @Jamie's answer above about X3 and think it might be most helpful to other users if your two answers were combined rather than as two separate answers. I'd encourage you to either (1) edit the above X3 answer, just adding this citation, or (2) comment on the X3 answer and suggest that Jamie adds the citation.
    – selene
    Jul 11 at 17:28

For archives we use FLAC. It is compatible with many players and analysis software, open license and open source. For small recorders we use X3 as it is much simpler to implement (and uses less CPU power).

Not the answer you're looking for? Browse other questions tagged or ask your own question.