Welcome to our community

Be a part of something great, join today!

  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Timecode / Edgecode and varispeed?

Nelson Goforth

Well-known member
Joined
Apr 12, 2008
Messages
105
Reaction score
0
Points
0
Website
www.rockymountain4k.com
Last week I worked on a spot in which questions were raised about whether the footage was being recorded at a high frame rate and being played back properly. In other words, were we getting slow motion? It was subtle.

I'd hope to demonstrate it by rendering out some footage with a timecode window burn. I'd figured that either the timecode or the edgecode (or both) would be playing back slower than real time... but it doesn't appear to work that way. Both timecode and edgecode play back at 'normal' speed.

Am I missing something, or is this the way it should be? It just seems that if timecode (time-of-day) runs like this then there is some remote chance that I could get overlapping code. It's not really recording the time of day but following the frame rate.

I have a sample clip that is clearly slow motion (100fps) which I burned with both timecode and edgecode; the codes both run at normal speed. I rendered it using RedRushes; on the "Render" panel I set Timecode to "External/TOD" but burned both codes onto the clip.

bike.100fps.mov

Thank you for any insights.

Nelson
 
For varispeed, Timecode is recorded at the project frame rate which means if your project rate is 24fps, and you record varispeed at 48 fps, you'll see the timecode go by normally when you play it back at 24fps.
 
Thanks Deanan, that's what I figured, but there was a part of it that's counterintuitive. As a friend of mine said, "You'd think that time of day would be... time of day"

So other than shooting a stopwatch (which I finally did) there's no way to 'prove' there's slow motion going on. And even with that stopwatch I'm still getting some questions about the other shots... the ones without stopwatches.

Sigh.
 
Thanks Deanan, that's what I figured, but there was a part of it that's counterintuitive. As a friend of mine said, "You'd think that time of day would be... time of day"

So other than shooting a stopwatch (which I finally did) there's no way to 'prove' there's slow motion going on. And even with that stopwatch I'm still getting some questions about the other shots... the ones without stopwatches.

Sigh.

Unfortunately, there's no smpte timecode format that would match for offspeed recording. When you add more frames that ll still need timecode, you can't do much else.
 
And even with that stopwatch I'm still getting some questions about the other shots... the ones without stopwatches.

Sigh.

One easy way (if the shutter was on RELATIVE mode) is to look at the shutter time metadata in Clipfinder or another tool - anything that isn't 1/48 (or 1/50 for 25fps or 1/59.94 for 29.97fps) is varispeed.
 
Thank you Cail, that gives me something to go on.

Actually today I'm going to shoot some similar material but with a stopwatch in the frame, just to ease minds about what's going on.

One easy way (if the shutter was on RELATIVE mode) is to look at the shutter time metadata in Clipfinder or another tool - anything that isn't 1/48 (or 1/50 for 25fps or 1/59.94 for 29.97fps) is varispeed.
 
Hi Deanan

Is there any chance of adding a varispeed fps field to RED metadata in the near-ish future? Or failing that a simple varispeed flag (ie varispeed on or off).

Thanks
Eric
 
Has anything been changed since the last post on this thread? What is the best way to see what the varispeed framerate is for a specific cilp?
 
Back
Top