Quelltext der Seite Datenvorverarbeitung und Synchronisierung von Playback Projekten/en

<languages />

'''Note:''' Data preprocessing with session synchronization works only for sessions of '''one''' realisation, not across realisations.

== Problem ==

In playback studies, the sessions usually take place asynchronously. In order to be able to compare the data of all sessions, the parts must be exactly superimposed before resampling. This article explains the process by which the sessions are (automatically) synchronized. 
The following circumstances must be taken into account:

# A part in Session 1 is rarely exactly the same length as the same part in Session 2. 
# If a part contains a pausable medium, there may be periods during the pause in which no data are generated.
# If randomisation is used in the study, Parts may be duplicated or missing. These data must also be comparable. 


<div class="et-screenshot">
[[Datei:Datenvorverarbeitung und Synchronisierung.png|Graphical representation of the synchronisation of several playback studies]]
</div>


== Synchronisation process ==

The synchronisation happens in several steps, which are shown graphically in two example sessions here.

# The raw data: 
#* The sessions have taken place one after the other and the raw data is stored. The boundary lines within a part mark start and pause events of a played medium. Between the boundaries, the medium is therefore paused, i.e. the data collected during this period, if any, is no longer medium-related and thus negligible for the study. 
#* Synchronisation events are generated. These correspond to the start event of a medium, e.g. the playing of a video. 
# The pauses within the parts are skipped for resampling. 
#* This may cause pauses between the parts, because sections have been removed. However, the start event of the next part remains in place and is not moved with it. 
# The sessions are synchronised.
#* Duplicated parts within a session are bundled on top of each other. 
#* The synchronisation events of all sessions are superimposed. Thereby all parts align themselves after the one, which had the most "waiting time" before the first sync event. So again this can cause gaps. 
#* Part-end events are created. 
# Relative timestamps are created. There are 2 types of relative timestamps: 
#* Session-related relative timestamps (Session timestamps).
#* Part-related relative timestamp (Part timestamp)



== Synchronisation for live studies ==

In live studies, the sessions can also start staggered (e.g. if a participant joins later or slight latencies occur). In this case, however, the part-start events must not be synchronized, as the data would otherwise be shifted. 
In live studies, therefore, the absolute time stamp must determine the measure, i.e. a concrete point in time during the study, or alternatively a concrete event originating from the performers.