Bug with subtitle track (SRT) exporting

Hi
I`ll have to deliver a feature film with subtitles, and have made some Resolve (16.2.3) differents projects / timelines but with exactly the same video file - (1920X1080 - 23,976p) intended to switch the same exported SRT file among the timelines. Windows 10 Pro + Davinci Resolve (free).

The sutbtitles track (SRT) generated from the Resolve exporting tool were progressively becoming OUT OF SYNC along the timeline(s). The timelines (and clips) have all the same speed: 23,976.

I just fresh reinstalled the program and I`ve also done some other tests, as long as my very little technical knowledge allows me to do.

Summarizing: when I import the SRT file to a new projects / timelines, but clones of the timeline that generated the SRT file, drag (or insert) it to the sync frame:

1) Some clips of the timeline are missing (randomly chosen by the bug), but it seems that the missing clips are always the same, and there are nothing in their place.

2) Regardless of the missing clips, video / audio / subtitles are progressively becoming OUT OF SYNC along the timeline(s).

3) Despite the SRT track missing clips, the SRT correspondent WORD file (subtitle text) shows NO missing clips, but as some of them shows a kind of disorder/disarray in relation to the standard organization of the other lines, they are not generated in the timeline as subtitle clips.
Note that all the timelines are 23,976p.

The bug has happened with the same free Resolve 16.2.3 installed in both desktop and notebook.

