Answers.Body: <p>From your 'localization' tag I assume you wanted to estimate the time delay of sound between the Soundtraps. What I would do is</p>
  <ul>
  <li>detect the known transmissions on all 4 units</li>
  <li>if you know location of transmission and recorders, correct for travel time</li>
  <li>assume that temperature is constant during deployment</li>
  <li>conclude (assume) that clock drift rate is constant</li>
  <li>correct timeseries (detections) of all transmissions align</li>
  </ul>
  <p>from your post I deduce that you already doing that</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-06-26T21:20:00.317Z
Answers.Text: Hi WMXZ, thanks for your response.  I am fully aware of the workflow, I am looking for alternate methods to conduct the time alignment of the tracks using calibration signals which means I won't have to assume constant clock drift at least when I have calibration info, and therefore, I will have more accurate localization results.
Answers.UserDisplayName: Julia Dombroski
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-06-28T04:59:41.913Z
Answers.Text: I effectively answered: "But I am curious about how folks have been time-aligning."
Answers.UserDisplayName: WMXZ
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-06-28T18:12:48.057Z
Answers.Text: Indeed, and thank you. I am looking for scripts\software that allows for the implementation of the concepts you described. Please share if you are aware of any.
Answers.UserDisplayName: Julia Dombroski
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-06-25T10:28:50.823Z
Answers.LastActivityDate: 2022-06-25T10:28:50.823Z
Answers.UserDisplayName: WMXZ
Answers.Body: <p>Info: Do you have a pinger/synchronization sound that you can use? Without that what you are trying to do will be near impossible to do with accuracy. As good as the Malinka paper is, there is still a ((small)) margin of error because the recordings are not being made with the same sound card.</p>
  <p>However, you may be able to get a loose synchronization, which may be OK depending on what signal you want to look at.</p>
  <p>Did program your SoundTraps with the same computer, and reset the time? This would give all of your sound traps the similar starting point for their internal clocks. You will need the times of Clock Reset for each individual unit.  In this example, I will call this: timeGPSreset</p>
  <p>Upon retrieval, using the same computer you used to reset the clocks, note the clock drift of each unit.  In this example, I will call these units timeGPSstop (real time) and timeClockstop (ST clock time).</p>
  <p>You can then use a linear interpolation to adjust for clock drift. Here is an example of how to do it in Matlab.</p>
  <pre><code>    %timeGPSreset -  Should be present for all deployments. This was the
      %time that the unit was synced with a GPS before deployment.
      
      %timeClockstop - Time on the unit when the data was offloaded.
      
      %timeGPSstop - Time according to the GPS or time.is when data was
      %offloaded.
            
      %DT_all - Datetime series you wish to adjust for Clock Drift
      
      %n - length of vectors you would like to interpolate over.
  
      %Create linear vectors of fixed length to interpolate on.
          timeGPSdiff=datenum(linspace(timeGPSreset,timeGPSstop,n));
          timeClockdiff=datenum(linspace(timeGPSreset,timeClockstop,n));
          %Convert date times to datenum
          DTall_num=datenum(DT_all);
          %Interpolate!
          newDTall=datetime(interp1(timeClockdiff,timeGPSdiff,DTall_num),'ConvertFrom','datenum');
  </code></pre>
  <p>This will give you a loose synchronization, as the timestamps across units will be adjusted for clock drift. It is not exact, however. And you will need to figure out what your margin of error is, as that will need to be included in your subsequent analysis.</p>
  <p>If you have a pinger/synchronizing sounds in your recordings that are produced at known/regular times, you can get a much more accurate synchronization.  You can adjust the code above to include those timestamps in the interpolation.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-06-30T18:35:48.637Z
