23.976 vs 24 FPS: irrelevant to sound and timecode with file based workflows?

[Milivoj]

I will be starting a feature film shoot with the Sony F-55. The final delivery will be DCP, but the camera cannot record 24 FPS with the current firmware. It will only do 23.976. Since I'm in Europe, I have always been able in the last 30 years to ignore this silliness of fractional frame rates. But now I need to understand it's implications.

The thing I don't understand is why some timecode generators and audio recorders have a separate 23.976 fps setting.

We would have a TC generator on the camera, synced to the audio recorder (Sonosax R4) , which records the time of day.

Both the audio files and camera files store the time of the first frame. There is no more continuous TC track as there used to be with audio and video tape recorders. Only the first frame's time of day.

Audio doesn't have different frame rates. It is (usually) recorded at 48'000 samples per seconds. So any FPS setting in the recorder should make no difference whatsoever to the recorded audio.

And audio doesn't even record a timecode at all. What the "bext" and iXML chunks contain are samples since midnight (and the "fmt " chunk contains the samples per second). The timecode itself is calculated afterwards by the software using the file (like Avid, etc.).

I understand that at 23.976 FPS, at the end of a shot, the picture's timecode as displayed in the Avid would not match the real world time anymore, drifting by about 1 frame every 42 frames.

But as long as the sync is done at the start of the picture, that shouldn't matter. If the picture plays back at the same frame rate at which it was recorded (23.976), and the sound plays back at 48K samples per second, both will stay in sync.

So my questions are:

• When using time of day timecode, what difference does a 23.976 frame rate setting on the TC generator actually do? Of course, the difference between 24/25/30 is relevant to converting fractional seconds of the time of day into "frames". But 23.976 or 24 should make no difference. Both count frames from 0 to 23.
• What does any sort of frame rate setting actually do on the audio recorder? I guess it would only change the frame number in the TC output, which is fed to the external generator when syncing. As above, 23.976 or 24 should make no difference?
• Is a separate 24 and 23.976 setting actually only relevant to tape based workflows?
• Or what have I overlooked or misunderstood?
• Am I an idiot? (if yes, please be kind and elaborate ...)

(Of course, at the end the sound will need to be stretched a little for the DCP since DCP's cannot be 23.976)
 

[atheisticmystic]

I've just turned the "Wielage Light" on over Gotham...

Your query will be momentarily answered in a proficiency rarely witnessed in non-cybernetic organisms.

Enjoy the "hold music"...

[John Blankenship]

Set everything to 23.976 (recorder, camera, jam box, etc.) and relax.

If they eventually go to actual 24, picture and sound will both be "pulled up" then.

[rich]

has the camera been brought in to the EU?

seems odd that an EU model of camera cant do 24fps.

or is the film for an American production?

[Milivoj]

Yes, the camera really can't do XAVC 24 fps, even if bought in the EU. (It does 25p and 50i, but that's not what we need). The next firmware should enable true 24, but we start shooting before that.

 

My concern is not the camera, but this audio recorder / TC generator setting which doesn't seem to make sense, and I want to make sure I understand what difference (if any) it makes.

[rich]

what does post want.

but, do what John Blankenship said a few replies ago, and all will be, at worst, just fine.

[RPSharman]

You are technically correct, but given editing software setups, you're better off just setting everything at 23.976. Works well for us over here, and we've been known to shoot one or two projects on 23.976 HD which eventually make it to 24 film prints and 25 PAL broadcasts and 29.97 NTSC silliness.

The safest solution at the beginning of the process is to have everyone with matching TC and frame rates, regardless of wether it actually matters or not.

[Wandering Ear]

When importing the audio files into an NLE, the frame rate you set is used by the NLE (Except FCP) to calculate the timecode number from the samples since midnight.  Despite audio not having frames, setting the frame rate correctly is important to keeping things accurate throughout the workflow.  Match the camera settings, and happy shooting.

[studiomprd]

Hi, and welcome...

" But now I need to understand it's implications. "

this is discussed here frequently.  the site search is lame, so try Google, with jwsoundgroup.net as your dirst search term.

" The thing I don't understand is why some timecode generators and audio recorders have a separate 23.976 fps setting. "

not understanding that simple, basic issue, renders pretty much the rest of your post's suppositions as somewhat immaterial as your base assumption " irrelevant to sound and timecode with file based workflows? "is incorrect

 

