May 2, 2013 at 18:13SubRip Subtitle Extender (.srt)
If a person has a practice of communicating in a foreign language and understanding by ear, subtitles for him are just a help, the meaning of which depends on the intelligibility, normativity, complexity and speed of speech on the screen. But if a person just reads reasonably well in a foreign language, subtitles for him are the main source of information.
Unfortunately, in the second case, the usual time for displaying titles is not enough. You can lengthen it in many programs (for example, in SubtitleEdit ) - but sometimes this lengthening is limited by reasonable limits, and launching a full-fledged editor for such a simple action is not always convenient.
Therefore, I tried to write simple scripts only for this need and chose two principles for lengthening time.
1. Extension in one direction: the end of the display of each subtitle is extended until the beginning of the next subtitle (one millisecond less so that there is no overlap). This is a simpler method, but it is not so effective, because time is distributed one-sidedly. On the other hand, this method is more familiar.
2. Extension in both directions: first, the pause time between two subtitles is calculated, then this pause is divided in half - one half is added to the end of the current subtitle, the other is subtracted from the beginning of the next one. Thus, each subtitle as far as possible precedes its sound replica and, if possible, is delayed as much as possible on the screen after it. You need to get used to this format a little, but the time is distributed more evenly and the viewer has a relative opportunity to read and understand key phrases in advance.
The scripts are implemented in two forms: in JavaScript (network version) and in Perl (local console version).
The network version is represented by a page with the water area of the source text of the subtitles and the output area of the elongated version. It is not so convenient (you need to open the subtitles in a text editor, copy the text, change it using a script, paste the changed version and save it), but it is simple and public (I checked the work in the latest versions of Chrome, Firefox, Opera and Safari). The page can be saved to disk, and it will work locally.
The console version is represented by a Perl script that takes an argument to the source file (if you do not specify an argument, the script asks about it in interactive mode) and creates a new file with an extended display time, adding a .long tail to the name. It works with UTF-8 encoding at the input and output (having received a different encoding, the interpreter itself must report an error - in this case, save the original subtitles to UTF-8).
It hardly makes sense to explain the code, everything is very simple: both scripts turn the source text into an array of arrays, analyze pauses, lengthen the time, and then put everything back into subtitle text. Some dubious curiosity can only be represented by two small functions that convert SubRip timecodes to milliseconds and vice versa, to simplify the calculations - but they are also quite obvious.
The scripts do not check the text for compliance with the format and do not correct the initial timing errors (overlapping timecodes, negative display time, etc.), therefore, in case of doubtful subtitles, it is better to perform all checks beforehand in full-fledged editors (for example, in the same SubtitleEdit ). The console version only checks the file extension (if not .srt, exits with a warning) so that by mistake it starts to process something big.
The script code is more than amateur, for which I apologize. Improve as necessary to your taste (for example, you can limit the time of extensions or invent a trickier algorithm, depending on the length of each subtitle).
JavaScript browser versions:
Browser subtitle extension (.srt): one way
Browser subtitle extension (.srt): on both sides
Local versions on Perl:
Console subtitle extension (.srt): one way
Console subtitle extension (.srt): both sides
P.S. Added extension cord in both directions for Node.js. It works the same way with a few additions: it can read files in both UTF-8 and UTF-16 LE; files in pure ASCII will be read as UTF-8 files for simplicity of code (there will be no differences anyway); the script can take several arguments, that is, process multiple files in batches.
Cantilever Subtitle Extender (.srt): both ways for Node.js
Unfortunately, in the second case, the usual time for displaying titles is not enough. You can lengthen it in many programs (for example, in SubtitleEdit ) - but sometimes this lengthening is limited by reasonable limits, and launching a full-fledged editor for such a simple action is not always convenient.
Therefore, I tried to write simple scripts only for this need and chose two principles for lengthening time.
1. Extension in one direction: the end of the display of each subtitle is extended until the beginning of the next subtitle (one millisecond less so that there is no overlap). This is a simpler method, but it is not so effective, because time is distributed one-sidedly. On the other hand, this method is more familiar.
2. Extension in both directions: first, the pause time between two subtitles is calculated, then this pause is divided in half - one half is added to the end of the current subtitle, the other is subtracted from the beginning of the next one. Thus, each subtitle as far as possible precedes its sound replica and, if possible, is delayed as much as possible on the screen after it. You need to get used to this format a little, but the time is distributed more evenly and the viewer has a relative opportunity to read and understand key phrases in advance.
The scripts are implemented in two forms: in JavaScript (network version) and in Perl (local console version).
The network version is represented by a page with the water area of the source text of the subtitles and the output area of the elongated version. It is not so convenient (you need to open the subtitles in a text editor, copy the text, change it using a script, paste the changed version and save it), but it is simple and public (I checked the work in the latest versions of Chrome, Firefox, Opera and Safari). The page can be saved to disk, and it will work locally.
The console version is represented by a Perl script that takes an argument to the source file (if you do not specify an argument, the script asks about it in interactive mode) and creates a new file with an extended display time, adding a .long tail to the name. It works with UTF-8 encoding at the input and output (having received a different encoding, the interpreter itself must report an error - in this case, save the original subtitles to UTF-8).
It hardly makes sense to explain the code, everything is very simple: both scripts turn the source text into an array of arrays, analyze pauses, lengthen the time, and then put everything back into subtitle text. Some dubious curiosity can only be represented by two small functions that convert SubRip timecodes to milliseconds and vice versa, to simplify the calculations - but they are also quite obvious.
The scripts do not check the text for compliance with the format and do not correct the initial timing errors (overlapping timecodes, negative display time, etc.), therefore, in case of doubtful subtitles, it is better to perform all checks beforehand in full-fledged editors (for example, in the same SubtitleEdit ). The console version only checks the file extension (if not .srt, exits with a warning) so that by mistake it starts to process something big.
The script code is more than amateur, for which I apologize. Improve as necessary to your taste (for example, you can limit the time of extensions or invent a trickier algorithm, depending on the length of each subtitle).
JavaScript browser versions:
Browser subtitle extension (.srt): one way
Browser subtitle extension (.srt): on both sides
Local versions on Perl:
Console subtitle extension (.srt): one way
Console subtitle extension (.srt): both sides
P.S. Added extension cord in both directions for Node.js. It works the same way with a few additions: it can read files in both UTF-8 and UTF-16 LE; files in pure ASCII will be read as UTF-8 files for simplicity of code (there will be no differences anyway); the script can take several arguments, that is, process multiple files in batches.
Cantilever Subtitle Extender (.srt): both ways for Node.js