02.05.2013 Views

Appendix 1

Appendix 1

Appendix 1

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

The Filmmaker’s Guide to Final Cut Pro Workfl ow<br />

The optac output was also sent to a time code generator that generated 30 NDF when the system<br />

was moving at 24 FPA. The plan was to use 30 NDF as the mixing and delivery time code to help<br />

identify this as a 24 FPS fi lm speed workfl ow while avoiding 24 NDF because not all equipment can<br />

be locked to 24.<br />

The NDF time code was sent to 2 DA88 digital recorders that were put into a “chase” mode. In<br />

chase, a recorder sees incoming time code and then “chases” it until it is in sync with it. It can chase<br />

forward or backward.<br />

This meant that whenever the main dubber was rolled forward or backward, the other dubber rolled<br />

forward and backward matching every movement as well as the DA88s also rolling forward and<br />

backward also matching every move.<br />

The “edit sync” point used was 01:00:00:00. This way, if DA88s were parked on 01:00:00:00<br />

and two sound tracks threaded to their respective edit sync marks everything was in sync. Every<br />

16 mm magnetic sound track could now be loaded two at a time and transferred to the 16 channels<br />

of the two DA88 recorders until all sound tracks were transferred in sync with each other to the<br />

DA88s.<br />

The work print was “telecined” on an Elmo fi lm chain locked to house sync. This pulled down the<br />

fi lm speed to 23.98 FPS. As this would now drift out of sync, the video playback deck was locked<br />

to the 30 NDF time code and 60 Hz reference, causing it to run at 30 FPS and pulling the video back<br />

up to the original fi lm speed.<br />

This was the exotic part of the workfl ow; video recorders do not like to run at 30 FPS. The 30 NDF<br />

time code was sent to a video sync generator that could cause a video recorder to run off-speed.<br />

While this worked, it looked horrible; the video was tearing and had color banding, which is exactly<br />

why NTSC video uses a 29.97 frame rate. As this was only a mixing video reference, the poor image<br />

was forgiven and used.<br />

The fi lm was mixed to a remaining track of one of the DA88s and this DA88 tape sent to Film<br />

Leaders for quality control. They in turn sent it out to be transferred to 16 mm positive optical sound<br />

fi lm, ready to be printed with the camera original reversal A-B rolls.<br />

Like the workfl ow for Help Wanted, the 24 FPS workfl ow actually added complexity. While the<br />

sound was never pulled up or down, sync was solid and the workfl ow straightforward. Yet, using a<br />

video reference picture and forcing it to run at fi lm speed was problematic.<br />

The fi lm could have been mixed at video speed. Had the dubbers been locked to the house sync<br />

instead of line power, they would have run at 23.98 FPS, pulling the tracks down as they were transferred<br />

to the DA88s. The DA88s could have been referenced to 29.97 NDF from the time code generator<br />

locked to the optac.<br />

The picture and sound would now play at video speed, 29.97 FPS and the mix could have been done<br />

at this speed with good picture. The DA88 tape could have been pulled up to 30 FPS in the transfer<br />

to optical fi lm and the optical would be back in sync with the camera original.<br />

So, here again, pulling down and then pulling back up may seem like the more complicated<br />

workfl ow, in reality, it is not. Postproduction at video speed is always simpler and the better choice.<br />

220

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!