" The next firmware should enable true 24, but we start shooting before that. "

typical ... something can't do what it needs to, but I'll use it anyway...

 

As Marc has not arrived to repeat what he has explained here so many times before,  maybe try that Google idea ?:?

 

particularly in North America, we got stuck with a slowing down of the actual frame rates of NTSC video from integer rates (30 - 24 FPS) to slightly slower non-integer rates, (23.976 - 29.97  FPS), thus the 24th or 30th frames are not finished in one actual second, but they are completed in the next actual second.  this is because the frame rate of the capturing (audio and / or video) have been slowed down by .1%. Thus if something has its frame rate changed, its speed is changed...this was mostly a problem going from film at 24.000 FPS to NTSC video at 29.97 FPS... the video was actually going slightly slower than it had been on the film.  thus the separately recorder had to also be slowed down...

now, you finish your homework by doing some searching, as this information is all over the Internet.

[Philip Perkins]

Don't be the guy who bucks the accepted workflow.  The default expectation in post, barring special notification, is that camera and sound will have TC of the same frame rate for all sync sound shooting, right?  If your posties want something else then make sure you have an email proving that they asked for that.  Why?  Because errors or misunderstandings in this area can lead to costly fixes down the line--not just frustration but real money being spent and time lost.  As the Senator often says "how about a workflow test?"

 

philp

[studiomprd]

"  Because errors or misunderstandings in this area can lead to costly fixes down the line--not just frustration but real money being spent and time lost. "

aka Time Effort and MONEY

[Marc Wielage]

So my questions are:

• When using time of day timecode, what difference does a 23.976 frame rate setting on the TC generator actually do? Of course, the difference between 24/25/30 is relevant to converting fractional seconds of the time of day into "frames". But 23.976 or 24 should make no difference. Both count frames from 0 to 23.
• What does any sort of frame rate setting actually do on the audio recorder? I guess it would only change the frame number in the TC output, which is fed to the external generator when syncing. As above, 23.976 or 24 should make no difference?
• Is a separate 24 and 23.976 setting actually only relevant to tape based workflows?
• Or what have I overlooked or misunderstood?
• Am I an idiot? (if yes, please be kind and elaborate ...)

