Subtitle timing slightly off

[DonMartione]

First off, I'm new to messing around with subtitles. I've been looking around and trying to read as many guides, manuals, and forum posts that I can, so I apologize if this is a stupid question.

Anyway, I have a few DVDs that I'm trying to edit the subtitles on. Basically I'm just making some minor edits to the subtitles. I see there is no easy way to do this, and that I have to go through the whole process as if I were adding subs to a movie.

The problem is, when I rip the subtitles through subrip and then compare them with the .sup file in SubtitleCreator, the timing is slightly off. It appears to be a very slight difference, but I don't understand why the timings wouldn't stay exactly the same. I haven't edited the .srt file at all yet.

Here's an example of the difference in timings.
Sub -------------SUP-file -------------------------Srt-file------------
0001 - 00:01:40,867-00:01:42,067 - 00:01:41,101-00:01:42,329
0002 - 00:02:13,634-00:02:14,701 - 00:02:13,867-00:02:14,959

In the end, both files have 290 subtitles, but the srt file runs a second longer than the original .sup file. I'm not sure if there is an easy way to synch the timings up to the original, or if this slight deviation is normal. I'd really just trying to avoid having to compare both the original and then the new subs to see that they both time up nicely with the video.

I appreciate any help that any of you can provide, thanks!

[CoNS]

Basically I'm just making some minor edits to the subtitles. I see there is no easy way to do this, and that I have to go through the whole process as if I were adding subs to a movie.It depends on what kind of minor changes you want to do.

With DVDSubEdit you can edit the subtitles directly inside the VOB files of a DVD.

Also, with SubtitleCreator's Manipulate SUP tool (in the Tools menu), you can make some changes to the SUP file without converting your DVD subtitles to text (.srt) first.

[DonMartione]

I'm making changes to the actual script. Correcting translation errors and such. The methods you mentioned only let me change the size, position, and color of the subtitles. However I wasn't able to edit the actual text in the subtitles.

[CoNS]

With DVDSubEdit you can delete text (parts of or whole subpics), but I agree that with the type of editing you have in mind you'll have to convert to text subtitles...

About the sync problem, you could try and use DVDSubEdit to convert to text (save as .srt) to see if it makes any difference. Also, instead of loading the SUP in SubtitleCreator to check the timecodes, you could load it in DVDSubEdit to see if it's the same result.

[Mtz]

I think that differences are because of audio delay. As CoNS told you, you can adjust the srt or sup file using SubtitleCreator. But the question is: which timming is OK if you want to reauthor the DVD? The srt or the sup? ;)

enjoy,
Mtz

[DonMartione]

Perhaps I just don't get how these subs work. I'm trying to keep the timing the exact way it it on the dvd originally. All I want to do is make a few edits. Nothing that requires adjusting the timming. I want to keep the dvd exactly the same as before, but with just an improved subtitle.

I'd prefer to just edit the sup, but I can't figure out how to do so. It seems if I want to actually edit/add text, that I must do so with the .srt file. Is there no easy way to just synch the .srt up with the .sup?

[DonMartione]

I just don't get why there should be any timing differences between the .srt and .sup file. I just assumed that the .srt file was ripped from the .sup so you could edit and play around with it. I figured it ripped the subtitles and timings from the .sup file. Instead it's more like it approximates them. Is there no simple method to correct the timings, or do I have to go through 300 lines and enter in correct times.


EDIT - CoNS, I tried DVDSubEdit and no luck. It doesn't show the timings in a manner that is easy to compare. In addition when I rip the subs using it, it ends up skipping several lines of text.

[CoNS]

I just don't get why there should be any timing differences between the .srt and .sup file. I just assumed that the .srt file was ripped from the .sup so you could edit and play around with it. I figured it ripped the subtitles and timings from the .sup file. Instead it's more like it approximates them.The time codes should be the same. Very strange. Could you save the subpic stream as a .sup file in DVDSubEdit and upload it, along with the .srt file from SubRip?

Is there no simple method to correct the timings, or do I have to go through 300 lines and enter in correct times.If all 300 lines need to be corrected with the same delay (+/-), it's quite easy to do so, for example in SubtitleWorkshop or SubtitleCreator. Otherwise the time codes can be synchronized with another subtitle file (.srt or .sup) using the tools in the Synchronize menu in SubtitleCreator.

