Answers.Body: <p>I think that you have misread the formula</p>
  <p>Let's say you want the subtitle to appear at 50.5 seconds. Current video rate is 25 frames per second.</p>
  <p>This will mean that the subtitle will appear at the frame number <code>50.5*25 = 1263</code> (rounding up).</p>
  <p>If you then convert the frame rate to 30 frames per second, your new start frame much change and will be <code>50.5*30 = 1515</code>.</p>
  <p>Perhaps you have gotten confused with this:</p>
  <pre><code>new_start_frame = new_frame_rate / old_frame_rate * old_frame
  </code></pre>
  <p>This is not <code>ts_1 x f_1 = ts_2 x f_2</code>, but rather <code>ts_1 x f_2 = ts_2 x f_1</code>.</p>
  <p>Let's check with the numbers i have calculated above:</p>
  <pre><code>ts_1 = 1263
  f_1 = 25
  ts_2 = 1515
  f_2 = 30
  
  1263 * 30 = 1515 * 25
  37890 = 37875
  </code></pre>
  <p>the error here was due to rounding.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2021-11-30T13:40:42.560Z
Answers.LastActivityDate: 2021-11-30T13:40:42.560Z
Answers.UserDisplayName: v010dya
Body: <p>I don't understand why the framerate of the video should affect timestamps in SubRip (*.srt) subtitles.  If I am correct, when you convert a video from one framerate to another, the length of the video remains the same—the only thing which changes is the total number of frames. But tools which change the subtitle framerate seem to follow an equation like </p>
  
  <pre><code>timestamp_1 x framerate_1 = timestamp_2 x framerate_2.
  </code></pre>
  
  <p>Which seems to imply that the frame numbers are equal.  For instance, <a href="http://www.dr-lex.be/software/srtlab.html#download" rel="nofollow">in the SRTLab documentation</a>, in order to convert from PAL (25.000 fps) to NTSC (23.976 fps), it says that each timestamp should be scaled by a factor of 25.000/23.976.  I don't understand this.  This would make the subtitles appear after the same number of frames in both videos, which is not what we're after. Obviously, I'm not getting something right.</p>
  
Tags: <framerate><subtitles>
Title: Framerate and timestamps in SubRip subtitles
UserDisplayName: Adarsh Kumar
ThreadText: # Framerate and timestamps in SubRip subtitles
  
  (Asked by: username_0 on 2014-10-31)
  
  I don't understand why the framerate of the video should affect timestamps in SubRip (\*.srt) subtitles. If I am correct, when you convert a video from one framerate to another, the length of the video remains the same—the only thing which changes is the total number of frames. But tools which change the subtitle framerate seem to follow an equation like
  
  ```
  timestamp_1 x framerate_1 = timestamp_2 x framerate_2.
  
  ```
  
  Which seems to imply that the frame numbers are equal. For instance, [in the SRTLab documentation](http://www.dr-lex.be/software/srtlab.html#download), in order to convert from PAL (25.000 fps) to NTSC (23.976 fps), it says that each timestamp should be scaled by a factor of 25.000/23.976. I don't understand this. This would make the subtitles appear after the same number of frames in both videos, which is not what we're after. Obviously, I'm not getting something right.
  
  **Tags:** framerate, subtitles
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2021-11-30. Score: 0
  
  I think that you have misread the formula
  
  Let's say you want the subtitle to appear at 50.5 seconds. Current video rate is 25 frames per second.
  
  This will mean that the subtitle will appear at the frame number `50.5*25 = 1263` (rounding up).
  
  If you then convert the frame rate to 30 frames per second, your new start frame much change and will be `50.5*30 = 1515`.
  
  Perhaps you have gotten confused with this:
  
  ```
  new_start_frame = new_frame_rate / old_frame_rate * old_frame
  
  ```
  
  This is not `ts_1 x f_1 = ts_2 x f_2`, but rather `ts_1 x f_2 = ts_2 x f_1`.
  
  Let's check with the numbers i have calculated above:
  
  ```
  ts_1 = 1263
  f_1 = 25
  ts_2 = 1515
  f_2 = 30
  
  1263 * 30 = 1515 * 25
  37890 = 37875
  
  ```
  
  the error here was due to rounding.
  
  
  ---
  
  