(Of course, at the end the sound will need to be stretched a little for the DCP since DCP's cannot be 23.976)

 

 

Many misconceptions here. Last question first: any company who makes DCPs can routinely do a .1% pull-up on your entire project to go from 23.976 to 24.00fps at no charge. It's not a big deal. By the same token, if they decide to do a film-out to digital negative, it's not a problem to output at 24.00fps at the very end. It's more of a consideration for initial production and the later re-recording mix session.

 

23.976 timecode does make a difference provided the picture is also going at 23.976. The advantage of going at this speed is that most American editorial workflows are designed around it. Tape is no longer a consideration for post in America except for final delivery, and even then, HDCam-SR and similar formats are generally being phased out now. I know of many networks that still require it, but it's in addition to the file version. 

 

I have worked on a handful of 24-frame timecode projects that were a little klutzy at the beginning, but eventually worked out OK. But because 23.98 (aka 23.976) is so prevalent, I think shooting at this rate makes more sense. So that means camera timebase, camera speed, external timecode, slate timecode, and sound timecode all have to be set to 23.976. 

 

I would get your editor involved and have your producer hire a post supervisor if they haven't already. A sit-down meeting with your post house can also cover these essentials very well. The suggestions to do a workflow test prior to production are good ones. Just shoot three or four minutes, picture and sound, and verify that everybody is set to the same timecode rate. Once you've nailed that down, have the post supervisor or editor send out an official memo verifying the speed and other parameters (file formats) and so on. 

[OmahaAudio]

 

now, you finish your homework by doing some searching, as this information is all over the Internet.

Or, he could ask here and get comprehensive and cogent information quickly.

 

Not from you, perhaps, but from others more willing to help.

[mikewest]

Exactly!

 

Do as post wants as now days they rule the technical scene.

 

Always ask what is needed, do not guess then it's not your fault.

 

mike

[Jay Rose]

When importing the audio files into an NLE, the frame rate you set is used by the NLE (Except FCP) to calculate the timecode number from the samples since midnight.  

 

And also in the DAW, once the project gets to audio post.

 

To explain: yes, each clip has an inherent speed based on the audio sample rate. But the location of each clip on the timeline is based on the computed sample number based on the frame rate. 

 

In practical terms it shouldn't matter much. The editor will curse and adjust sync. Audio post and the editor will agree on a timecode format for interchange, so the OMF / AAF import will agree with the editor's adjusted version. But if audio has to bring in any additional files, they won't be able to rely on timecode if the production format was different.

 

This isn't half as bad as when a production decides to change the timecode format halfway through the edit, as when a producer specifies ndf and then discovers the network demands df. That can totally screw up audio post, depending on the software they use. If pix is using FCP, it can even screw up the sample rate!

 

---

 

Historical note:

 

When everything was 24 fps and had holes down the side, we didn't have to worry about these things. 

 

Instead, we had to worry about generation loss. That was much, much worse.

[Marc Wielage]

BTW, I have worked on projects where the picture and sound timecode did not agree, but we figured out how to force the sound to the correct playback speed. But the moment that happens, the timecode goes out the window and we have to hand-sync everything by eye, which increases syncing time by a factor of 10. Instead of 10 seconds per shot, it winds up well over a minute -- even worse when it comes to early pre-rolls, late rolls, staggered camera rolls, incorrect sound slates, and similar production problems. I've even done 25fps sound with 23.98 film projects... but it's painful. 

[studiomprd]

" specifies ndf and then discovers the network demands df. "

unless specified otherwise: DF timecode should normally be applied only to the final output (for delivery).

Edited August 23, 2013 by studiomprd

[Jack Norflus]

" specifies ndf and then discovers the network demands df. "

DF timecode should normally be applied only to the final output (for delivery).

Maybe - but not always

 

All the work I do for NBC and CBS requires all field audio and video recorded as DF

[Wandering Ear]

Maybe - but not always

All the work I do for NBC and CBS requires all field audio and video recorded as DF

I'm working on a show for tlc right now that wants 29.97 df. It is common, maybe less these days, but still common.

[John Blankenship]

I've done a couple of shows recently that used drop frame in the field.

[Jay Rose]

 

unless specified otherwise: DF timecode should normally be applied only to the final output (for delivery).

 

Why???

 

Any modern pix or audio editing software can cope with DF all the way through the workflow.

 

AND...

 

if they're using FCP in pix, changing from NDF to DF partway through can cause all kind of problems with the audio layback. Certain versions will assume - without asking, or giving the operator a chance to cancel - that you now want a pulldown on any audio imports! So your files will be out of sync, and unless the editors already know and can cope with this issue, they'll blame you.

 

Even if you all know about the (bug? feature? bats##t product design?), someone will still have to do a sample rate conversion to compensate. Which will compromise the sound, because you have to convert s/r without affecting TRT.

[Marc Wielage]

if they're using FCP in pix, changing from NDF to DF partway through can cause all kind of problems with the audio layback. Certain versions will assume - without asking, or giving the operator a chance to cancel - that you now want a pulldown on any audio imports! So your files will be out of sync, and unless the editors already know and can cope with this issue, they'll blame you.

 

All American network scripted shows that I know of were shot and posted in NDF in the 1980s and 1990s, and once HD came in circa 2002-2004, it all went 23.98 (essentially NDF). Only at the very end, right before the audio layback, did they switch to 29.97DF for air (with 1080i videotapes or files). They have charts showing the 3-second-per-hour error of NDF code, and compensate for that in editing so that the DF deliverable will hit the correct timings for network.

 

I personally think DF makes no sense for production, but acknowledge that it's so ingrained in low-budget cable shows and many news crews, it's the way things are. Me, I just shrug and give the client what they want. They're not going to change their workflow just because of me. 

[John Blankenship]

+1 What Marc said.

[Bash]

You might also want to check with post production as to whether they want you to shoot the location audio at a sample rate of 47.952 (or whatever it is) kHz. Sometimes this can help as when it is pulled up by the 0.01% the end result is 48kHz.

Kindest regards,

Simon B

[studiomprd]

" went 23.98 (essentially NDF) "

important to note:  there is no industry standard specification for either 23.976 DF or 30FPS DF time-codes; SMPTE/EBU do not cover these non-standard rates.  any implementations are proprietary...