I tried DVDSubEdit and no luck. It doesn't show the timings in a manner that is easy to compare. In addition when I rip the subs using it, it ends up skipping several lines of text.Yes, the OCR function in DVDSubEdit is not perfect. However, you can use it to make a new .srt file to compare the time codes with the .srt file from SubRip.

[DonMartione]

As a test, I've been using an anime dvd to try to figure out how to edit the subs. The dvds that I actually want to edit aren't out yet, but they will be shortly and I know the subs are goofy on them.

Here you go though, I attached the .sup and .srt file. The timing doesn't seem off by a lot, they're only milliseconds off. But like I said, I don't understand why they would be off even the sligthest. And I don't want to have to watch both the original and new subbed dvds to make sure things are as they should be. That could be very time consuming, especially over the long run.

[setarip_old]

Hi!The dvds that I actually want to edit aren't out yet, but they will be shortly and I know the subs are goofy on them.

You've piqued my curiosity - How can yo know that the subs "are goofy on them", if the DVDs haven't yet been released? - Or am I misinterpreting what you've said

[DonMartione]

I'm very familiar with the company releasing the dvds, Viz, and their work. I have several anime series on dvd by them, and their subtitle work isn't very good, at least to my standards. It's more of an assumption, almost a guarantee that the subs will not be to my liking.

Therefore, I'm trying to get some practice in with editing the subtitles so that when the dvds come out I'll be ready to "fix" them.

Also I'm hoping to fix the Battle Royale dvd that I recently bought. The subtitles are not only inaccurate, but their are several grammatical errors that make viewing less than enjoyable.

[DonMartione]

http://www.dmartin.net/subs.rar

There is a direct link for the .sup and .srt files.

EDIT - I tried ripping the subs using DVDsubEdit and it's OCR. The timing is still off. It's exactly the same as the .srt that I ripped using subrip.

[Mtz]

