One tool that does it right (smartly) is Telestream MacCaption, which writes the caption AFTER a display command, not before. SCC Tools` developer obviously "gets" SCC, so I was disappointed to see he uses the same write-then-display method. So the timecodes in Rev's scc file will display at those times, but the timecodes are delayed too. It just calculates how long buffering should take, and delays the in point intentionally. Rev.com's online converter tool is aware of that, but the result ends up being the same. Therefore ALL the captions' in points are off the mark, delayed by x frames (x=the caption's character count / 2). 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. And there's always a juggle between the buffer, actually displaying the text on the screen, and clearing it off the screen.Īlas, from my research so far, all free tools do not handle this limitation properly: 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). 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." SUBRIP2SCC's response to this problem is to move the start time forward as necessary to prevent overlap between captions. If a subtitle is timed to appear too soon after a previous one, there will be trouble converting the times over to the captions. 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. "Closed Captions are potentially displayed much more slowly than subtitles. 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. Subtitle Extractor has to alter the timecodes to fit the subtitles into whatever speed limitation processes they're using.īascially, 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. 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. 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. The different timings are being caused by the bandwidth limitations in Closed Captioning. If you're converting to closed captions there's no way around that. OK, so the extra lines are being cause by the 32 character per line limitation in Closed Captions.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |