3
$\begingroup$

I realized that audio files from my Soundtraps do not last exactly the required amount of time, i.e.: i asked for a 1h hour file at 128kHz, i should then have 128.000 * 3600 = 460.800.000 samples, however i get a file containing 460.815.344 samples with a begin timestamp of 00:00:00.

My second audio file begins at timestamp 01:00:00, therefore i have an "overlap" between the end of the first audio file and the beginning of the second file based on the timestamps (15.344 samples overlap). I checked if the extra 15.344 samples at the end of the first file were a duplicate of the beginning of the second file but it is not the case. How do you take this into account when manipulating your data ?

After recording several files, the extra samples add up to more than 128.000 samples, i.e. one second of data. However, the audio file timestamps are still labelled n:00:00, with the extra second not being taken into account.

Should I discard the excess data (i.e. trust the timestamps from the file names) or should I use that offset (i.e. offset each file by the amount of extra samples) ?

Thanks !

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ This mismatch between clock times and sample rates (and nominal vs actual sample rate) is a common issue for most acoustic recorders, not just SoundTraps. See related discussion on the forum at bioacoustics.stackexchange.com/questions/1632/… $\endgroup$
    – Brian Miller ♦
    Commented Dec 6 at 1:49
  • $\begingroup$ I'm trying to come up with a good follow up question along the lines of "So most of us have imperfect sampling rates/clock times...what do we do with it?" If anyone has a good attempt (or answer!) let me know. $\endgroup$
    – selene
    Commented Dec 7 at 22:55
  • $\begingroup$ @selene, if you ask, I can try to answer :-) $\endgroup$
    – WMXZ
    Commented Dec 8 at 5:56
  • $\begingroup$ @selene: "what do we do with it?" is really more of a class of questions that depends on the application. Since identifying and addressing it in any form requires some IMO tedious attention to detail, I'm inclined to first ask, "is it causing a problem that needs solving for your application? i.e. if you don't address it, does it change your results/interpretation?" Only if the answer is "yes", then is it worth delving into potential solutions. Otherwise probably not worth addressing (e.g. if it's just to satisfy a compulsion for things to line up nicely/perfectly). $\endgroup$
    – Brian Miller ♦
    Commented Dec 8 at 22:26

1 Answer 1

Reset to default
3
$\begingroup$

From the numbers (460.815.344 samples for 3600 s) I would conclude that the sampling rate is not exactly 128,000.00 Hz but 128,004.26 Hz. This small difference is due to the fact that the clock of the processor is a) never exactly the nominal value and b) may even vary in function of the temperature. The SoundTrap never duplicates data so you do not discard the data but adjust the sampling time. Consecutive files hold consecutive data. You should, however, synchronize the real-time-clocks (write down the reported value) before and after the deployment. Due to long term clock drifts, the reported time may differ from the true (UTC,local,GPS,...) time and the time synchronization allows better estimation of the true sampling rate.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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