Fix 29.97 fps Subtitles to 23.976 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 29.97 frames a second and puts it on a 23.976 timeline. Every timestamp is multiplied by 1.25 — five fourths, exactly — so the file comes out a quarter longer: a cue at forty-eight seconds becomes one at a minute, and a cue that says twenty-four minutes in an episode running thirty comes back to thirty. The two boxes are already filled in; change them if your file was counted at something else.
The mistake is the same arithmetic as its mirror image, seen from the other end. Frame numbers divided by 29.97 when they belonged to a 23.976 timeline come out a quarter too small, because 23.976 divided by 29.97 is 0.8 — so the whole timeline is squeezed to four fifths of its length and every subtitle appears 20 percent early, further and further ahead as the film goes on. Multiplying by 1.25 is that error divided back out.
Recognising which way round you are is the whole job, and the symptom says it. Subtitles that run late, growing later, with a twenty-four minute episode whose last cue claims thirty minutes, need 0.8. Subtitles that appear early, growing earlier, with a twenty-four minute episode whose last cue claims twenty-four when the episode is thirty minutes long, need this page. Both files were built from the same mis-divided frame numbers; only the direction of the mistake differs.
1.25 is exact, for the same reason its mirror is: 29.97 is 30000/1001 and 23.976 is 24000/1001, so the shared division by 1001 cancels and 29.97 over 23.976 is simply 30000 over 24000 — five fourths, with nothing rounded and nothing left over. Each cue is given a quarter more time on screen, so the reading speed of every line falls by 20 percent, which is the one direction in this group that eases the pressure rather than adding to it. 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
The quarter, in full
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:01,250 --> 00:00:03,750
Hello there.
2
00:01:15,000 --> 00:01:17,500
One minute in.
1.25 is 29.97 divided by 23.976. The cue at one second gains 250 ms and the cue at a minute gains 15,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 2.5 seconds, and that extra room is where the reading speed improvement comes from.
Early by a quarter of the elapsed time
Input
1
00:08:00,000 --> 00:08:02,000
Eight minutes in.
2
00:24:00,000 --> 00:24:02,000
Twenty-four minutes in.
Output
1
00:10:00,000 --> 00:10:02,500
Eight minutes in.
2
00:30:00,000 --> 00:30:02,500
Twenty-four minutes in.
Two minutes early at the eight-minute mark, six minutes early at the twenty-four-minute mark — a quarter of the elapsed time in both cases, which is what a ratio problem looks like rather than an offset. The last cue is the one to check after converting: open the file at its new timestamp and the line should be there, and if it is, everything before it is right too.
Frames stay put, the declaration moves
Input
{1}{1}29.97
{300}{360}Hello
Output
{1}{1}23.976
{300}{360}Hello
MicroDVD counts in frames, and nothing was wrong with the frames — the rate they were divided by was. Frame 300 declared at 29.97 reads as ten seconds, which is the earliness being complained about; declared at 23.976 it reads as twelve and a half, which is where that cue belongs. So the first line is edited and no frame number is touched: rewriting them would apply the extra quarter twice.
Frequently asked questions
Why is the factor for 29.97 to 23.976 exactly 1.25?
Because both rates are a round number divided by 1001 — 29.97 is 30000/1001 and 23.976 is 24000/1001 — so dividing one by the other cancels the 1001 and leaves 30000 over 24000, which is five fourths. Nothing is rounded and nothing is approximated, which is why the cue at forty-eight seconds lands at exactly one minute.
My subtitles appear too early and get earlier — is this the pair?
Check whether the earliness is a quarter of the elapsed time. Two minutes early at the eight-minute mark, six minutes at the twenty-four-minute mark, and twenty-four minutes early in a two-hour film is this pair exactly. The mirror page handles the opposite symptom: subtitles that run late and get later need 0.8 instead of 1.25.
Can I use this pair to go from an NTSC video straight to PAL?
No, and going through this page is the long way round on purpose. 29.97 to 25 is 1.19880 and there is no page for it, because 29.97 is the rate the signal runs at rather than a speed the pictures are played at — film inside it is padded out with repeated frames that leave the running time alone. The honest path from an NTSC timeline to a PAL one is back to the film rate first, which is this conversion, and then 23.976 to 25.
The video is 29.97 and the subtitles look right — will this page ruin them?
It will, and this is the mirror of the trap on the other page. A film carried in an NTSC signal has pulldown applied, which repeats frames without changing the running time, so a file timed against that video is already correct. Only a file whose frame numbers were divided by the wrong rate needs converting; multiplying a correct file by 1.25 makes every subtitle a quarter of the way late.
What happens to cue lengths and reading speed when the timeline grows by a quarter?
Every cue gains 25 percent of its duration as well as moving later, so a two-second line is given 2.5 seconds while the words stay exactly as they were. That lowers the reading speed of each line by 20 percent, which makes this one of the two pairs in the group that relieve pressure on a file rather than adding to it — the other being the 50 to 25 halving.
What kind of workflow leaves a file early rather than late?
One that treated the container's rate as the rate of the pictures. NTSC carries 29.97, so a tool that reads that number off the video and divides frame numbers by it will under-time any film inside the signal, because the film itself is running at 23.976 and the pulldown was only padding. The cure is to declare the rate the pictures actually run at, which is what this page does: 29.97 first, 23.976 second.