Hi Lars, we have not yet added a general time-drift adjustment, but to get the problem right: the audio source a starts in sync with the acc data, but, say, 2 hours later, you are off by k seconds?

What offset do you observe for a day? Are there synchronized events that help to detect it?

One way to tackle this could be to re-encode the raw audio data to fit the expected duration from the acc data and/or by using individually adjusted chunks of audio data. Depending on the precision of replay control adjustment of replay speed may be possible, but my guess is that would be too coarse in general.

You may want to get in touch, so we can discuss this in more detail or share some sample material to understand this better.

In my case the audio logger made a pause after every 1 hour. For the individual logger the drift (or time scaling) seemed constant BUT every new hour of recording had it's own individual time shift!

I analysed this by finding recognisable behvioral events in both audio and acc - like "shaking".

I "time scaled" the audio and shifted it to be in sync by means of some python scripts.

My problem was that far from all hour long splits had multiple shakes so it could be hard to arrive at the correct shifts.  

Given that the time scaling was rather constant, I exlored signal cross correlation methods to arrive at the shifts but it was not a trivial exercise as in many cases the audio and ACC did not record the same things.

In all of this, I assumed that the time codes of the ACC signal was correct - but I still need to check for this!

My plan is to use a very precisely GPS synced audiorecorder (like the GPS synced Audiomoth) and do some synced recordings of audio and ACC. 

My point was just that it may be worth while to have some "knobs" to tune drift and shift when plotting video or audio together with ACC and other sensor data with a different time code. 

Currently, the main focus is visual footage as we don't render audio data in the same way as we do for acceleration (also: the highly different frequencies can be hard to show sensibly side by side).

But In this sense, yes, the new module features 'quick adjust knobs' for time shifts: you can roll-over a timestamp and use a combination of shift/control and mouse-wheel to adjust the offset of the video by 1/10/60 seconds or simply enter the target timestamp manually down to the millisecond level. This work can then and also be saved in a custom mapping file to continue synchronisation work later on.

but no "time scaling" adjustments to adjust a too "slow" or too "fast" video ?

No, not yet. The player we attached does support slower/faster replay up to a certain precision, but I'm not sure that this will be sufficiently precise for the kind of offsets we are talking about. Adding an option on the frontend to adjust this is quite easy, but understanding the impact of this on internal timestamp handling will add a level of complexity that we need to experiment with first. 

As you said, for a reliable estimate on this kind of drift we need at least 2 distinct synchronized markers with sufficient distance to each other, e.g. a precise start timestamp and some recognizable point event later on.

I perfectly agree that providing an easy-to-use solution does make perfect sense. We'll definitely see into this.