Fix 23.976 fps Subtitles to 29.97 fps
Or paste subtitle text
Options
Which frame rate the timings are counted in. On the format pages this is what MicroDVD needs, because it stores timing as frame numbers. On the frame rate pages it is the rate the file was timed against — the version the subtitles were made for — and the page's second box takes the rate of the video you are going to use them with. 23.976, 24, 25, 29.97, 30, 50, 59.94 and 60 are the common ones. Getting it wrong shifts the whole timeline, and on the frame rate pages it shifts it by a ratio rather than by a fixed amount.
The frame rate of the version you are going to use the subtitles with — the video you are actually going to play. The factor applied is the first box divided by this one, so 24 into 25 gives 0.96: a film runs 4% faster on PAL, and a 100-minute feature fits a 96-minute tape. Getting the two boxes the wrong way round shifts the whole timeline in the wrong direction by the same amount.
This page takes a subtitle file whose timeline was counted at 23.976 frames a second and puts it on a 29.97 timeline. Every timestamp is multiplied by 0.8 — four fifths, exactly — so the file comes out a fifth shorter: a cue at one minute becomes one at forty-eight seconds, and a twenty-four minute episode whose subtitles claim thirty minutes comes back to twenty-four. The two boxes are already filled in; change them if your file was counted at something else.
The mistake is in the arithmetic that turns frame numbers into seconds. If a tool read frame numbers belonging to a 29.97 timeline but divided them by 23.976, then every second it produced is a quarter too large: 29.97 divided by 23.976 is 1.25, so the whole timeline is stretched by a quarter and the subtitles run 25 percent late, further and further behind as the film goes on. Multiplying by 0.8 is the same error divided back out.
One thing this page must not be used for, and it is the easiest mistake in the group to make. A film carried inside an NTSC signal has 3:2 pulldown applied — the same pictures are repeated to fill the 29.97 signal — and pulldown leaves the running time exactly as it was. So "my video is 29.97 and it has pulldown" is not a reason to convert anything: a file timed against that video is already correct, and multiplying it by 0.8 would take a fifth off it. This page is for a file whose frame numbers were counted against the wrong rate, not for a file that merely sits in a 29.97 container.
What makes this pair pleasant to work with is that 0.8 is exact. Both rates in it belong to the NTSC family and both carry the same division by 1001, so the 1001 cancels and 23.976 over 29.97 is simply 24000 over 30000 — four fifths, with nothing rounded and nothing left over. Each cue is given a fifth less time on screen, which raises the reading speed of every line by 25 percent. Nothing is uploaded, and a whole season goes through the queue in one pass — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON and CSV files are read as what they actually are rather than as the extension suggests.
Examples
A short cue and a long one
Input
1
00:00:01,000 --> 00:00:03,000
Hello there.
2
00:01:00,000 --> 00:01:02,000
One minute in.
Output
1
00:00:00,800 --> 00:00:02,400
Hello there.
2
00:00:48,000 --> 00:00:49,600
One minute in.
0.8 is 23.976 divided by 29.97. The cue at one second loses 200 ms and the cue at a minute loses 12,000 ms — sixty times the distance from zero, sixty times the movement. Both edges of each cue are multiplied, so a two-second line is given 1.6 seconds, and that shortening is where the reading speed increase comes from.
The lateness grows with the clock
Input
1
00:10:00,000 --> 00:10:02,000
Ten minutes in.
2
00:30:00,000 --> 00:30:02,000
Half an hour in.
Output
1
00:08:00,000 --> 00:08:01,600
Ten minutes in.
2
00:24:00,000 --> 00:24:01,600
Half an hour in.
Two minutes late at the ten-minute mark and six minutes late at the half hour — a quarter of the elapsed time in both cases, which is what a ratio problem looks like. A fixed offset can never fix that, and a proportion can. The check after converting is at the end of the file: open it at the last cue's new timestamp and the line should be there.
A MicroDVD file changes only its declaration line
Input
{1}{1}23.976
{240}{288}Hello
Output
{1}{1}29.97
{240}{288}Hello
MicroDVD stores timing as frame numbers, and the frames are not what was wrong — the rate they were being divided by was. Frame 240 declared at 23.976 reads as ten seconds, which is the lateness being complained about; declared at 29.97 it reads as eight, which is where that cue belongs. So the file's first line is edited and not one frame number is touched: rewriting them would apply the 25 percent twice.
Frequently asked questions
Why is the factor for 23.976 to 29.97 exactly 0.8?
Because both rates are NTSC rates and both are a round number divided by 1001: 23.976 is 24000/1001 and 29.97 is 30000/1001. Dividing one by the other cancels the 1001 on both sides and leaves 24000 over 30000, which is four fifths. So nothing here is rounded and nothing is approximated — the cue at one minute lands at exactly forty-eight seconds.
Does this fix a film that has had 3:2 pulldown applied?
No, and that is the trap this page exists to name. Pulldown fills a 29.97 signal with repeated frames and leaves the running time exactly as it was, so a subtitle file timed against the pulled-down video is already right — converting it takes a fifth off the timeline and makes a correct file wrong. The page is for timings built by dividing frame numbers by 23.976 when the frames belonged to a 29.97 timeline.
My subtitles are a quarter of the way late and getting later — is this the pair?
Check whether the lateness is a quarter of the elapsed time. Two minutes late at the ten-minute mark, six at the half hour, and half an hour late in a two-hour film is this pair exactly. The cousins in this group are easy to tell apart by size: 0.95904 is a 4 percent error, 1.0427094 is 4.271 percent, and a factor of two doubles the file's length.
Can I put 24 and 30 in the boxes instead of 23.976 and 29.97?
For this pair, yes, and the result is identical — 24 divided by 30 is four fifths, the same as 23.976 over 29.97, because the shared division by 1001 cancels either way. That is a property of this pair and not of the group: on the film-to-PAL page, using 24 and 25 where the file was really 23.976 leaves an error of 3.5 seconds an hour.
Every cue is given a fifth less time — does that break the reading speed limits?
It is worth checking, because the words do not get shorter to compensate: a line that was comfortably inside a characters-per-second limit can be pushed over it by a 25 percent increase. The accessibility tools on this site measure reading speed against the thresholds the standards set, which is the number to look at rather than an impression that the subtitles now seem rushed.
Should I use this pair to put film subtitles on an NTSC DVD?
No. A film on an NTSC disc is stored at 23.976 and the player applies pulldown on playback, so a file timed against the film needs no change at all and 0.8 would ruin it. If your file was timed against a PAL copy of that film and you are going back to the disc, the pair is 25 to 23.976 and the factor is 1.0427094 — a small correction in the other direction.