Using 1.5.3 B5172, 48 FPS material Played At 48 FPS when put on a continuous TC reel and a h.264 is created the ale reads lengths that are different than reported in cortex and when laid up against the file drift. (looks like they are based on the original TC or double the length)
Hmm, yeah, I can see what could be confusing here.
If you bring in a clip that was really 48fps with 48 fps timecode, then the playspeed is 100%.
When you put a clip on a continuous tc reel with a particular framerate, we don’t skip frames to change the framerate. Every frame of your input becomes a frame in your output. So putting a 48fps clip on a 24fps reel results in a clip that is twice as long as the original (because it has the same number of frames).
In order to output a clip with the durations in time as the original, you actually have to set the playspeed to 200% (in this case 96 fps).
The clip in question had a frame rate of 48 fps over 24. When the clip is brought in, the code is read at 24 fps and the clip is slow. The request was to play the clip at 48 fps in order to achieve real time motion. They are apparently going to do this quite a bit. Cortex certainly gives a big warning to not add this clip to a source TC reel due to match back which makes sense, but if you follow it’s instructions which is to put it on a continuous TC reel. Durations in the software reflect the new duration of the clip while the ALE reflects the original unaffected duration. This makes it difficult to create deliverables which are the new duration and use the ALE to create chapter marks (DAX).
Hope this makes sense.
1 Like
Yep makes sense. Thanks. Definitely a bug.
This topic was automatically closed after 2 days. New replies are no longer allowed.