A plea for Rec run TC on file based shoots, and to introduce 23.976 DF TC.
2010/01/23 16:35
I want to start a discussion on timecode.
First the easy part.
I am thinking that there is no need to shoot Rec Run tc anymore on file based shoots / workflows.
(Unless you shoot XD cam and ingest 'traditional' with a deck and 422 control, but that is not what i call file based...)
One reason to shoot Rec Run was to make the ingest process more seamless (with all the trouble of undetected small TC breaks...)
But for a file based workflow, it makes sense to know the time of shooting, and it definitely will lessen the double timecodes.
(each source start on 00:00:00:00)
Of course another good reason was to have each source hours reflect the tape name.
(And for the ones longer around, that has saved each and everyones butt at least once...)
However, going back to originals is less and less needed.
(That does not mean that you should not keep a good record of sources, and use the 'tape / reel / disk' label always!)
So why not shoot TOD and give the editor some more info.
Handy to find back lost shots ("did you shoot it before or after lunch?" comes to mind.)
But more important, more options to synchronize.
More and more (cheap) equipment is entering the playground.
And since there is more, the amount of cams / audio recorders / cell phones
that you have to use during a session is increasing.
So if you shoot TOD, you have the ability to 'sync' sources based on their shooting time / date.
Of course it will not be frame accurate, but will get you very close.
This whole idea started while I was making my LTC_Systime application.
Intended to lock DSLR cams to BWF recorders.
And that brought up the next issue, the need for 23.976 DF TC.
Mind the use of 23.976. If you shoot true 24, there is no need for DF,
as the TC will be in sync with the time on the wall.
But not with 23.976, same as with NTSC.
If you want to use the internal clock of a device, that will run in 'time on the wall' time.
So the timecode will be in sync with Drop Frame.
So no problem if the shoot was Drop frame, but if you have to match up with non-drop frame shoot, you have a problem.
Or, if you want to match the end of a 23.976 long take to a drop frame shoot, you also have a problem.
If a NDF running cam was reset at exactly midnight,
it would be possible to calculate the corresponding matching TC.
I don't see that happening often...
Thus to keep everything sync as possible, why not have 23.976 DF TC?
Principle can be the same, forget 2 TC frames every minute except for the minutes dividable by ten.
Or to make it more accurate (as i think it should be), just drop ONE tc frame every 1000 frames.
(Remember the speed of 23.976 = 24 * 1000 / 1001
Am i right?
Back to the blog listing
2010/01/23 16:35
I want to start a discussion on timecode.
First the easy part.
I am thinking that there is no need to shoot Rec Run tc anymore on file based shoots / workflows.
(Unless you shoot XD cam and ingest 'traditional' with a deck and 422 control, but that is not what i call file based...)
One reason to shoot Rec Run was to make the ingest process more seamless (with all the trouble of undetected small TC breaks...)
But for a file based workflow, it makes sense to know the time of shooting, and it definitely will lessen the double timecodes.
(each source start on 00:00:00:00)
Of course another good reason was to have each source hours reflect the tape name.
(And for the ones longer around, that has saved each and everyones butt at least once...)
However, going back to originals is less and less needed.
(That does not mean that you should not keep a good record of sources, and use the 'tape / reel / disk' label always!)
So why not shoot TOD and give the editor some more info.
Handy to find back lost shots ("did you shoot it before or after lunch?" comes to mind.)
But more important, more options to synchronize.
More and more (cheap) equipment is entering the playground.
And since there is more, the amount of cams / audio recorders / cell phones
that you have to use during a session is increasing.
So if you shoot TOD, you have the ability to 'sync' sources based on their shooting time / date.
Of course it will not be frame accurate, but will get you very close.
This whole idea started while I was making my LTC_Systime application.
Intended to lock DSLR cams to BWF recorders.
And that brought up the next issue, the need for 23.976 DF TC.
Mind the use of 23.976. If you shoot true 24, there is no need for DF,
as the TC will be in sync with the time on the wall.
But not with 23.976, same as with NTSC.
If you want to use the internal clock of a device, that will run in 'time on the wall' time.
So the timecode will be in sync with Drop Frame.
So no problem if the shoot was Drop frame, but if you have to match up with non-drop frame shoot, you have a problem.
Or, if you want to match the end of a 23.976 long take to a drop frame shoot, you also have a problem.
If a NDF running cam was reset at exactly midnight,
it would be possible to calculate the corresponding matching TC.
I don't see that happening often...
Thus to keep everything sync as possible, why not have 23.976 DF TC?
Principle can be the same, forget 2 TC frames every minute except for the minutes dividable by ten.
Or to make it more accurate (as i think it should be), just drop ONE tc frame every 1000 frames.
(Remember the speed of 23.976 = 24 * 1000 / 1001
Am i right?
Back to the blog listing