Jump to content

timecode pain on live shoot...


edwar64896

Recommended Posts

Hope there is someone that might be able to help with this...

I'm doing sound on a multicam live event shoot this week. The record and edit frame rate is set to 23.976FPS (NDF) and thus I will be recording at 48kHz.

There will be a sequence that will require playback and I am intending to send timecode from my audio system to each camera using wireless link. I will probably also try and get a smart slate on set so that there is at least some visual representation of the timecode.

Unfortunately my audio playback system doesn't support 23.976ND fps - the lowest timecode rate it will go to is 24fps. This means I can't generate timecode at the right rate for playback.

I'm anticipating this to be a problem.

I can send timecode out from the playback system at most rates, just not 23.976ND

I am proposing to lay 30fps timecode up against the audio and send this to a smart slate so at least it will be possible to synch both cameras up against the audio track that I have recorded, even if the end framerate they will be using is different.

This is the first time I have come up against this little issue, so I would be grateful if forum members could possibly shed some light on this and suggest possible alternatives.

cheers,

Mark

Link to comment
Share on other sites

There will be a sequence that will require playback and I am intending to send timecode from my audio system to each camera using wireless link. I will probably also try and get a smart slate on set so that there is at least some visual representation of the timecode.

I'm confused. Why do the cameras need the audio timecode? I'd just send them a scratch track of the playback audio, and let the editor sync it by hand.

Unfortunately my audio playback system doesn't support 23.976ND fps - the lowest timecode rate it will go to is 24fps. This means I can't generate timecode at the right rate for playback.

If it's just a 3- or 4-minute song, a regular Windows laptop (even an old one) can run something like Courtney Goodin's BWF-Widget Pro, and the audio will hold sync for this amount of time with no problem. You can still send 23.976 playback timecode out to a slate provided you process the playback track beforehand (which has been discussed on the group before).

Link to comment
Share on other sites

+1

This sounds like a standard "music video" playback situation where you would put the song on one audio track and time code on the other track and send the output of the time code track to a slate. Be sure to have the time code start well before the song to have sufficient pre-roll.

Also, sending the song track to the cameras adds the capability of syncing by hand as Marc pointed out.

There are some in-depth discussions about music playback on the forum -- again, as Marc said.

Are the cameras going to be gen-locked?

Link to comment
Share on other sites

" generate timecode at the right rate for playback. "

the right rate is "non-integer"

this has been discussed before: the non-integer TC's are both counting at the same .1% slower rate, compared to the integer rates which are in complete frames withing the clock second. non-integer rates complete the frames, but it takes a little bit longer than an exact second. 23.976 TC will match 29.97 TC at the :00 frame of each second, and the :12 frame will match the :15 frame each second.

Link to comment
Share on other sites

My gut feeling is that the editor doesn't really need to hear the timecode of the playback music -- but I think a visible slate with playback TC numbers is useful, just in case they choose to do a pickup in the middle of the song, and they're not sure which verse it is.

Link to comment
Share on other sites

My gut feeling is that the editor doesn't really need to hear the timecode of the playback music -- but I think a visible slate with playback TC numbers is useful, just in case they choose to do a pickup in the middle of the song, and they're not sure which verse it is.

Agreed. I'm not sure if you're referencing my post, if so, I wasn't suggesting an audio TC track to cam. The audio TC track is fed just to the slate -- either wireless or wired. The audio music track is sent to the playback speakers -- and can also be sent to the camera as an audible reference for post.

I think we're both saying the same thing and I was only meaning to elaborate a bit. I hope I didn't add a confusion factor.

Link to comment
Share on other sites

When did 23.98/23.976 gain the title of NDF ......

I agree, I wince every time I see it. In the old TLC display (an editing program used for film dailies), it still said "N" on the far right. At least they didn't use "N" for 25.00 timecode for 50Hz projects.

I agree with The Senator that 29.97ND timecode works fine for audio playback in 23.976 video projects. I think it makes more sense from a workflow point of view to have everything at the same timecode rate, but this alternate method can still work.

Link to comment
Share on other sites

" When did 23.98/23.976 gain the title of NDF "

by definition...

there is no SMPTE/EBU standard for 23.976 DF TC

30 FPS is also NDF

there is also no SMPTE/EBU standard for 30 frames DF TC

My response was to be taken as sarcasm senator :P

Link to comment
Share on other sites

there is also no SMPTE/EBU standard for 30 frames DF TC

Whenever anybody mentioned 30DF at Complete Post in the 1990s, everybody's eyes would glaze over and the engineers would start screaming "No, No, A Thousand Times No!"

Sound Devices has a nice explanation of drop and non-drop rates in their user manuals:

• 23.976 – This frame rate is most often used in productions shooting high definition video. Counts 0.1% slower than real time.

• 24 – Frame rate of standard film. Sometimes, it is also used in high-definition video production when the video files go through a telecine process.

• 25 – The frame rate of PAL video. Most often used in video and film production in Europe and other PAL-based environments.

• 29.97 – The frame rate of NTSC color video. Most often used in the USA and other NTSC based nations. Counts 0.1% slower than real time.

• 29.97DF – The frame rate of NTSC video modified to match real time. Drop frame time code is primarily used in the NTSC broadcast industry where it is often required that the time code of finished program material reflects actual real time duration. Drop frame is not common for production time code.

• 30 – Originally, the standard frame rate for American black and white television. Today, it is most often used to sync sound to film where transfer to NTSC video is expected.

• 30DF – This is a rarely used non-standard frame rate. Do not use unless specifically requested by production.

• 30+ – This setting is specific to Sound Devices recorders. Records at 48.048 sampling rate at 30 frames per second but stamps the file at 48 kHz, 30 frames per second.

I would have said "use 30DF at your own peril, and risk the death of a thousand horrible, painful deaths."

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...