Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2024-12-05T14:19:20.737Z
Answers.LastActivityDate: 2024-12-05T14:19:20.737Z
Answers.UserDisplayName: WMXZ
Body: <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>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-12-06T01:49:09.273Z
Comments.Text: 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
Comments.UserDisplayName: Brian Miller
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-12-07T22:55:11.970Z
Comments.Text: 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.
Comments.UserDisplayName: selene
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-12-08T05:56:30.997Z
Comments.Text: @selene, if you ask, I can try to answer :-)
Comments.UserDisplayName: WMXZ
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2024-12-08T22:26:33.827Z
Comments.Text: @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).
Comments.UserDisplayName: Brian Miller
Tags: <soundtrap><data-processing><files><time-align><time-stamps>
Title: How do you take into account SoundTrap offset?
ThreadText: # 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.
  
  
  ---
  
  