- This topic has 8 replies, 2 voices, and was last updated 10 months, 4 weeks ago by
.
-
Posts
-
We are looking at the results of eyetracking experiemtns and more specifically the audio time presented to the partiicpant and if possible to total time an item is presented the participant. Our set up was 1000ms pictures on screen then onset of audio with pictures then 400ms after with pictures on screen. (eye trakcer had few question here and there but rest for sit back and record)
1. In the column name event times, the first 5 or 6 digits are same for the same participants for all the items presented to that participant. why?
2. Second question, i wanted to find if the audio presented to participant was different than original audio time in ms. I would look at audio play and audio end number in results file. (Parameter column and Value column). How we interepret these numbers?
For example one partiicpant has 0 at audio play and 14.069025 at audio end or pause; another participant 0.000485 audio play and 13.792653 audio end/pause. How we translate .000485 as audio suppose to have started after the 1000ms or is 1000 +485ms extra added then audio starts. How do look at the audio play and end times? are the original numbers in seconds?Because My audio is longer and PCIbex audio comes out shorter. I am struggling understand thse numbers.
THank youHi,
1. The values in the EventTime column are timestamps estimating how many milliseconds have elapsed since Jan 1 1970 (UNIX time). What matters is the difference between them: by subtracting the timestamp of one event from that of another, you get how much time separates the two events
2. You can apply the logic I just mentioned to calculate how much time passed between when the “play” event was logged and when the “end” event was logged, ie. to estimate how long the playback lasted. The values you report are in seconds, they correspond to the in-file position of the player when the events were logged. The value of 0.000485 associated with the “play” event means that the player was at position 0.485ms in the audio file when the event was logged, indicating an infinitesimal delay between when the browser initiated playback and when PennController received the “play” event. For an audio sampled at 48Hz, 0.484ms do not even correspond to a single sample, and it is abysmally shorter than what humans perceive, so you can safely ignore this delay. The 14.069025-13.792653 = 0.276s = 276ms difference, however, is more intriguing. Are these for the same file? What format is it? wav? mp3?
Jeremy
But for this participant for example, an item that starts at 0.001168 sec (1.16ms) and ends at 14.689637. Same participant also has different items play at .002114 and another at .022991, Other participants also have times like this. Should this be concerning? Seems really big. How do we understand these numbers?
Hi,
If the different time positions for the “end” events correspond to different audio files, then it’s no cause for concern
When a “play” event reports a time position of 0.022991, it means that the event was detected 23ms after the browser had effectively initiated playback, so you can estimate a more accurate timestamp for the beginning of playback by subtracting 22.991 from the EventTime value of the “play” line
Jeremy
FOR question 1 (first post), I was trying to ask about the event timestamp numbers FOr example, Same participant as above:
(item no, Event start_results, event end_results, original total audio+1000ms before onset audio+400ms after audio onset added)item18b.wav, 1648122657466, 1648122678169, 17683ms
The results say the total time is 20703 (end_results-start_results) but my total time with audio, before and after time added is 17683. This gap is really big betweeen the original item and reported time by pcibex.
Other items are the similiar as well. How should be translate this as well?
Would you mind sharing a link to your study, here or at support@pcibex.net so I can take a closer look? If you didn’t run it on the PCIbex Farm or have deleted the results from the platform, would you mind sending a sample of your results file too?
Jeremy
- You must be logged in to reply to this topic.