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' labels 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?
Bouke
VideoToolShed
van Oldenbarneveltstraat 33
6512 AS NIJMEGEN
The Netherlands
+31 24 3553311
www.videotoolshed.com
For large files:
http://dropbox.yousendit.com/BoukeVahl998172
------------------------------------
Please donate to the Red Cross to help those in earthquake ravaged Haiti: http://www.redcross.org/en/donatemoney
Search the offical complete Avid-L archives at: http://archives.bengrosser.com/avid/
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/Avid-L2/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/Avid-L2/join
(Yahoo! ID required)
<*> To change settings via email:
Avid-L2-digest@yahoogroups.com
Avid-L2-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
Avid-L2-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
No comments:
Post a Comment