What timming is better for you? The timming from SUP or from SRT? Did you tried to remux the streams with the SRT and the SUP to see which fit the best for you?
In both cases if the delay is constant there is no problem: you can adjust the SUP or SRT as your needs.
You can find here (http://rapidshare.de/files/18691764/subs_new_timming.zip.html) your files with delay solved.
Btw: when you used SubRip you forget to "Post OCR corrections". Try to use Ctrl+i in Subtitles Workshop before adding a subtitle to a DVD.

enjoy,
Mtz

[mpucoder]

What version of SubRip? 1.17.1 and earlier never accounted for the video delay (not audio delay), and I'm not sure that it's been fixed yet.

[CoNS]

mpucoder, that could very well be it. However, he's getting the same .srt time codes with DVDSubEdit so the problem must be in this app, too, if that's the problem.

DonMartione, could you try ripping your subtitles with the latest beta version of SubRip instead (SubRip can't read SUP files so I can't test it for you with your uploaded subs)

[DonMartione]

I've been using subrip v1.50 beta 3 the entire time.

Mtz, I don't understand what you mean. I was under the assumption that the timing on the .sup file is the correct timing. Or should I say, the same exact timing that is used on the dvd. That's why I'm trying to get the .srt to match the .sup timing.

That's the problem I have. I can't figure out how to get the .srt timing to match the .sup. I haven't even edited the srt yet, so all the subtitles are exactly the same as the original. So shouldn't the timing be exactly the same as well?

[CoNS]

Hmmm, I've tried running the SUP file you provided through DVDSubEdit's OCR function and saving it as .srt. And this way I get different time codes again!!

So the time codes you got from SubRip seem to be different from both the time codes for the subpics inside the SUP file (when I load the SUP in SubtitleCreator's Manipulate SUP tool), and the time codes saved by DVDSubEdit!!!

The time code difference seems to vary from subpic to subpic, which is even more strange. Kinda looks like a framerate issue, but both .srt and SUP files are based on time codes, not frame numbers, right?

At this point I don't know if it's SubtitleCreator that displays the time codes from the SUP file incorrectly, or if SubRip (and DVDSubEdit?) somehow uses the wrong time codes, maybe because of a video delay as suggested by mpucoder. Or something completely different.

I think we need some of the "heavy guys" (mpucoder, jeanl, ai4spam etc.) to solve this mystery! Maybe by looking into the provided SUP file to see how the real time codes match the time codes in the .srt files outputted by SubRip (provided by DonMartinone) or by DVDSubEdit.

[mpucoder]

I just tried DVDSubEdit beta 0.90 (the latest that will run on my system without a runtime library problem - but I'm using an old system for testing) on a known (created by MuxMan) vob. The timing shown in the window is the unadjusted pts value. For the first sub it shows 3343572 (37.15s), which translates to 0:37:04.5 (the fact that 0.15 seconds is not a frame boundary, or that 3343572 is not divisible by 3003 should tell you there is a problem). This sub is actually at 0:36:25, which is 3343572 - 25257 (the video delay) = 3318315. 3318315 / 3003 = 1105 frames, or 0:36:25
The pts value recorded in a sup file created by VobEdit (and hopefully all newer apps) IS adjusted by the video delay, and should be divisible by the frame duration (NTSC 3003, PAL 3600)

btw, MuxMan can adjust .sst file produced by SubRip, but you need to obtain the video delay manually. That can be done with VobEdit - look at the start ptm of the very first Nav.

[mpucoder]

OK, I just tried DVDSubEdit 1.322 on a modern machine and got the same numbers.

@jeanl - pts values are relative to the video pts, ie if the first frame of video shows at 25257 (as most muxes do) then 25257 must be subtracted from any audio/sub/hli pts before converting to frame number/timecode.
Also, an NTSC second is 90090 ticks, so in the above example the time should be 37.11 seconds - but, of course, it should be adjusted first to 3318315, which then yields 36.83 seconds.
I notice that the sup file made by DVDSubEdit is correctly adjusted.

[CoNS]

Thanks very much for looking into the problem, mpucoder.

So for the not-so-techie-kinda-guys like me, would it be correct to conclude that DVDSubEdit is able to extract a SUP file correctly from the VOB files, with the correct time codes? Like VobEdit. (Probably SUP files extracted with PgcDemux and DVD Decrypter are saved with the correct time codes, too? I wonder if it's the same with SUP files saved in SubRip?)

However, I understand from your posts that both SubRip and DVDSubEdit have problems calculating the right time codes for the .srt files? (since they reach different time codes for the same subtitle stream, they must calculate it in different ways, both faulty?)

Can you confirm that the time codes from the SUP file is correctly displayed in SubtitleCreator, when the SUP file is loaded in the Manipulate SUP tool?

[ai4spam]

Well, this is the kind of problem I usually ask Zuggy to look into ;). Neither he nor I had any time recently, but plans are to move SubRip to SourceForge and make it work with various OCR engines, besides the default one.
Anyway, back to your problem... I may try to look into it sometime, and fix the timecodes, but I can't tell when that will be. In the meantime, I was going suggest another path (currently broken in this case, due to weird colors): DVDSupDecode, then SubRip on the image sequence.

[DonMartione]

Will the difference in timing even make a difference though? It seems like the offset is never more than 200ms, so I'm curious if it's even worth going through and fixing.

I'm going to try editing the subtitles using a different dvd as well. Hopefully it's just this particular dvd being a pain. Thanks for the help though.

[Mtz]

How I adjusted the Srt file according to the sup file:
- opened the Sup file in SubtitlesCreator and noted the first and last timmings from the first and last subtitles lines.
- opened the Srt file in Subtitles Workshop and pressing Ctrl+B. In the new opened window I pasted the noted values from SubtitlesCreator.

enjoy,
Mtz

[johner23]

plans are to move SubRip to SourceForge and make it work with various OCR engines, besides the default one.

@ai4spam, do you know if there are any similar program like SubRip in payware environment? I never saw anyone... It'll be interesting to see any OCR professional system adapted for reading dvd streams. ;)

Anyway, SubRip is already nice program. And getting in SorceForge maybe help more about improvements. :)

PS: do you choose any other OCR systems, just for testing?

Thanks and great work !!

[ai4spam]

@johner23: I heard there was some Asian (Chinese) clone, but never looked into it. The other OCR engines include a variant of the current one that allows scale differences, support for gOCR (now that JeanL is improving it) and a neural network OCR engine (which will have to be trained).

[jeanl]

OK, I just tried DVDSubEdit 1.322 on a modern machine and got the same numbers.

@jeanl - pts values are relative to the video pts, ie if the first frame of video shows at 25257 (as most muxes do) then 25257 must be subtracted from any audio/sub/hli pts before converting to frame number/timecode.
Also, an NTSC second is 90090 ticks, so in the above example the time should be 37.11 seconds - but, of course, it should be adjusted first to 3318315, which then yields 36.83 seconds.
I notice that the sup file made by DVDSubEdit is correctly adjusted.
mpucoder, thanks for looking into it. I didn't know that PTS values were actually relative to the video PTS (but that makes sense). Also, thanks for pointing out my mistake with the 90kHz clock (now, that's really confusing, NTSC PTS clock is 90.090 kHz, but PAL PTS clock is 90.000kHz if I understand you correctly!). What a mess!!!
Thanks though, I'll fix that in DVDSubEdit asap...
Jeanl

[mpucoder]

Not really, the clock is still 90KHz. But most timecodes (and that should be all timecodes when editing) are non-drop. 1 second is 30 frames, but 30 frames is 90090 ticks (each is 3003).

[jeanl]

OK I see, the mess comes from the fact that timecodes are non-drop, I did realize that 90090Hz was 30fps in NTCS.
Thanks!
Jeanl

[CoNS]

The other OCR engines include a variant of the current one that allows scale differences, support for gOCR (now that JeanL is improving it) and a neural network OCR engine (which will have to be trained).:eek: coooool!! *drooling* !!

EDIT:

@mpucoder, jeanl and ai4spam: Any of you techie guys who would explain to me in layman's words what's wrong where and why!?! (with the time code differences that is!)

[jeanl]

I can only explain for DVDSubEdit. When DVDSubEdit saves to .sup, it does subtract the PTS for the first video frame from the PTS of the each subtitle, which happens to be the right thing to do. When saving to a srt, DVDSubEdit was not doing that (saving the PTS of the subtitle without any adjustment) and that was wrong. As mpucoder explained to us (and that was news to me), the audio, highlights and subs PTSs are all relative to the video, not absolute (as I thought they were)...
Not sure whether this clarifies or not! :)