Answers.Text: Hi etgriffiths, thank you so much for your response! For this specific deployment I do not have pingers - I will have them for the next deployment in a few weeks. I agree that the interpolation of the time drift across the whole deployment will be the best solution %for now %. The objective is to loosely localize calls to identify if they come from inside or outside the array area which can be done with amplitude differences in these cases. The code you provided will be very useful! Thanks!
Answers.UserDisplayName: Julia Dombroski
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2022-06-29T07:47:41.173Z
Answers.LastActivityDate: 2022-06-29T07:47:41.173Z
Answers.UserDisplayName: etgriffiths
Body: <p>In the past, I used Osprey and I am aware of the script by Malinka et al., 2020. What other methods/scripts/software folks have used and would recommend?</p>
  <p>Here's some background on the dataset:
  I have recordings made with a 4-unit SoundTrap array. Sensors were self-recording independently of each other resulting in 4 independent .wav files. Units were programmed to start recording at the same time but the end of the recording is different for each one due to battery performance differences. The deployment is about 7 days long and we have sounds produced at known times every other day to use as anchors for the time alignment. I am aware that the intervals between these sounds are not ideal and I am aware that the clock drift of SoudTraps can be huge... But I am curious about how folks have been time-aligning.</p>
  <p>Thanks!</p>
  
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-06-24T08:23:39.820Z
Comments.Text: Just for information - here is a paper describing a method (behind a paywall): [Blind alignment of asynchronously recorded signals for distributed microphone array](https://ieeexplore.ieee.org/document/5346505); for more generic time-series: [Multiple Alignment of Continuous Time Series](https://cs.nyu.edu/~roweis/papers/alignment.nips2004.pdf), [Time Alignment Measurement for Time Series](https://www.sciencedirect.com/science/article/pii/S0031320318301286)
Comments.UserDisplayName: pabouk - Ukraine stay strong
Comments.ContentLicense: CC BY-SA 4.0
Comments.CreationDate: 2022-06-28T18:13:25.490Z
Comments.Text: Thank you pabouk these are very useful!
Comments.UserDisplayName: Julia Dombroski
Tags: <methods><pam><time-align><localization>
Title: Which methods /software/scripts can be used to time-align recordings from an acoustic array?
ThreadText: # Which methods /software/scripts can be used to time-align recordings from an acoustic array?
  
  (Asked by: username_0 on 2022-06-23)
  
  In the past, I used Osprey and I am aware of the script by Malinka et al., 2020. What other methods/scripts/software folks have used and would recommend?
  
  Here's some background on the dataset:
  I have recordings made with a 4-unit SoundTrap array. Sensors were self-recording independently of each other resulting in 4 independent .wav files. Units were programmed to start recording at the same time but the end of the recording is different for each one due to battery performance differences. The deployment is about 7 days long and we have sounds produced at known times every other day to use as anchors for the time alignment. I am aware that the intervals between these sounds are not ideal and I am aware that the clock drift of SoudTraps can be huge... But I am curious about how folks have been time-aligning.
  
  Thanks!
  
  **Tags:** methods, pam, time-align, localization
  
  > **Comments:**
  > **username_1**: Just for information - here is a paper describing a method (behind a paywall): [Blind alignment of asynchronously recorded signals for distributed microphone array](https://ieeexplore.ieee.org/document/5346505); for more generic time-series: [Multiple Alignment of Continuous Time Series](https://cs.nyu.edu/~roweis/papers/alignment.nips2004.pdf), [Time Alignment Measurement for Time Series](https://www.sciencedirect.com/science/article/pii/S0031320318301286)  
  > **username_0**: Thank you pabouk these are very useful!  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_3 on 2022-06-29. Score: 3 | Accepted answer
  
  Info: Do you have a pinger/synchronization sound that you can use? Without that what you are trying to do will be near impossible to do with accuracy. As good as the Malinka paper is, there is still a ((small)) margin of error because the recordings are not being made with the same sound card.
  However, you may be able to get a loose synchronization, which may be OK depending on what signal you want to look at.
  Did program your SoundTraps with the same computer, and reset the time? This would give all of your sound traps the similar starting point for their internal clocks. You will need the times of Clock Reset for each individual unit.  In this example, I will call this: timeGPSreset
  Upon retrieval, using the same computer you used to reset the clocks, note the clock drift of each unit.  In this example, I will call these units timeGPSstop (real time) and timeClockstop (ST clock time).
  You can then use a linear interpolation to adjust for clock drift. Here is an example of how to do it in Matlab.
      %timeGPSreset -  Should be present for all deployments. This was the
      %time that the unit was synced with a GPS before deployment.
      
      %timeClockstop - Time on the unit when the data was offloaded.
      
      %timeGPSstop - Time according to the GPS or time.is when data was
      %offloaded.
            
      %DT_all - Datetime series you wish to adjust for Clock Drift
      
      %n - length of vectors you would like to interpolate over.
  
      %Create linear vectors of fixed length to interpolate on.
          timeGPSdiff=datenum(linspace(timeGPSreset,timeGPSstop,n));
          timeClockdiff=datenum(linspace(timeGPSreset,timeClockstop,n));
          %Convert date times to datenum
          DTall_num=datenum(DT_all);
          %Interpolate!
          newDTall=datetime(interp1(timeClockdiff,timeGPSdiff,DTall_num),'ConvertFrom','datenum');
  
  This will give you a loose synchronization, as the timestamps across units will be adjusted for clock drift. It is not exact, however. And you will need to figure out what your margin of error is, as that will need to be included in your subsequent analysis.
  If you have a pinger/synchronizing sounds in your recordings that are produced at known/regular times, you can get a much more accurate synchronization.  You can adjust the code above to include those timestamps in the interpolation.
  
  > **Comments:**
  > **username_0**: Hi username_3, thank you so much for your response! For this specific deployment I do not have pingers - I will have them for the next deployment in a few weeks. I agree that the interpolation of the time drift across the whole deployment will be the best solution %for now %. The objective is to loosely localize calls to identify if they come from inside or outside the array area which can be done with amplitude differences in these cases. The code you provided will be very useful! Thanks!  
  
  ---
  
  ### Answer by username_2 on 2022-06-25. Score: -1
  
  From your 'localization' tag I assume you wanted to estimate the time delay of sound between the Soundtraps. What I would do is
  
  * detect the known transmissions on all 4 units
  * if you know location of transmission and recorders, correct for travel time
  * assume that temperature is constant during deployment
  * conclude (assume) that clock drift rate is constant
  * correct timeseries (detections) of all transmissions align
  
  from your post I deduce that you already doing that
  
  > **Comments:**
  > **username_0**: Hi username_2, thanks for your response.  I am fully aware of the workflow, I am looking for alternate methods to conduct the time alignment of the tracks using calibration signals which means I won't have to assume constant clock drift at least when I have calibration info, and therefore, I will have more accurate localization results.  
  > **username_2**: I effectively answered: "But I am curious about how folks have been time-aligning."  
  > **username_0**: Indeed, and thank you. I am looking for scripts\software that allows for the implementation of the concepts you described. Please share if you are aware of any.  
  
  ---
  
  