Problem wih subtitle edit

[mitof1]

Why when I insert srt file and after this convert into .scc. Timing in scc is changed and the 2 lines are splitted of 3 lines?
I want when I export subtitle file no change in timing and the lines. Thanks.

[ndjamena]

Closed Captions have a 32 character limit, could that be the problem?

The developers of Subtitle Edit haven't actually known how subtitles work. I've gave them everything I know a few weeks ago but I don't know what's been done with it.

Which version are you using? Try the current version and the previous version and see if there's a difference. They may have changed something.

How are you determining the timing is different? As far as I can tell no free software has ever known how Closed Captions actually work and all have a broken implementation.

[mitof1]

Check before and after.

[ndjamena]

OK, so the extra lines are being cause by the 32 character per line limitation in Closed Captions. If you're converting to closed captions there's no way around that.

The different timings are being caused by the bandwidth limitations in Closed Captioning. Bascially, Closed Captions are an analogue NTSC standard designed to be written into Line 21 two bytes at a time 29.970 times a second, which means at an absolute maximum, without any formatting or special characters, it's possible to write only about 60 characters into Closed Captions per second.

I have a nasty feeling the current implementation of Subtitle Edit uses the "60 characters a second" limitation as an absolute and ignores the formatting/special character bytes that are needed for every line, I haven't put it to the test yet though.

Subtitle Extractor has to alter the timecodes to fit the subtitles into whatever speed limitation processes they're using.

Bascially, you're encountering the Closed Caption limitations, Subtitle Edits implementation of Closed Captions may not be perfect at the moment but you'll never get an exact representation of your srt files while converting to proper Closed Captions.

[Nikse]

Yes, Subtitle Edit enforces max 32 chars per line and max four lines, so make sure your srt uses the same settings (better max two lines at max 32 chars).

The time codes may not be perfect in SE for scc files (patches on github are welcome

[ndjamena]

If you can figure out how to get the wreckage in my skull into some kind of working order I'm there.

Just remember the golden rule: "They need to be able to be written back into Line 21, since that's what they're designed to be."

[Spider1972]

i gives manual 23.976 fps in subtitle edit, and get 24 fps. With exporting to blu-ray sup
tsmuxer and suptosub gives 24 fps on the display

[dror]

I've been doing more work recently that involves delivering captions in SCC format, so I found myself spending hours researching it and understanding its somewhat arcane logic.

What ndjamena writes is spot on. To quote SCC Tools` documentation:
"Closed Captions are potentially displayed much more slowly than subtitles. Closed Captions have to be built up in a buffer before they can be displayed, and this process takes time, around 10 characters per second. If a subtitle is timed to appear too soon after a previous one, there will be trouble converting the times over to the captions. SUBRIP2SCC's response to this problem is to move the start time forward as necessary to prevent overlap between captions. As a result, these captions will appear late and may be replaced by the next (on-time) caption before the viewer has had a chance to read it."

It took me a long time to realize that the buffer has a "writing" time (makes sense really, when you understand the broadcast origins of CEA-608). And there's always a juggle between the buffer, actually displaying the text on the screen, and clearing it off the screen.


Alas, from my research so far, all free tools do not handle this limitation properly:

Subtitle Edit issues a Display command immediately after writing the buffer, which is the worst option, because it leaves it up to the player to display it as soon as it can - which is definitely not the timecode in the SCC file. Therefore ALL the captions' in points are off the mark, delayed by x frames (x=the caption's character count / 2).

Rev.com's online converter tool is aware of that, but the result ends up being the same. It, too, issues Display after buffering. It just calculates how long buffering should take, and delays the in point intentionally. So the timecodes in Rev's scc file will display at those times, but the timecodes are delayed too.

SCC Tools` developer obviously "gets" SCC, so I was disappointed to see he uses the same write-then-display method. It seems to a fare a bit better, though.

One tool that does it right (smartly) is Telestream MacCaption, which writes the caption AFTER a display command, not before. In other words, it starts writing the next caption to the buffer as soon as possible (right after the last one was sent out to the display) rather than as late as possible. This gives the most time to fill up the buffer, almost always enough to avoid any display delays.

Here is what it all looks like, in a challenging case of a long caption immediately after a short one: ((which happens to be from a crass character in a comedy))


You can see the mess. MacCaption is the best by far. Too bad it's $1,100.