jeanl

[CoNS]

It does, thanks jeanl.

So, if the time codes in the .srt file saved with SubRip is different from the SUP time codes, it's probably a bug in SubRip (not subtracting the PTS for the first video frame from the PTS of each subtitle), right?

Weird, though, that the time codes in the SubRip and DVDSubEdit .srt files were not the same!!

[CoNS]

I've just checked the Manipulate SUP tool in SubtitleCreator, and it seems to have a bug, too, with the time codes display.

SubtitleCreator doesn't show the right time codes inside the SUP file. It seems that SubtitleCreator calculates the time codes in the SUP file the same exact same faulty way as DVDSubEdit has been calculating the time codes for the .srt file up until now, as it outputs identical time codes.

So, in the end it turned out that all three programs have bugs in their subtitle time code calculation! SubtitleCreator has a bug when displaying time codes for loaded SUP files. SubRip has a bug when calculating the time codes for .srt files (and maybe also when saving the subtitles to a .SUP file?). And DVDSubEdit has a bug when calculating the time codes for .srt files.

(Jeanl is going to release a new version of DVDSubEdit shortly, where the time code bug in saved .srt files is fixed, and where the subpic time codes are displayed in 00:0x:xx,xxx --> 00:0y:yy,yyy format, too)

[DonMartione]

How I adjusted the Srt file according to the sup file:
- opened the Sup file in SubtitlesCreator and noted the first and last timmings from the first and last subtitles lines.
- opened the Srt file in Subtitles Workshop and pressing Ctrl+B. In the new opened window I pasted the noted values from SubtitlesCreator.

enjoy,
Mtz

Thanks, but I tried that and it didn't work. It adjusted the subtitles, but they're still off by a few hundred milliseconds. So it's not really different from the .srt.

I guess I should just wait until some of the programs are updated? I don't really understand all that you guys were talking about, but it seems there is some error in calculating the timings. I guess the dvd I've been testing on isn't normal and is pain in the ass. Otherwise such errors would have been found a while ago.

[DonMartione]

