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
%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.
%Convert date times to 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.