I have been doing video analysis on quicktime movie files for several years, but have never really had the need to use the time information of the movie files. For a project, I now had the need for getting the timecode in seconds out of the files, and this turned out to be a little more tricky than first expected. Hence this little summary for other people that may be in the same situation.
It turns out that QuickTime uses something called time units for the the internal representation of time, and this is also what is output in Jitter when run my analyses on the files. The time unit is not very meaningful for humans, as it is a combination of frames and a timescale that defines the actual length of each time unit. Apple has posted some more technical information about Timecode Media Handler Functions, but it didn’t really help me solve the problem easily.
Fortunately, there are a few threads on this topic on the Cycling ’74 forum, including one on relating sfplay time to quicktime time, and another on converting quicktime Units into time code. These threads helped me realise that calculating the duration of a movie file in seconds, is as easy as dividing the duration in frames by the timescale. And, by knowing the total number of frames it is then also possible to calculate the frames per second of the file. Now that I know this, it is obvious, but I post the patch here in case there are others looking for this information.
----------begin_max5_patcher---------- 1334.3oc6Zt0iiZCE.94jeEV7TqzTJ9B25Sspu0+BUqF4.NY7rDHEblY1tZ+ uWegbcGLPVvyLRUq1DgCfOmOet4imutbg2ppWXMdfeC72fEK95xEKzCoFXQ6 0K71ReIqf1nuMurpsaYkBu6L+lf8hPO9eRKx1WPELv1pm3LP99ZpfWUBnk4f 06Z.7RvewEBV8gGccUong+uL0iCQ9AsCWtea0dQASnmuCittdyJ80GuucTQ1 C7xM2WyxDFM.GI+U.BY9LV+k7A.ep8Q34ZQsZ0i+BJ5bwnjtUKFd+QMmV3cR R3kGDDnZrusbo5i69AYUVAO6y.QEH6HzDboDLefAgUvHQSFHhXkLn2PxbvpY 9PAJIxOINTp+QZZDCsACX7XgwgYtl0HUPsxb9rmF5qmbrdAIn8CvmlPFttVJ lYU6O8Sy.EgQ9CGhQSLDgo5oy3tOKLT4N1H8NmQeRHQaBzRvH6DjLsDDFFXH X7rRv4CdwomwNiuTmrC6f3YxWvpQlYC0s1EYRckn0qHhOJzh5A8N9hTN9xDr 2yJoqJXW.0IwrIE4C0xR3UQuZeLi1I9xNl4983JCCf2JZ4Fuax5ZZ4JD2F8c PjM0cfEJKVQyUxGRthBH9CFqINDqRCV85MI8iIWiwFTZ.KL.Ykrwy.YmdDsZ uPbp.uKYAzBKRwl51RBNDsuaRDMNc5GX8l8rb999jefUl+MJKAx.zdXfYONQ V0ej2DsZqIycc78jWu.3mZjEtVl27yyXYWlReHw5ufPqbjj5fZGVWTIeGSVL CoFoBRPL6+Mzt9k3hPFREjJlGql06ZlwM4DE5ehj16m.wE8SninM+J.5OJJ. 627AmpSYhQ9VR3PFabFjcSjI0z3XCnbPPEbPa3YbT5PBq.+3EVAg8OSAiisV IBN5CRbEW3Qcfb3j98nvouC7n1xZZnaXeGU1HmfapuHVnSHlzVXioWDwZHAS 5.OjoBO2FYlVeJy17aqDoOOJz+6QcE2vCHCEF+NvepCjTKmCSi+AGcq.mZdK 3l5EdXucUpsaYo1ODffQxsvNczt6p+O0gjtw1caw9BSRuHlTRrsXRvz21XRV PyMYAYALDR7kAqgVAS36VvL5lSOjFSzBEyNt5BJuwIv5HTztZdGtO3dJO901 gsoDQTf15n8LYgcXi3fBg2UP+xJZs2XSOm.8O0uIn8CnAebizOvyY0Oud84V MuZxW0MVTUsyZBYUDS0Ryj5.Tyn4iZwF12QtaXjw9Wc3bu5Rcv6RS+G4B++Q 3a9iV32o6EUMBZs.DLJBg5iPPS1WXHxl6P3T02NoVc+Vpnl+xsmyUQlcOyKy qd161T5Pj4bARM6FFR55HrN145UzrOuQVXTYdu9OudkFWno5IyqfWd8ehKZI VM9kpeS095rCut1i.BbRjyYMBdoIi5o6QUhI.d7ljt04rxyCQlyaT0oq0nfW ccXnhi5r9Fl7D3D4QUkXuxyUB8rKOvdjmTmINCx5I0YVOICPbTczykKVndjm DmINwCcwxgzA2i7D6LwIb.NVWEMXNEmnArXgbJb5OJ36qEK2ET9pPJcD2wcN 5jAHNg8HMa446pj0k2bp8+X8V.izcUgnO2H8EmlnISAvCJuRjy.JNYBH5DJN QCMOmaR6hmACtPBwkFb3gXv4vJGFxBrSkl9RTicq3zav+TmJN8UjGzcAGfoy Pz+vTG5LBCmdMfDF6RMHXFyWX1xOc2tmX0MsuRsj3sk9XUs5xn6zWxKMWp6m fWM6I9g6GqGgVm8.WvxD6qMsg4kjHukp44aK+Ob4vDqA -----------end_max5_patcher-----------
My main problem, though, was that I already had a lot of analysis files (hundreds) with only the QuickTime time unit as the time reference. It was not an option to rerun these analyses (which have taken weeks to finish), so I had to figure out a way of retroactively calculating a more meaningful timecode (in seconds).
After fiddling around with the time series data for a little while, I realised that it is possible to use the difference between two time samples and, knowing the original fps of the movies (using QuickTime Player to check the fps), calculate the correct duration in seconds. For my dataset there turned out to be only five different time unit durations, so it was fairly easy to write a small script for calculating the durations in Matlab. This is the part of the script that handles the time calculation, in which
a is a Matlab structure with my data, hence
a.time(1) is the time code of the first sample in the dataset.
time_diff=a.time(2)-a.time(1); switch(time_diff) case 1001 t = (a.time-a.time(1))/(29.97*time_diff); % 29.97 fps case 2000 t = (a.time-a.time(1))/(29.97*time_diff); % 59.94 fps case 3731 t = (a.time-a.time(1))/(24*time_diff); % 24 fps case 3733 t = (a.time-a.time(1))/(24*time_diff); % 24 fps case 3750 t = (a.time-a.time(1))/(24*time_diff); % 24 fps otherwise t = (a.time-a.time(1))/(29.97*time_diff); % 29.97 fps disp('!!! Unknown timecode.') end
For new analyses, I will calculate the correct duration in seconds right away, but this hack has a least helped in solve the problem for my current data set.