Camera sensor, project and timecode rates

A camera can describe three different rates.

“We shot at 48” leaves important questions unanswered. Did the sensor capture 48 pictures per second? Is the clip intended to play at 48, 24 or 23.976? What timecode rate and counting mode identify it? A camera report should answer each question explicitly.

These functions may share a setting in one camera and have separate controls in another. Timecode is not a measurement of every underlying sensor operation. Likewise, a quoted sensor readout time describes how quickly an image is read, not how many recorded pictures the clip contains per second. Rolling-shutter readout concerns timing across an image; capture rate concerns the spacing of successive pictures.

Shutter angle is another quantity. Under the usual electronic-shutter timing relationship, exposure time is angle ÷ (360 × capture fps). A 180° setting gives 1/48 second at 24 fps and 1/192 second at 96 fps. It changes exposure and motion rendering; it does not by itself select the clip’s playback duration.

Off-speed changes the relationship to elapsed time.

For a constant capture rate, pictures = recording seconds × capture fps. If every captured picture is retained once, playback seconds = pictures ÷ playback fps. The duration multiplier is therefore capture fps ÷ playback fps. Higher capture than playback produces slow motion; lower capture produces fast motion.

The last two rows have the same picture count and playback duration but different recording durations. Exact 48 capture with a 23.976 project gives a 2.002 duration multiplier. Capture at 48000/1001, often displayed as 47.952, gives exactly 2× at that project rate. Read the actual setting rather than assuming every displayed high-speed rate is an integer.

These examples assume continuous, constant-rate capture, the stated integer picture count, and no skipped, repeated or interpolated output pictures. Camera start/stop boundaries and variable-rate recording require the actual recorded count. Merely placing a clip on another-rate timeline does not guarantee this frame-preserving treatment.

Camera behaviour needs a model and manual version.

The following are two documented implementations, not a rule for every slow/quick-motion mode. Test the intended recording format, camera software and post-production path before relying on camera sound or timecode.

Do not extrapolate a maximum capture rate from these examples. Supported combinations depend on the camera and format. ARRI specifically lists sensor mode, codec, media model and licence as constraints; RED identifies project time base and sensor format. A quoted maximum without its recording configuration is insufficient for a shoot plan.

Labels cannot restore normal-speed motion.

A timecode label can locate a picture, but it does not make forty seconds of slow-motion playback fit ten seconds of continuous production sound. A matching start label can establish an alignment point while the two recordings immediately diverge in playback duration.

In the cited ALEXA 35 SUP 6.2.0 manual, off-speed operation automatically changes Free Run to Rec Run. Rec Run advances once per captured image, and the previous Free Run timecode returns when sensor and project rates match again. This is a specific implementation to document in the camera report, not a universal off-speed timestamping convention.

Drop-frame and non-drop-frame describe label counting. Switching count mode does not change the sensor’s capture speed or retime pictures. Fractional-rate timing also needs explicit treatment: 240 pictures captured at exactly 24 fps span 10 seconds, but the same 240 pictures played at 24000/1001 span 10.01 seconds. Rounded labels such as “23.98” should not become literal 23.98 in duration calculations.

For continuous reference, distinguish receiving LTC for labels from using a supported reference to control camera timing. Some cameras can derive synchronization from LTC under specified conditions. The timecode, genlock and word-clock guide explains those separate jobs and the device-specific exceptions.

Give editorial enough information to reconstruct the take.

Record camera model/software, clip and reel identifiers, sensor mode, codec, capture rate, project rate, timecode rate/count mode and generator mode. Add whether the take is intended for normal-speed sync, slow motion, speed ramps or MOS. Identify camera audio availability and the separate sound files.

Keep continuous sound on its own real-time basis unless the agreed workflow calls for a deliberate pull or stretch. Slate the take, note the off-speed setting, and retain a visible and audible sync event where practical. A slate can identify the relationship at an instant; it does not guarantee that off-speed picture has continuous lip sync at its project playback rate.

For a test take, count recorded pictures, compare real recording duration with project playback duration, and check how the receiving software reads capture metadata and timecode. Confirm whether proxies and editorial transcodes retain that information. Include a later sync event when assessing normal-speed sound alignment; start alignment alone misses progressive drift.

If editorial needs real-time motion from a slow-motion clip, document the chosen treatment. Playing all pictures faster and converting them to a lower-rate real-time output are different operations. Preserve the camera originals and communicate any interpretation override before making transcodes or turnovers.

Calculate the picture count before the handoff.

Use the conform calculator to compare fixed-picture-count playback at different rates. Keep the capture-time calculation separate so that “ten seconds recorded” and “forty seconds on the timeline” remain clear.

Timecode Pro supports calculation and format comparison; it does not configure a camera, inspect clip metadata or retime recorded media. Verify the selected app format’s behaviour before using a result in a camera or sound report. Mathematical examples here use physical elapsed time and the exact rates stated.

Continue with frame-rate conversion for delivery and drop-frame versus non-drop-frame timecode when planning the master’s playback rate and labels.