Help w/ Subtitling For My Deaf Friend?

[angelatc]

I have no idea what I'm doing here, so I hope one of you has the patience of a saint and can help a poor girl who knows essentially nothing about video.

I have a deaf friend and occasionally I download short videos for him and add captions using Subtitle Workshop. No problems.

We have a friend who is a filmmaker, and they asked me if I would create a subtitle file for a full length movie. I did. The filmmaker uses a Mac, and I use a PC, so we can't use the same software. I was able to create a compatible text file with Subtitle Workshop.

What I can't do is to get the titles to sync properly. The first file I sent him was out of sync. He sent me a mp4 with his time codes burned in. I tried just playing the video in several different players, and on a couple different computers, but I can't get my timers to match his burned in timer no matter what I use to play the video. I think I'm off by about 4:00 minutes an hour.

He then sent me 2 DVDs. One has the movie in an mp4 format, and the other seems to be a "real" DVD format. I am not sure how to identify that - but it has Audio_TS and Video_TS folders, along with .vbo and .ifo files.

Any thoughts would be most appreciated. I thought I understood how a copy of the DVD could be off, but I don't understand how I can be off from original DVD format.

[rumplestiltskin]

Sounds like whatever you are using for the subtitling has the wrong framerate. If the video is, for example, 29.97fps, your subtitles should be using that framerate as well.

Be patient; others will chime in with suggestions.

[creamyhorror]

The question is, how exactly are you doing the subtitling process? Are you working from the exact same video file that the filmmaker is? If you are, there should be absolutely no difference in playback on your computers.

[Cornucopia]

It's really hard to tell this one from what we've been told so far (need more info about your and their systems, FRAMERATES, software, etc)

Regarding this difference--After an HOUR...

If there was a simple difference between NTSC and PAL - changing framerates - there would be a 11 1/2 to 12 minute difference.

If there was a simple difference between Film and PAL, there would be a 2.6 minute difference.

And if there was a simple differenc between 30fps and 29.97fps in NTSC (like drop vs. non-drop) there would be a 3.6 SECOND difference.

Film vs. NTSC has judder because of TC, but no "real" time differential. If things were VERY screwed up (rare), it would be up to 15 minutes difference.

What's left?

Scott

[angelatc]

Ok - thanks so much to all of you for your replies. I am so sorry - I meant to say I was 4 seconds off per hour - not minutes.

I have to admit that I don't know what all the acronyms are, so I'll Google a bit after I write this.

I'm going to ignore the subtitle file right now and just focus on the differences in the playback timing to try to understand this.

He is using DVD Studio Pro. I am working with an mp4 in this message, not the actual DVD.

The filmmaker said the FPS is 23,976. Subtitle Workshop shows that FPS in 3 places - the "Input FPS" the "FPS" (both those fields can be changed by the user, but I don't mess with them) and also in a section of the program that also displays the time and frames elapsed, and total video length.

Right now, I ran the film to the 1 hour mark. I can't go frame-by-frame, but the timer on the software reads 01:00:00,010 (I believe that 010 is the frame count and not mircoseconds). The time burned into the film reads 00:59:56:11 (Again, I believe the 11 is the frame count.)

I loaded it on Media Player Classic, and used slider bar to reach the middle of the film as opposed to letting it play for an hour. I did go frame by frame, and where the film says 01:00:00:00 the program's timer reads 1:00:04.

Does this mean anything?

[manono]

Right now, I ran the film to the 1 hour mark. I can't go frame-by-frame, but the timer on the software reads 01:00:00,010 (I believe that 010 is the frame count and not mircoseconds). The time burned into the film reads 00:59:56:11 (Again, I believe the 11 is the frame count.)

The one at the 1 hour mark uses drop-frame timing (29.97fps) while the one at 59:56 uses non-drop-frame timing (30fps). You didn't say if the subs are early or late (probably early, eh?), so you just have to adjust the timings to account for the difference. If the subs play 4 seconds early at the 1 hour mark, then you adjust the timings with something like Input FPS=30, Output FPS=29.97. I don't use Subtitle Workshop for these things and I'm only going by what you said. Forgive me if I have something wrong.

[angelatc]

Oh, I appreciate the input! And it seems that you're not wrong - the subtitles do run ahead of the audio.

I'll try your suggestion.

Any other software suggestion, payware or otherwse, would definitely be considered.


ETA: The rest of this post is wrong - the frame numbers aren't in the STL format.



Edited to Add: This is going to make it incompatible with his file, because the format has to be hh:mms, frame#, where frame number doesn't exceed 23.

The results, changing the settings like you suggested give me numbers in the frame fields that are much higher than that. Argh.

I have to think about this. Hmmmmm. There's got to be a work-around.

[creamyhorror]

Right now, I ran the film to the 1 hour mark. I can't go frame-by-frame, but the timer on the software reads 01:00:00,010 (I believe that 010 is the frame count and not mircoseconds). The time burned into the film reads 00:59:56:11 (Again, I believe the 11 is the frame count.)

What makes you think so? Does the last number never go above 23?

Edited to Add: This is going to make it incompatible with his file, because the format has to be hh:mms, frame#, where frame number doesn't exceed 23.

If you're creating SRT files, you're mistaken on this:

00:01:04,297 --> 00:01:06,561

This is a perfectly valid SRT timecode. the number after the comma is milliseconds. So "4,297" in the quote is actually 4.297 seconds.

It seems like Subtitle Workshop may have detected the MP4's timing wrongly. You should follow manono's suggestion and play it back with the MP4 to convince yourself that it's fine.

With regard to alternate software, you can try Aegisub, which is more advanced and may detect the timing correctly. It also has waveform and spectral analysis tools so you can see voice represented visually and time it directly on the waveform. It's excellent and saves a lot of time once you learn it. (You'll have to use the Export function to save as SRT, since it only saves ASS subtitle files.)

