<p>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.</p>

CC BY-SA 4.0
2024-12-05T14:19:20.737Z
2024-12-05T14:19:20.737Z
WMXZ
<p>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.</p>
<p>My second audio file begins at timestamp 01:00:00, therefore i have an &quot;overlap&quot; 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 ?</p>
<p>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.</p>
<p>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) ?</p>
<p>Thanks !</p>

CC BY-SA 4.0
2024-12-06T01:49:09.273Z
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 https://bioacoustics.stackexchange.com/questions/1632/how-does-raven-paging-deal-with-imperfectly-continuous-data
Brian Miller
CC BY-SA 4.0
2024-12-07T22:55:11.970Z
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.
selene
CC BY-SA 4.0
2024-12-08T05:56:30.997Z
@selene, if you ask, I can try to answer :-)
WMXZ
CC BY-SA 4.0
2024-12-08T22:26:33.827Z
@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).
Brian Miller
<soundtrap><data-processing><files><time-align><time-stamps>
How do you take into account SoundTrap offset?
# How do you take into account SoundTrap offset?

(Asked by: username_0 on 2024-12-05)

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 !

**Tags:** soundtrap, data-processing, files, time-align, time-stamps

> **Comments:**
> **username_1**: 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 https://bioacoustics.stackexchange.com/questions/1632/how-does-raven-paging-deal-with-imperfectly-continuous-data  
> **username_2**: 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.  
> **username_3**: @username_2, if you ask, I can try to answer :-)  
> **username_1**: @username_2: "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).  

---

## 1 answers

### Answer by username_3 on 2024-12-05. Score: 3 | Accepted answer

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.


---

