Messages

1

Video Splitter / Re: Version 6 bugs and functionality issues

« on: August 07, 2016, 02:24:02 AM »

Olga,

Thank you for your reply!

Here is a Google Drive folder containing my project, original clip, and resulting output.  In addition there is a README file that explains some problems.

Files: https://drive.google.com/folderview?id=0B7C6PULHSco7RWxJbHE1bm1fNlE&usp=sharing

For your convenience, I have posted the contents of the README below as well:

Source file: example.mkv
Project file: example_2.ssp
Output file: example_output.mkv

Subtitles start about 13m 04s into the source video.

Problem 1: When playing the output file using VLC many of the subtitles from the
original clip do not appear. In addition, the embedded subtitle file has bad
timestamps. For example, here is a segment of the resulting SRT file:

10
00:01:27,170 --> 00:01:30,839
If you want it back,
you must take it for yourselves.

11
00:02:36,461 --> 00:02:39,171
Each and every one of you.

12
00:02:13,718 --> 00:02:15,385
Fly

13
00:02:22,552 --> 00:02:24,236
Let me pass.

Notice that subtitle #11 has a timestamp AFTER subtitles #12 and #13, even though it is
supposed to appear before them.

Problem 2: The original scene has forced subtitles for when the characters speak in a
foreign language. Note that in the output file, the subtitle track no longer has the
"forced" flag.

2

Video Splitter / Re: Version 6 bugs and functionality issues

« on: August 05, 2016, 02:15:18 PM »

Another bug I've noticed in both version 5 and 6 is the following. This happens 100% of the time when editing MKV files with embedded SRT subtitles:

SolveigMM Video Splitter fails to update the timestamp of the last subtitle for each clip that is kept, for all subtitle tracks.

The resulting subtitles after saving an edited MKV are all still present and in order (I verified this by extracting and inspecting the embedded resulting subtitles file).  However, since the last subtitle for each kept clip has an incorrect timestamp, it can potentially have a timestamp value greater than succeeding subtitles, resulting in a variety of odd behaviors for video playback applications. The most common symptom is that the player will omit all succeeding subtitles that have smaller timestamp values than the erroneous subtitle. In all cases the erroneous subtitle itself is placed incorrectly during playback.

I believe this occurs because Video Splitter has an off-by-one error. As it iterates through subtitles to update their timings, the last entry is ignored, likely due to premature exit of the loop responsible for the iteration.