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 :)

Syncing Audio / TC on Pro Playback Shoots?

Alexander Alexandrov

Well-known member
Joined
Nov 24, 2008
Messages
848
Reaction score
0
Points
0
Age
44
Location
Los Angeles, CA
Website
alexanderalexandrov.com
I have a few questions about syncing TC / Camera / Audio on Playback (music video, commercials) shoots on professional large productions

what is a common proper workflow? here are the areas that are confusing to me:

1. each time a song is played back, on each replay is it re-playing with the same timecode as before or is the TC new each time it plays? if it is new, how is it later synced in post? do playback(sound) then provide the same track as multiple files with timecode played to sync?

2. are the RED cameras on such shoots usually TC-synced with playback? if they are, they must be resyncing on each camera reboot? I haven't seen this done many times, but i haven't been paying attn to these parts earlier.

3. if it is not syncing properly, is there a way for DIT to know by looking at the footage on set?

3. if generating dailies, is it possible to sync with playback sound in redcineX on set or is it usually done later with offline proxies?
 
On the music vids I've worked on we imported the song into FCP with a Timecode Generator Effect applied to the blank slug in the Video track. I exported that QT movie out of Compressor (or File>Share out of FCP) as an iPhone h.264 and imported it into an iPhone. They used the iPhone screen as the slate, and fed the amp that powered the playback speakers with the audio-out jack of the iPhone.
 
I've previously used a digital Nagra with audio files of the music as a playback device. The files were generated with TC embedded within them so that when it plays back, the Nagra will recognize the TC and send to its outputs in the following ways:

1 - TC out from the Nagra to the RED TC in.
*We used wireless to the Nagra, not a lockit box - TOD will NOT work here! It CANNOT free run*

2 - Mono audio out from the Nagra to the RED input.
*No need to sync dalies, its embedded when shooting at @ regular speed*

3 - Smart slate wirelessly jammed to the Nagra.
*Allows for a visual representation of the TC on frame*

4 - Audio out of Nagra to PA system for talent monitoring

Essentially this will allow for multiple clips to be recorded with overlapping TC so the editors can use them like a cutting a live show. All the different places you have your talent singing the same song are now able to be lined up without incident on top of each other via TC.

Note: There will be a 1 second lag in TC from the Nagra to the RED on set. This is normal but only 1 second, no more. The RED actually actually takes that time to record the live image to disk/card. It will line up later.

I suggest you do several tests to ensure accuracy.

I also advise against using things like an iPhone/iPod as they will drift differently each time you initiate playback. A Professional deck like the Nagra or Sound Devices will not have those kind of issues. Organization and line up will also not have to be done by hand.

It seems like drift is a non issue but let me tell you, after having to manually re-sync a Mos Def concert some years ago (every 2-3 minutes of playback) its not something I'll ever forget!
 
so this becomes like a multicam type shoot with 1 playback (although playbacks are multiple), and since timecode is always supplied in, cameras don't need to resynced on reboot.

I think what you're saying is that it is CUT like a multicam right? Its not shot that way - Although it could be!

The end result is numerous clips recorded at different REAL times but are stamped with TC saying they occurred at the SAME time, or closely overlapping as you won't always hit roll in a frame accurate manner.

And yes, reboots shouldn't cause issues with TC. I would however make sure that you're running correctly each time you power cycle the camera just for toots.
 
Yeah, what Michael says above.

All of the music videos I've ever done have used time-of-day code for picture (except for film, which is now rare), and then used wireless transmitted playback code to a TC slate for music. Do not use playback timecode for the camera. This is a bad idea for many reasons. Do not try to avoid using a real timecode slate, because you need real frame accuracy, not "close enough."

There are complex projects, like Dreamgirls, that required specialized workflows since they mixed live dialog with pre-recorded music. For that, the post crew came up with a system that put playback timecode on user bits, with time of day as the main timecode. But this was an unusual, very high-budget situation.
 
thanks Marc
Do not use playback timecode for the camera.
why?

if cameras are running it's own TC then syncing pic to playback can be done by visual slate only?

especially with RED (i don't think RedCineX allows timecode change on R3D files, for example like FCP does for quicktimes)

trying to figure out a quick way to transcode dailies already synced to playback timecode song on set in redcine and it'd be easy and possible if playback timecode was also the camera
 
Back
Top