UPDATE:
1) As I have observed, the problematic subtitle track file generated by the Resolve export tool progressively anticipates to the original subtitling along the timeline.
2) A pal of mine tried to solve my project (big) problem in his Resolve Studio 16.2.3. The out of sync issue didn`t happen, but the missing clips did.

And by the way, the subtitle track style parameters are not kept when the subtitle track is exported!

Please someone help me, because I need urgently deliver this SRT file.
And please Black Magic Design people pay attention to this big issue with a very important tool.
Gerron

Having exactly the same problem here. Did you discovery something?

I have not experienced that specific problem, but a new one has showed up putting sync out by exactly 1 hour! I use studio version and JUST swithched to release 17. The default setting for Davinci is to start a timeline at 01:00:00:00. In the past, on export, the SRT file would start measuring from 00:00:00:00, which would then line up exactly with the exported video. But the most recent exports I have done from Resolve Studio 17 clearly measures from the timeline timecode setting. I could not figure out why my subtitles were not showing up, until they popped up exactly 1 hr out of sync.

Here are the first few entries exported from Resolve 15 (I removed the spaces here between entries):

1
00:00:00,000 --> 00:00:03,002
[HEAVY RAIN AND THUNDER]
2
00:00:14,055 --> 00:00:16,182
[THUNDER]
3
00:00:20,270 --> 00:00:22,397
[KEYBOARD AND TRACKBALL]
4
00:00:32,741 --> 00:00:34,868
[CROSSING BELLS AND TRAIN]
5
00:00:41,750 --> 00:00:42,542
[SCREAM]

Here are the SAME entries exported yesterday from Resolve 17 - SAME project (subtitles now bolded) and minor position change but note they are out of sync by an hour from the original, and are out of sync by an hour when the video is run with captions on VLAN or on my LG smart TV. The subtitle file is now carrying over the "start timecode" setting from the project (01:00:00,000). I don't know if this is a new "feature" in Resolve 17 or if I am missing some changed setting somewhere. While I can change the default start-timecode setting, I see no way to change it for an existing project, nor can I find anywhere that would explain why the SRT is suddenly different!
1
01:00:00,000 --> 01:00:03,000
<b>[HEAVY RAIN AND THUNDER]</b>
2
01:00:14,041 --> 01:00:16,166
<b>[THUNDER]</b>
3
01:00:20,250 --> 01:00:22,375
<b>[KEYBOARD AND TRACKBALL]</b>
4
01:00:32,709 --> 01:00:34,834
<b>[CROSSING BELLS AND TRAIN]</b>
5
01:00:41,709 --> 01:00:42,500
<b>[SCREAM]</b>

In fact I am also experiencing the reported drift. and have quantified it. Obviously something has been buggered up in the code for generating the SRT files since Resolve 15.

(1) I found a work around for the problem of the 01:00:00:00 putting the whole SRT file one hour late. The workaround was to create a new timeline beginning at 00:00:00:00 and copy the consolidated video track and the subtitle track to the new timeline. I then re-delivered the SRT from this track, and Viola - it now starts where it should start in an external player. So clearly the new algorithm being used for the SRT file is NOT taking into account the offset in the Start Timecode! This was never a problem from release 12.5 to release 15. Now it IS a BIG problem!

(2) I put the new (base 00.00.00.00) srt into the player (Vlan) and it started exactly where it should - BUT by the end of the film, the subtiles were substantially out of phase, leading the video by a matter of seconds. This is as reported by the others on this thread.

(3) Since I had an earlier version (DVS release 15) of the .srt, I cut and pasted each subtitle file into Open Office Calc, did some column and format magic, corrected for minor changes I had made to the subtitles, and compared the two by calculating the time difference subtitle by subtitle. Here is the result at the two extremes - first and close to last:

00:00:14,055 subtitle 2 in old file is 00:00:14,041 in new file. Close enough for horseshoes. 1000 subtitles in the numbers are 01:03:19,587 and 01:03:15,792 - about 4 seconds out with the new one appearing too early. By the end of the near two hour feature at subtitle 1900, the numbers are 01:53:47,862 and 01:53:33,083 — A 7 SECOND error with the new SRT ahead of where it should be.

Being an old programming hack (I first programmed in Fortran II - ), I had a hunch. My timeline is 23.976 fps. Over two hours at 24 fps one generates 172,800 frames. At 23.976 fps, one generates only 172,627 frames - a difference of 172.8 frames. Curiously, if you divide the difference by 24, it comes out to - wait for it - 7.2 seconds! Now I don't know what changes were made to the SRT algorithm, but I find this quite interesting. Don't you?

This is why I use a paid, (and fairly expensive) caption and subtitle program.

Resolve is not ready for proper in and out subtitle workflows. If you want to add a subtitle or two to a show for language translation it is fine, but i would not try to do broadcast master subtitles out of it.

I use captionmaker, and it works flawlessly for all sorts of situations. Expensive...yes, but I don't pull my hair out at the last minute trying to get it to work. Time saved, is money saved.

I reported the two issues to BM tech support. They confirmed that they reproduced my results on all 1000/1001 fps settings: 23.976, 59.94, and 29.97. So this has been escalated to the development team.

As for the other problem of not synching with the audio on external devices because of the default start time on the timeline being 01:00:00:00, this was described as follows (my bolding): "The new behavior for the start of the subtitles is perfectly and exactly correct and is a correction of the improper behavior. It is the desired behavior that the assets delivered, including the subtitles, match the TC of the originating timeline, if the asset is a timeline object.

I responded as follows, and if you agree, you might want to reinforce these points with the development team:

At the least, all users of V.17 should be/should have been advised of this behavior change before they installed V.17.

At this point, if the intent is to keep the subtitles tied to the time line rather than the output file:

(1) default time line setting for new projects should be zero. This is not currently the case. A new project automatically defaults to 01:00:00:00, meaning the subtitle problem on external devices for new and seasoned users will continue;

(2) setting a time line to other than 00:00:00:00 should come with a pop-up warning that this may impact subtitle function on external devices;

(3) There should be functionality to either (a) change the time-line base within a project or (b) change the time line base in the subtitle deliver function.

I would appreciate your passing these comments on to the development team.

Old post but this issue is still existing in 18.1
Fixing timeline settings from 01:00:00 to 00:00:00 is easy but rendering a part of the timeline where the clip does not start at 00:00:00 still requires workarounds.

Old post but this issue is still existing in 18.1
Fixing timeline settings from 01:00:00 to 00:00:00 is easy but rendering a part of the timeline where the clip does not start at 00:00:00 still requires workarounds.

I'm having the same problem where the export doesn't start at 00:00:00 and so the subtitles are delayed, but I've found a fairly simple workaround to 'time shift' the subtitle track. Just go to the following website and enter the time shift amount, and it will update the srt file for you:

https://www.happyscribe.com/subtitle-tools/srt-time-shift

eg if your export starts at 2s 15ms on the timeline, enter -2:15

Using Resolve Studio 18.5 beta
On the DELIVER page, when exporting a NEW subtitle file - the timecodes in the generated SRT file match the TimeLine - NOT THE RENDERED FILE.
This, of course, confuses YouTube, since my 30 minute video never hits the 01:08:32;16 in the SRT file, which is the <in> marker for the segment being delivered.

So pleeeeease - when the DELIVER page generates the SRT file, please fix the start time of the timecodes.

I'll do the ugly workaround where I copy the timeline to a new timeline based at 00:00:00, but come on guys - this can be isolated to the DELIVER page...
(yes - this is the Studio version)

Why don't you change the timeline start TC before working on it?

That wouldn't help Reed, Uli.

He has a 30 minute timeline and is describing exporting a range from within that timeline ... that range starts at timeline timecode 01:08:32;16 and the media and SRT exported will correctly reflect that timecode. There's no bug in Resolve here, but there is clearly room for smarter functionality.

My understanding is that adding a simple delivery page option to "Set start timecode" is needed... currently the only available timecode override option is the "Start timeline timecode at" option (under the Delivery page 'File' tab), but that's only useful for 'Entire Timeline' exports, it's pretty much useless for anyone exporting an In/Out range.