Ugh I just tried another dvd and I get the same problem. My DVDs are cursed or I just have bad luck.:(

[ai4spam]

@mpucoder: The SubRip TimeStamp mechanism is hour:minute:second:frame or hour:minute:second:millisecond

The code below is attributed to you, and does the conversion from PTS to TimeStamp.


//PTS = Presentation Time Stamp (Compteur basé sur une horloge à 90KHz qui gere le moment precis auquel on doit afficher un élément)
function PTSToTCMs: TTimeCodeMs;
var
L1, LMSec: Int64;
begin
L1 := //mpucoder's def (it's strange but it is equal to previous)
(PackBuf[27] and $FE) shr 1 +
PackBuf[26] shl 7 +
(PackBuf[25] and $FE) shl 14 +
PackBuf[24] shl 22 +
(PackBuf[23] and $0E) shl 29;

LMSec := TimerToMs(L1);
Result := MSecToTCMs(LMSec);


Does that look right? PackBuf contains chunks of 2048 bytes that start with BLOCK_START_CODE = $000001BA.
And... would you always subtract 25257, or...? Sorry if this sounds trivial to you, it's the first time I look into that part of the code.

@others: DVDSupDecode outputs a frame-based list, which upon conversion to .srt yields timestamps that are on frame boundaries. I've improved the SubRip support for image sequences to deal with various color schemes, it will be up in the next version.

[mpucoder]

I guess the dvd I've been testing on isn't normal and is pain in the ass. Otherwise such errors would have been found a while ago.
Your DVD is typical, the error was discovered a LONG time ago, but most people have just been adjusting the time by subtracting 7 frames (PAL). The usual delay is 25257 ticks, divided by 3600 (the duration of a PAL frame) yields 7.01
For NTSC it is 25257/3003 = 8.41
This works on the majority of DVDs since most use the same algorithm and delay. However the better DVDs, especially those with seamless branching, use a different muxer with a variable delay.
It's best that we get the programs fixed. Use .sup files made by programs such as VobEdit, PgcDemux and DVDSubEdit, the timing is correct.

[jeanl]

Guys, here's a quick update of DVDSubEdit:
http://www.videohelp.com/~DVDSubEdit/Downloads/DVDSubEdit1.323.zip
It fixes the timing error in the .srt output and also shows the timing in the SUP info panel in a more legible way...
Enjoy...
Jeanl

[mpucoder]

@ai4spam - that looks like the Delphi/Pascal version of extracting the pts value of any pes.
The delay (see above) is not always 25257. It can be determined for the first vob by looking at either vobu_s_ptm (offset 0x039) of the first NavPk, or vob_v_s_ptm (offset 0x433) of any NavPk in the vob. But when there is a clock discontinuity the delay must be recalculated. And since the clock has been reset and the duration of the previous vob must be accounted for, one value can be used for both.
This value gets ADDED to the pts, so the initial value is the negative delay. At a new vobid adjust the value by adding the old vob_v_e_ptm (this accounts for the duration of the previous vob) and subtract the new vob_v_s_ptm.
(edited to simplify the math)

[ai4spam]

@mpucoder: Thanks for the reply. Unfortunately, things like http://dvd.sourceforge.net/dvdinfo/dsi_pkt.html are not very helpful for someone with little time (like me) to determine what exactly needs to be done. Any place where this is already coded (C code works as well, I'll do the translation if needed)?

[CoNS]

DVDSubEdit is coded in C++. Maybe jeanl can help with a code snippet in C++ for calculating the PTS value?

[Sir Didymus]

...
most people have just been adjusting the time by subtracting 7 frames (PAL). The usual delay is 25257 ticks, divided by 3600 (the duration of a PAL frame) yields 7.01
...It's best that we get the programs fixed. Use .sup files made by programs such as VobEdit, PgcDemux and DVDSubEdit, the timing is correct.

Haaa. Finally understood the reason for this 7 frames "mistery"...

http://forum.doom9.org/showthread.php?t=106347

However, also the twin vsrip+vsconv (adopded for ripping subpictures by many applications, including NuMenu4u...) suffer from some glitches in the timings...

[jeanl]

Guys, I posted a quick update of DVDSubEdit to fix the discontinuous PTS problem.
http://www.videohelp.com/~DVDSubEdit/Downloads/DVDSubEdit1.324.zip
Jeanl

[ai4spam]

Umm.... how 'bout the source...?

[jeanl]

Well, I usually post the source for normal updates. But I can post it, tomorrow...
Jeanl

[ai4spam]

A code snippet here/an email with the source to my address would also work. Thanks.

[jeanl]

ai4spam,
I think this is what you're looking for...

// In first VOBU, set PTSAdjustment.
PTSAdjustment = -GetInt(m_Buffer,0x39);
.......
// Checking for discontinous PTS... If discontinuous, update adjustment.
m_EndPTS = GetInt(m_Buffer,0x3d);
ThisStartPTS = GetInt(m_Buffer,0x39);
if(m_EndPTS > ThisStartPTS)
{
PTSAdjustment += m_EndPTS - ThisStartPTS;
}

m_EndPTS is the end PTS of the previous vobu extracted from navpack at offset 0x3d. ThisStartPTS is the start PTS of the current vobu, extracted from the navpack at offset 0x39...
GetInt() is a function I use to take care of the endian problem.
Then the subs PTS is simply adjusted by adding PTSAdjustment to it.

Is that what you were looking for?
Jeanl

[Paddington]

How I adjusted the Srt file according to the sup file:
- opened the Sup file in SubtitlesCreator and noted the first and last timmings from the first and last subtitles lines.
- opened the Srt file in Subtitles Workshop and pressing Ctrl+B. In the new opened window I pasted the noted values from SubtitlesCreator.

enjoy,
Mtz
You can do both of this in SubtitleCreator: you go to the Synchronize menu, open the SUP, and by default it will show you every 5th subtitle in the left window, and your text subtitle in the right window. You can now select matching subtitles left and right, press add link, and after you have done this near the beginning and end of the subtitle file (if you have more text file, do this for each subtitle file near the end and beginning), you can synchronize them. This way, the SUP times are copied to their linked text counterparts, and everything in between is linearly adjusted.

[CoNS]

Paddington, as reported in this (http://forum.doom9.org/showthread.php?p=819149#post819149) previous post it seems to me that SubtitleCreator has a bug, too, when extracting/displaying the time codes in SUP files.

When I demux a SUP file using PgcDemux (or create a new SUP file using SubtitleCreator) and load this SUP file into SubtitleCreator's Manipulate SUP tool, the time codes shown here are (slightly) different than the time codes I get when I load the same SUP in DVDSubEdit.

(Notice that the latest version 1.324 of DVDSubEdit shows the time codes in 00:00:0x,xxx --> 00:00:0y,yyy format in the Subpic Info area, which makes the time codes easy to compare. Also, the PTS calculations in this version should be 100% tested and confirmed).

[Paddington]

@mpucoder or jeanl
OK, now I am getting a bit lost, so hopefully you can help me out:

SubtitleCreator reads and writes SUP files - since I don't use VOB's I shouldn't need to worry about the video delay.

Next, there are two time codes important for me: PTS, the start offset (normally 0), and the end offset (when the subtitle stops displaying).

Currently I do the following (for PAL movies):
I divide the PTS value by 90000 to get the number of seconds.
And the end offset by 900 to get the duration.

fs.Read(b,0,2); // At the beginning of a control sequence
int Offset = ((int) b[0]<<8 | (int) b[1]);= ((int) b[0]<<8 | (int) b[1]);

According to DvdSubEdit, however, the PTS is divided by 90090, e.g.:
PTS = 2044800
Duration = 3.606s
TimeCode: 00:00:22,697 --> 00:00:26,303

As I don't seem to be doing the correct thing, what should I do to convert the PTS to time (for PAL and for NTSC), and the same with the offset... any help would be very much appreciated!

[mpucoder]

Using 90090 for NTSC is to convert to non-drop timecode, which is the recommended timecode for authoring. Dividing by 90000 will give you the drop-frame time.

I know you guys like to use milliseconds instead of frames, but subpicture pts values are always frame aligned. It is simpler to divide the adjusted pts (the one found in a sup) by the frame duration (3600 for PAL, 3003 for NTSC) to get the starting frame number. From there you get hh:mm:ss:ff, or, if you wish, hh:mm:ss.mmm

The duration times of spu's also should be first rounded up and then adjusted to a frame point or you may accumulate arithmetic errors and drop a frame in the next authoring. Use the last DCSQ_STM (the delay value) in this formula:
duration_in_frames = ((DCSQ_STM * 1024) + 1023) / frame_duration
That is an integer divide - discard the remainder.
From there you can compute the end time by adding duration_in_frames to the start (in frames).

Why round up? Because this is the formula used to derive STM values:
DCSQ_STM = (frames * frame_duration) >> 10
So this value is almost always less than the intended delay when multiplied again by 1024 (or shifted left 10)