If you are searching for how to translate video frame rates, how to translate FPS and timecode, or how to preserve 23.976, 24, 25, 29.97, 30, 50 and 59.94 frame-rate specifications across languages, the first rule is that a frame-rate number is part of a timing system. The label around it may be translated, but the value, scan method and timecode convention must still describe the same audiovisual sequence after translation.
Video-specification translation matters in film and television production, streaming, broadcast delivery, subtitling, dubbing, post-production, camera manuals, editing software, archival media, online video and technical documentation. A target-language description can sound perfectly natural yet still be wrong if it rounds 23.976 to 24 without permission, confuses frames per second with fields per second, drops the distinction between progressive and interlaced scan, or treats drop-frame timecode as though actual video frames were being removed.
This guide explains how to translate video frame rate and timecode specifications without changing timing. It covers FPS, integer and fractional rates, 23.976 versus 24, 29.97 versus 30, 59.94 versus 60, progressive and interlaced notation, fields, variable frame rate, constant frame rate, timecode, drop-frame and non-drop-frame conventions, frame-rate conversion, slow motion, speed changes and how to verify the translated specification against the media file and delivery requirements.
Why frame-rate translation is really time-system translation
Frame rate describes how many image frames are captured, stored, transmitted or presented per unit of time. A difference that looks numerically small can affect runtime, synchronization, timecode counting and compatibility with a delivery standard. That is why 29.97 and 30 should not be treated as casual stylistic variants.
Video documents also mix several related but distinct concepts: capture rate, playback rate, project timeline rate, display refresh, field rate, timecode base and delivery frame rate. Translation should preserve which layer the source is talking about. A camera may capture high frame rate for slow motion while the final project plays back at a lower timeline rate.
Timecode adds a counting system on top of the video. Drop-frame timecode does not remove picture frames from the video stream; it adjusts the numbering convention so clock time and timecode remain closely aligned for particular fractional-rate systems. Translators should therefore preserve the technical term rather than interpreting “drop” as missing visual content.
The safest workflow protects every numeric rate and technical code, translates the explanatory labels, and verifies the target against file metadata, project settings, timecode display and delivery specifications.
A reliable translation method
1. Identify the exact frame rate
Record the source value exactly, including decimal precision. Preserve 23.976, 23.98, 24, 29.97, 30, 50, 59.94 and 60 as distinct labels when the source distinguishes them. Do not round automatically because the decimal looks awkward.
2. Identify what the rate describes
Determine whether the number is capture FPS, playback FPS, timeline FPS, delivery FPS, display refresh, field rate or a high-speed recording setting. The same number can appear in several layers of one production.
3. Preserve progressive and interlaced notation
Labels such as 1080p25 and 1080i50 carry more than resolution. The p and i indicate scan structure, and the accompanying number may be framed differently depending on the notation convention. Keep the complete source designation intact.
4. Keep frame rate separate from resolution
1920 × 1080 describes pixel dimensions; 25 fps describes time sampling. Translators should not merge display-resolution and frame-rate fields simply because they appear together in a delivery profile.
5. Preserve timecode mode
If the source specifies drop-frame, non-drop-frame, source timecode, record timecode or another timing mode, keep the label and any standard abbreviation. Do not replace the mode with an inferred equivalent.
6. Keep separators and punctuation meaningful
Timecode can be written with colons, semicolons, periods or other separators depending on software and convention. Do not localize punctuation casually when it carries technical meaning in the workflow.
7. Treat frame-rate conversion as a technical transformation
Converting 24 to 25, 25 to 29.97 or variable-rate footage to a constant-rate deliverable can involve duplication, interpolation, cadence changes or speed changes. Translation should describe the source process accurately, not perform or prescribe conversion unless that is the task.
8. Verify against the media and project settings
Use file metadata, editing-software project settings, camera records, timecode windows and delivery documents. The target text should still point to the same actual media behaviour.
Twenty-four recurring frame-rate and timecode translation problems
1. 24 fps
A source that states 24 fps should remain 24 frames per second unless the project explicitly requests a standards conversion. The value may be associated with film-style production or digital cinema contexts, but the translator should preserve the source rather than generalize.
Translate “frames per second” naturally and keep fps if the target technical audience uses the abbreviation. Do not change the number because another market commonly uses a different delivery rate.
For QA, inspect file metadata or project settings and confirm the target documentation still refers to the same 24 fps source or deliverable.
2. 23.976 fps
23.976 fps is numerically close to 24 but should not be rounded to 24 in a technical specification without authorization. Runtime and synchronization relationships can depend on the distinction.
Some software or documents may display 23.98 as a shortened label. Preserve the source representation and avoid “correcting” one to the other unless the system explicitly defines them as display variants.
QA should compare media metadata and the editing timeline rather than relying on title-card wording.
3. 25 fps
A 25 fps source should keep that rate and any associated production context. Translating 25 fps as “European frame rate” may be too broad unless the source itself explains the standard that way.
Keep the numeric rate and translate only the descriptive label. If a target document compares 24 and 25 fps, preserve both values rather than simplifying the distinction for readability.
QA should check runtime if the source discusses speed-up or conforming between rates.
4. 29.97 fps
29.97 fps is another fractional rate that should remain exact. Do not translate it as 30 fps simply because the target prose prefers round numbers.
If the source associates 29.97 with drop-frame or non-drop-frame timecode, preserve that mode separately. Frame rate and timecode numbering convention are related but not identical fields.
QA should confirm both project rate and timecode mode in the source software or delivery sheet.
5. 30 fps
A true 30 fps source is not automatically the same as 29.97. Preserve the integer rate when that is what the source specifies.
If marketing material casually uses “30 fps” while technical metadata says 29.97, translate the source faithfully at each level and flag the inconsistency if the project requires reconciliation. Do not silently rewrite the technical field.
QA should privilege authoritative file or workflow metadata for technical delivery instructions.
6. 50 fps
50 fps may be used for smoother motion, sports, slow-motion capture or particular broadcast and online workflows. Preserve both the rate and whether it is capture or playback.
Do not confuse 50 frames per second with 50 fields per second in interlaced contexts. Translate “frame” and “field” consistently as separate technical concepts.
QA should inspect scan type and project settings.
7. 59.94 fps
59.94 fps is close to 60 but should remain exact in technical documentation. The fractional relationship can matter to synchronization and delivery acceptance.
Translate the surrounding term but preserve decimal precision. If the source writes 59.94p, keep the progressive-scan indicator attached to the rate.
QA should compare the target against the encoded media properties.
8. 60 fps
A true 60 fps rate should not be normalized to 59.94. Preserve the source and any platform-specific requirement.
If consumer-facing copy uses 60 fps as a rounded marketing description while technical specs use 59.94, keep the two source layers distinct instead of forcing one terminology across both.
QA should identify which field governs actual delivery.
9. Progressive scan
Progressive scanning presents full frames in sequence. A notation such as 1080p25 combines spatial resolution, scan type and frame-rate context.
Translate “progressive” in explanatory prose but keep standardized p notation in technical codes. Do not delete the letter because the resolution number seems sufficient.
QA should compare p/i notation with file metadata and delivery requirements.
10. Interlaced scan
Interlaced video represents temporal information through fields. Specifications can be expressed using frame-oriented or field-oriented conventions, so translators must preserve the source notation rather than infer a different counting basis.
Keep i notation and any field-rate explanation. Do not describe interlaced content as progressive because both display similar resolution labels such as 1080.
QA should inspect field order and scan metadata where the source discusses them.
11. Fields per second
Fields per second is not automatically the same thing as frames per second. A translator should keep field terminology distinct in interlaced-video instructions.
If the source uses a shorthand that a target audience may misread, add explanatory wording rather than replacing the technical value. Preserve the standard notation used by the project.
QA should verify whether the numeric label counts frames or fields.
12. Constant frame rate
Constant frame rate means the media follows a fixed frame cadence for the relevant file or stream. This can matter for editing, synchronization and platform delivery.
Translate the term consistently and retain any abbreviation such as CFR if the source uses it. Do not infer that a file is constant-rate merely because a player displays one average FPS number.
QA should inspect media metadata with a suitable tool.
13. Variable frame rate
Variable frame rate allows frame timing to vary. Mobile phones, screen recordings and other sources may use it, and editing software can behave differently with VFR media.
Translate VFR accurately and do not rewrite a reported average FPS as though it were a constant exact frame rate. Preserve the distinction between average rate and timing mode.
QA should compare file metadata and the editing workflow described by the source.
14. Timecode hours, minutes, seconds and frames
A timecode such as 01:12:35:18 generally represents hierarchical time fields ending in a frame count. The last field is not decimal fractions of a second.
Translate labels such as hours, minutes, seconds and frames if they appear in prose, but keep the source timecode string exact. Do not localize separators as ordinary punctuation without knowing the workflow convention.
QA should compare the translated cue or instruction with the exact frame in the source media.
15. Drop-frame timecode
Drop-frame timecode adjusts timecode numbering for certain fractional-rate systems so displayed timecode tracks elapsed clock time more closely. It does not mean that picture frames are physically deleted from the video.
Use the established target-language technical term and preserve DF or other notation when present. Avoid literal wording that suggests damaged or missing frames.
QA should inspect the source timecode display and project setting rather than infer the mode from frame rate alone.
16. Non-drop-frame timecode
Non-drop-frame timecode uses a continuous frame-number count without the numbering adjustment associated with drop-frame mode. The distinction can affect how timecode corresponds to clock duration at fractional rates.
Preserve NDF or the full technical term and do not simplify both modes to generic timecode. A post-production instruction may depend on the exact mode.
QA should compare timeline settings and source documentation.
17. Source timecode
Source timecode refers to timing associated with the original media or recording. It may differ from the editing timeline or sequence timecode.
Translate source, record, clip and sequence timecode terms consistently. Do not copy a source-media timecode into a target instruction that is meant to reference program time.
QA should identify which clock the source document is referencing.
18. Program or sequence timecode
A finished sequence can have its own timeline starting point, for example a program beginning at a specified hour code. That timeline is separate from each source clip’s embedded timecode.
Preserve the distinction in subtitle, dubbing and review documents so a target-language note refers to the same program frame as the source.
QA should test a sample cue against the final sequence.
19. High-frame-rate capture for slow motion
A camera may record at 120 fps or another high rate and then play the clip on a 24, 25 or 30 fps timeline for slow motion. Capture rate and playback rate are different fields.
Translate both labels explicitly. Do not describe the final program as 120 fps merely because the source footage was captured at that rate.
QA should compare camera metadata and timeline interpretation settings.
20. Overcranking and undercranking terminology
Film and video workflows may use overcrank or undercrank to describe capture-rate relationships that create slow or fast motion at playback. Literal translation without the capture/playback relationship can confuse readers.
Use established target production terminology and, where useful, explain whether the camera captures more or fewer frames than the intended playback rate.
QA should preserve the direction of the speed effect.
21. Speed change during conform
Some workflows conform footage from one frame rate to another by changing playback speed rather than synthesizing or dropping image frames. That changes runtime and often audio timing.
Translate terms such as conform, speed change and retime accurately. Do not imply that every frame-rate conversion preserves exact runtime.
QA should compare source and target durations when the source discusses speed conversion.
22. Frame interpolation
Frame interpolation creates intermediate frames algorithmically in some conversions or motion-processing systems. It is not the same as simply changing the metadata label.
Translate the technical process accurately and do not promise quality improvements that the source does not claim. Optical-flow, motion-compensated and simpler interpolation approaches can behave differently.
QA should keep processing method separate from target frame-rate value.
23. Subtitle frame references
Subtitling and QC notes may reference exact timecodes. If the target translation changes the displayed cue wording, the timing reference should still point to the same program moment.
Do not convert timecodes by eye when a frame-rate change is involved. Use the actual project timing system and preserve whether the cues belong to source, sequence or delivery timecode.
QA should spot-check translated notes against the video frames they describe.
24. Delivery profile name
A delivery specification may combine resolution, frame rate, scan type, codec, colour information and audio settings under one profile. A label such as 1080p25 should remain traceable to the same technical profile.
Translate descriptive headings but keep profile codes and required values exact. Do not adapt the delivery profile to a target market merely because another standard is common there.
QA should compare the final translated delivery sheet with encoded output properties before release.
Common failure modes
1. Rounding 23.976 to 24
They are close but can behave differently in timing and workflow. Preserve the source rate.
2. Rounding 29.97 to 30
Technical delivery specifications should keep the fractional rate when that is what the source states.
3. Confusing frames and fields
Interlaced video can be described using field rates. Keep frame and field terminology distinct.
4. Treating drop-frame as removed video frames
Drop-frame is a timecode numbering convention in relevant workflows, not missing picture content.
5. Translating timecode punctuation as ordinary typography
Separators can carry workflow meaning. Preserve the source convention unless the technical system explicitly requires another.
6. Confusing capture rate with playback rate
High-speed capture can be played back on a lower-rate timeline. Keep both values and roles visible.
7. Treating variable frame rate as one exact constant rate
An average FPS display does not necessarily mean every frame interval is constant.
8. Changing delivery standards for target-market familiarity
Translation should preserve the requested technical deliverable. Standards conversion is a separate production decision.
Worked practice
Practice 1: 23.976 project
Situation: A source specification requires 23.976 fps progressive video.
Reasoning: Preserve 23.976 and progressive scan. Do not simplify to 24p unless the source authorizes it.
Practice 2: 29.97 drop-frame timecode
Situation: A post-production note specifies 29.97 fps with drop-frame timecode.
Reasoning: Preserve both the fractional frame rate and the DF mode. Do not describe the video as having missing frames.
Practice 3: Interlaced delivery
Situation: A delivery sheet uses 1080i notation and separately discusses field order.
Reasoning: Translate interlaced and field-order terminology while preserving the full technical code and field relationship.
Practice 4: High-speed capture
Situation: Footage is captured at 120 fps for playback in a 30 fps sequence.
Reasoning: Keep capture and playback rates as separate fields so the slow-motion intent remains clear.
Practice 5: Variable-frame-rate phone clip
Situation: Metadata reports variable frame rate with an average near 30 fps.
Reasoning: Translate VFR explicitly and do not state that the source is a constant 30 fps file.
Practice 6: Subtitle QC note
Situation: A reviewer flags a subtitle at 01:12:35:18.
Reasoning: Keep the timecode exact and verify the translated note against the same frame in the program timeline.
Practice 7: Frame-rate conversion
Situation: A workflow document says footage is converted from 25 fps to another delivery rate using a specified processing method.
Reasoning: Translate the method and both rates without implying a different conversion technique.
Practice 8: Delivery profile
Situation: A platform requires a named profile combining frame rate, resolution, codec and audio settings.
Reasoning: Translate descriptive instructions but preserve the profile values exactly and verify the final encoded file.
Metadata tools, editing systems and AI
Media-file metadata, camera reports, editing-system project settings, waveform/timecode displays and official delivery specifications are stronger evidence than casual player readouts. Technical translation should refer to the system that actually controls capture, edit or delivery.
AI can explain 23.976 versus 24, progressive versus interlaced and drop-frame versus non-drop-frame timecode, but it can also round values or simplify jargon for readability. Protect technical tokens and ask for explanatory prose around them rather than replacement values.
When the translation is used for subtitling or dubbing, spot-check exact cues after any frame-rate conversion. A mathematically small rate change can shift timing relationships over long runtimes if the project treats source and target clocks differently.
How this fits the wider eduKate translation system
Video timing translation combines numbers, abbreviations, temporal reference and technical workflow language. The broader method is developed in Master Art of Translation | The Complete System for Moving Meaning Between Languages. Vocabulary depth connects to the Vocabulary Learning Hub, while temporal expressions, reference and instruction structure connect to How English Works. The special rule here is synchronization: translated wording must still point to the same frames, timecode positions and delivery timing as the source.
FAQ
Is 23.976 fps the same as 24 fps?
They are close but not identical. Preserve the exact source rate in technical documentation.
Is 29.97 fps the same as 30 fps?
No. Do not round the fractional rate in a technical specification without authorization.
What does FPS mean?
Frames per second, but always confirm whether the source is talking about capture, playback, timeline or delivery rate.
Does drop-frame timecode remove video frames?
No. It changes timecode numbering in relevant fractional-rate workflows; it does not delete picture frames from the media.
What is non-drop-frame timecode?
It is a timecode numbering mode without the drop-frame numbering adjustment. Preserve the source mode.
Are frames and fields the same?
No. Interlaced systems use fields as part of image timing. Keep frame and field terminology distinct.
What is variable frame rate?
It is a timing mode in which frame intervals can vary rather than following one constant cadence throughout the media.
Can I convert a frame rate while translating?
Not as an ordinary language edit. Frame-rate conversion is a media-processing decision and should follow the production workflow.
Should timecode punctuation be localized?
Not casually. Separators can be part of a technical convention and should remain consistent with the source workflow.
What is the simplest rule?
Protect the exact rate, scan type and timecode mode, then verify the translated instructions against the actual media and timeline.
Final checklist
- Is the exact frame-rate value preserved?
- Is capture rate distinguished from playback and delivery rate?
- Are progressive and interlaced scan labels intact?
- Are frames and fields kept distinct?
- Is variable versus constant frame rate preserved?
- Is drop-frame/non-drop-frame timecode identified correctly?
- Are timecode strings and separators unchanged where required?
- Are source, sequence and program timecode references separated?
- Were frame-rate conversions described rather than silently performed?
- Would the translated instruction still point to the same audiovisual moment and delivery profile?
Video frame-rate translation succeeds when the target reader sees the same timing system, the same scan method and the same frame references as the source reader. Protect fractional rates, distinguish frames from fields and capture from playback, preserve timecode mode, and verify every technical instruction against media metadata and the actual project timeline.