[angelatc]

(Again, I believe the 11 is the frame count.)

What makes you think so? Does the last number never go above 23?

That is correct. When I have the Input FPS set to 23,976 that number never goes above 23.

Edited to Add: This is going to make it incompatible with his file, because the format has to be hh:mms, frame#, where frame number doesn't exceed 23.

If you're creating SRT files, you're mistaken on this:

00:01:04,297 --> 00:01:06,561

This is a perfectly valid SRT timecode. the number after the comma is milliseconds. So "4,297" in the quote is actually 4.297 seconds.

No, I understand that, but the format that I will require eventually needs the frame number after the seconds. I already sent him a test version with numbers higher than 23 in that space, and it caused the software he is using to freeze up.

It seems like Subtitle Workshop may have detected the MP4's timing wrongly. You should follow manono's suggestion and play it back with the MP4 to convince yourself that it's fine.

I changed the timing as per his advice and now the timings match, but the format of the Subtitle file is different now, with ms instead of frames in the last two slots. I think I can probably figure something out with that though. It's just a text file, and they don't have to sync to the frame, so if I can change them all to 00 I'll be fine.

Just for kicks, what is "drop-frame timing" and "non-drop-frame timing?"

With regard to alternate software, you can try Aegisub, which is more advanced and may detect the timing correctly. It also has waveform and spectral analysis tools so you can see voice represented visually and time it directly on the waveform. It's excellent and saves a lot of time once you learn it. (You'll have to use the Export function to save as SRT, since it only saves ASS subtitle files.)

Oh that sounds very cool! I shall try it in the morning! Thank you!

[creamyhorror]

No, I understand that, but the format that I will require eventually needs the frame number after the seconds. I already sent him a test version with numbers higher than 23 in that space, and it caused the software he is using to freeze up.

What format is this? I think that's the issue. I was assuming you used Subtitle Workshop to output SRT files, and SRT files (AFAIK) include milliseconds after the "," instead of frames. Your required format appears to be different.

I haven't used Subtitle Workshop, but I don't see why it would output a different time format just because the Input FPS was changed.

Oh that sounds very cool! I shall try it in the morning! Thank you!

Aegisub may not help your issue since you need the frame number to be specified after the seconds. But after you work the issue out, I'd certainly encourage you to look into it.

A basic video introduction to Aegisub, and a guide to efficient/speed timing with with the spectrum analyzer.

[manono]

Edited to Add: This is going to make it incompatible with his file, because the format has to be hh:mms, frame#, where frame number doesn't exceed 23.

I think creamyhorror asked the question, but what's his format and what program does he use to generate subs in that format? I don't really understand why he's restricted to using that format and that format only when subs in a number of formats can easily be authored for DVD. You said among the 2 discs he sent you was a true DVD of the movie. Can't you add the subs yourself, burn a copy, and then send it back to him? If so, follow Method 2 in this guide to get the subs in SRT format into the DVD. Then if he doesn't like what you've done, he can demux them and do whatever he likes with them:

https://forum.videohelp.com/topic338721.html

[angelatc]

He is on a MAC using DVD Studio Pro. He needs an STL file.

The DVD he sent me has his time codes burned in, so he'd have to demux (if that's the right word) regardless.

Something I had done in Subtitle Workshop created an SRT file that put the frame numbers in the last 3 fields. It might read 080, but that will be frame #8, and it matches the code burned into the movie. I never get anything like 280, for example. I attached a teeny text file example if you want to see an example. Well, it was an SRT file - I stripped out the other 1600 lines and saved it as a txt file.

