Convert Drop-Frame Timecode to Non-Drop-Frame
Or paste subtitle text
Options
30 fps non-drop and 29.97 drop-frame write the same clock differently, and this box picks which way the file is read and which way it is written back. A cue one hour in reads 01:00:00,000 under one and 01:00:03,600 under the other — the two are 3.6 seconds apart per hour, not a rounding error. The page's title names one direction, and this box offers only that one, so the file you get is the file the page is about. Nothing about the text changes: no cue is retimed against the video, no frame rate is converted, and a cue inside the first minute of an hour comes back exactly as it went in, because no frame label is dropped there.
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.
This page re-labels every timecode in a subtitle file from 29.97 fps drop-frame back to 30 fps non-drop-frame, so each clock counts down by a fixed amount that grows with the programme: nothing inside the first minute of an hour, 3.6 seconds an hour in, 36 seconds after ten hours. The words, the cue numbers, the order of the cues and the line breaks are the file's own and come out untouched.
The file this page is for was stamped against a display or a deck that was counting in drop-frame — which is the usual thing on 29.97 material, because drop-frame is the convention that stays with the wall clock — and everything downstream of it reads clocks as non-drop. Read that way, every timecode in the file is too large by an amount that keeps growing, so the subtitles land early, and later and later as the programme runs. Half an hour in the error is 1.8 seconds, and it does not stop growing anywhere in the file. That is why the fix is not a nudge: it is the same re-labelling applied at every timestamp, with the size of the correction set by where the cue sits.
Reading a clock as a timecode means snapping it to the nearest 30 fps frame tick, and in drop-frame two of those ticks do not exist. Drop-frame skips the labels ;00 and ;01 at the start of every minute except every tenth minute — it counts 00:00:59;28, 00:00:59;29 and then jumps to 00:01:00;02 — so an incoming 00:01:00,000 names an instant that convention has no way to write. It is pulled back to the last label it can write, 00:00:59,933, 67 milliseconds earlier. That is a real boundary of the arithmetic, not a tolerance, and it is stated on the page rather than smoothed over: over two hours there are 216 of them.
A cue that ends up shorter than one frame after the snap cannot be written at all, because its two edges land on the same tick and a cue whose end equals its start is not a cue. Those are dropped and counted in the loss report above rather than silently stretched to a frame. In practice this only reaches material cut frame by frame, but the page does not rely on that being rare — it reports the count, and a file with no such cue reports nothing.
Nothing is uploaded. The file is read and re-written inside the browser tab and never leaves the machine, which matters for the same reason it matters on every other page here: material under a confidentiality obligation cannot be handed to a conversion service, and this one does not ask for it.
Examples
A file five minutes in
Input
1
00:05:00,000 --> 00:05:02,000
The room is dark.
2
00:10:00,000 --> 00:10:03,000
A cold night.
Output
1
00:04:59,667 --> 00:05:01,667
The room is dark.
2
00:09:59,400 --> 00:10:02,400
A cold night.
The correction is not one number applied to the file: five minutes in the clock moves back 333 ms and ten minutes in it moves back 600 ms, because drop-frame has thrown away ten labels by the first cue and eighteen by the second. Each cue keeps its length to the millisecond, since both of its edges move by the same amount — this is a re-labelling, not a shift.
The same correction at one hour
Input
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Output
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
An hour in, drop-frame's 01:00:03,600 is what non-drop calls 01:00:00,000 — 108 skipped labels, 3600 ms. This is the number to check the page against: the first line of the output should be exactly 3600 ms earlier than the first line of the input, and a file that came off a drop-frame deck should land on the round hour.
A cue inside the first minute
Input
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:05:00,000 --> 00:05:02,000
This one does move.
Output
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:04:59,667 --> 00:05:01,667
This one does move.
During the first minute of an hour no label is dropped, so the two conventions spell those sixty seconds identically and the first cue is left alone. The second cue, at five minutes, moves. One cue unchanged beside one cue moved is the correct output for this file and not a stalled run — the correction is zero at the top of an hour and grows from the first minute boundary onward.
Frequently asked questions
Why do the subtitles come out earlier instead of later?
Because the file's clocks were larger than the instants they name. Non-drop-frame counts 30 labels a second as if 29.97 fps delivered 30 frames a second, so it slowly runs ahead of real time; drop-frame skips two labels a minute to stay with it. A clock read off a drop-frame deck and then interpreted as non-drop therefore points past where it should, and the fix subtracts that excess: 333 ms at five minutes, 3600 ms at an hour, 36000 ms at ten hours. The amount is zero for every clock inside the first minute of an hour, so the smallest correction the page ever applies is the one at the first minute boundary, and no clock is pushed below 00:00:00.
What happens to a drop-frame timecode that cannot be written?
It is pulled back to the last label that can be. Every dropping minute in drop-frame lacks its ;00 and ;01 labels, so 00:01:00,000 and 00:01:00,010 are not clocks that convention can display: they land on 00:00:59,933, 67 milliseconds earlier. This is the one place on this page where the output is not an exact re-labelling, and it is bounded — two labels per dropping minute, 216 values over two hours — so the page names it here rather than leaving you to find it in the diff.
Can a cue disappear from my file?
Only a cue shorter than one frame, 33.37 ms. Two things can push a cue onto a single frame: the snap described above, where a ten-millisecond cue like 00:01:00,000 to 00:01:00,010 has both edges pulled to 00:00:59,933, and a cue that was already sub-frame when it arrived. A cue whose start and end are the same instant cannot be written out, so it is dropped and its count appears in the loss report above the workspace. A file with none reports nothing, which is the usual case.
Does anything besides the clock values change in the file?
No. Cue numbers, their order, the text of every line, the hard line breaks inside a cue and the total cue count are the file's own and stay as they were. The page writes the same two numbers per cue, re-labelled. It also does not record anywhere that the clocks are now non-drop, because none of the formats read here — SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON, CSV — has a field that could hold that, and the file you dropped in did not say it either.
What frame rate should I put in the box?
Any rate the footage actually has; it does not affect this conversion. 30 and 29.97 in this page's name are the counting conventions written on the timecode string, not the frame rate of the video, so nothing here is scaled by the number you enter. The box is required only because MicroDVD stores timings as frame numbers rather than as clocks, and reading a MicroDVD file is impossible without knowing its frame rate.
If I run the opposite page on this output, do I get the original file back?
Yes, byte for byte, as long as no timecode fell in the class drop-frame cannot write. The two pages are the same arithmetic read in opposite directions: this one subtracts a growing amount, the other adds it back, and the amounts are set by the position of each cue rather than by a fixed offset. The exception is the snapping case — 00:01:00,000 that came out as 00:00:59,933 returns as 00:00:59,933 — and it is the only class of timestamp for which the pair is not a round trip.