I dropped the extra digit when I converted the SRT to the STL file. I believe I can change my conversion program to just replace those digits with zeros, which will suit my purposes just fine.

This timing change has so far worked like a charm and I can't thank you enough.

I am still curious about what "drop-frame timing" and "non-drop-frame timing" is. Is there a link for that?

videohelpexcerpt.txt

[manono]

Drop-frame .vs non-drop-frame timing is the same as 29.97fps .vs 30fps. As you know, NTSC DVDs have to output 29.97fps (actually 59.94 fields per second), but movies are 24fps (hence 3:2 pulldown), and video is 30fps. To get a movie from 24fps to 23.976fps and video from 30fps to 29.97fps the drop_frame flag is set which says (sort of) to drop one frame in every 1001. No frames are actually dropped. The effect is to slow it down:

Don't get a wrong concept of DROP_FRAME as "FRAMES being REMOVED or DROPPED". In a 30fps Video sequence, a DROP_FRAME time code counts video frames accurately in relationship to real time. DROP_FRAME time code counts each video frame, but, when that .03 finally adds up to a video frame, it skips (or drops) a number. It does not drop a film or video frame, it merely skips a number and continues counting. This allows it to keep accurate time. So if you're cutting a scene using drop frame time code, and the duration reads as, say, 30 minutes and 0 frames, then you can be assured the duration is really 30 minutes. Confusing? Well, to put it in simple term, DROP_FRAME here is in essence EQUAL a SLOWED_DOWN playback from a pure 30fps into the correct NTSC 29.97fps SPEED. In an MPEG-2 domain, this means that the 00 and 01 frames are dropped or SKIPPED from time code, at the start of each minute except minutes which are even multiples of 10.

http://www.doom9.org/synch.htm

You could still add the subs to that DVD and then he can easily extract them for use in the 'real' DVD. I've never heard of an STL file myself, but then I work on Windows machines. But maybe it'll be easier for both you and him if you send your modified SRT file. Somehow though, that's just seems too easy to me and I'd expect some sort of problem at his end.

[creamyhorror]

Something I had done in Subtitle Workshop created an SRT file that put the frame numbers in the last 3 fields. It might read 080, but that will be frame #8, and it matches the code burned into the movie. I never get anything like 280, for example. I attached a teeny text file example if you want to see an example. Well, it was an SRT file - I stripped out the other 1600 lines and saved it as a txt file.

Your excerpt is pretty strange, since it's clearly in SRT format. I have no idea why Subtitle Workshop is doing that (making the first digit after the comma 0). The third digit appears to always be 0 as well, which means it's not referring to the frame number at all. So it's not actually the STL format that your filmmaker friend needs.

I dropped the extra digit when I converted the SRT to the STL file. I believe I can change my conversion program to just replace those digits with zeros, which will suit my purposes just fine.

The proper format for an STL file involves no comma in the timecode - it looks like

00:00:10:07 , 00:00:12:21 , No, did Edwards quote me right?

This is pretty different from the SRT output from Subtitle Workshop, so how exactly are you converting it? What conversion program are you using?

The best thing would be to use a program that is actually capable of converting from SRT to STL. If you have to manually get the program to output the correct format, you're using the wrong program.

Here's an SRT-->STL converter,
from Doom9's Useful Software page. I haven't tested it, but a quick search shows that some people used it (years ago).

[manono]

Good find, creamyhorror. I got it and was just playing around with it. Works well. Here's a direct link:

sub2stl.zip

[angelatc]

Your excerpt is pretty strange, since it's clearly in SRT format. I have no idea why Subtitle Workshop is doing that (making the first digit after the comma 0). The third digit appears to always be 0 as well, which means it's not referring to the frame number at all. So it's not actually the STL format that your filmmaker friend needs.

No, I convert it, and only pick up the first 2 digits. The first digit after the comma isn't always zero - it's just a fluke in that example. The numbers run from 000 to 230. The first 2 digits are the frame number. I can verify that by looking at the burned-in time codes before the movie gets too much out of sync.

This is pretty different from the SRT output from Subtitle Workshop, so how exactly are you converting it? What conversion program are you using?

Subtitle Workshop. They have a "Custom Format" option, so I wrote it. It merged just fine, so I'm ok there. You're right - I don't need the frame numbers. For some reason I thought they were in there but they're not.

We originally did this whole caption-thing in 48 hours. Some bits of it are blurry.

The best thing would be to use a program that is actually capable of converting from SRT to STL. If you have to manually get the program to output the correct format, you're using the wrong program.

Here's an SRT-->STL converter,
from Doom9's Useful Software page. I haven't tested it, but a quick search shows that some people used it (years ago).

LOL! I wish I had seen that 3 weeks ago. Seriously, Subtitle Workshop has about 100 conversion options included. It's apparently abandonware now, which is a shame because it's so much more versatile than anything else out there, payware or otherwise. I'm hardly a power user, but even I was able to quickly write a custom format that worked properly.

I turned on voice recognition software, repeated the words the actors were speaking, and subtitled a 1:57:00 minute feature-length film in less than 2 days. Considering how badly my typing sucks, that's a miracle. I think it's a very good program, except for this timing nonsense, which is sadly happening again today. The input FPS and FPS are set at 30 and 29.97 respectively, but it's showing the input FPS as 24. So I'm out of sync by a little less than a minute at the 13 minute mark. I can see where this is going... That's unfortunately what makes it the wrong program in my book.

I'm going to try Aegisub today.

[manono]

... but it's showing the input FPS as 24.

So, make InputFPS=24 and OutputFPS=23.976. Same ratio as before.

[creamyhorror]

Subtitle Workshop. They have a "Custom Format" option, so I wrote it.

Oh, the custom format explains it.

I turned on voice recognition software, repeated the words the actors were speaking, and subtitled a 1:57:00 minute feature-length film in less than 2 days.

That's a pretty good idea

The input FPS and FPS are set at 30 and 29.97 respectively, but it's showing the input FPS as 24. So I'm out of sync by a little less than a minute at the 13 minute mark.

The FPS is detected by Subtitle Workshop from the video file, so it should be correct. The input FPS should be set to the same value, since you're not trying to change the framerate of your subtitles (see explanation here). Unless, of course, the framerate in the video you received is set incorrectly - which might explain the desyncs you're getting.

[angelatc]

Subtitle Workshop. They have a "Custom Format" option, so I wrote it.

Oh, the custom format explains it.

I didn't write the .SRT format. Just the STL format.


The FPS is detected by Subtitle Workshop from the video file, so it should be correct. The input FPS should be set to the same value, since you're not trying to change the framerate of your subtitles (see explanation here). Unless, of course, the framerate in the video you received is set incorrectly - which might explain the desyncs you're getting.[/quote]

I'll invite him to view this thread. He can talk technical with you if he's around.

I'm just totally stumped. No matter what combination of FPS settings I use in Subtitle Workshop, I end up out of sync. Having the exact same issue in Aegisub today, being able to match up the words with the audio graph makes it cool anyway.

It appears that shifting the times is a more user-friendly process in this program, so I'll just write the whole file out of sync, then go through and sync it with the on-screen codes. He should be able to get one of the two close enough to manipulate in his program.

The video framerate shows as 23.976 in Aegisub's info, btw.

[creamyhorror]

Okay, I re-read your first post and understand now. I'm surprised manono's suggestion didn't work, because it seems like it should.

It appears that shifting the times is a more user-friendly process in this program, so I'll just write the whole file out of sync, then go through and sync it with the on-screen codes. He should be able to get one of the two close enough to manipulate in his program.

No need to do it manually. When you export your SRT, tick the Transform Framerate option in the Export window, and enter 24fps for Input Framerate and 23.976 for Output Framerate. This will cause all your timings to scale down, i.e. they will appear sooner. The resulting SRT file should match the timecodes burned into the video.

What's actually happening is that the video is set to play at 23.976 fps while the timecodes are acting as though it's playing at 24fps. So you should be able to correct for this by transforming the framerate.

Does the audio actually match the video perfectly? I'm finding the situation a little hard to imagine, since you're timing to the audio, which should be in sync with the video.

[angelatc]

Hi, didnt mean to disappear on you. I do appreciate the help.

Thanks for the export tip! That''' save me loads of time.

Yes, the audio and video match perfectly all the way through.

[creamyhorror]

Glad to hear that. So do you have a fast workflow that works for you?

By the way, in case you're interested in learning more about Aegisub, here's an example of high-speed Aegisub timing with the spectrum analyzer, and this one is a sort of informal video tutorial on how to do it yourself. (Right-click -> Save As)

[angelatc]

I had a great workflow until I started this project. Everything that could go wrong, did. Keeps life interesting, I guess.

I am definitely going to check out Aegisub in greater detail. That's probably the program that made the Subtitle Workshop people toss in their towel. They had a better conversion program though - like I said, there are about 100 formats to pick from plus the ability to write a custom format.

I never could get the sub2stl.zip to work. It might be a Vista thing, but it just hangs up.

[creamyhorror]

Well, without sub2stl I hope your method is still fast. (I'm not exactly sure what you're doing at this point ) Best of luck.