Creating single .mkv out of multiple .mpg + .srt files without reencode/recompress

[Avisynth_challenged]

Hi, I am a MKV newbie, so I know I am in the right area of the forum :)

I have a simple question. I have a set of multi-part .mpg files which have accompanying .srt subtitle files. For example:

My_video_1.mpg
My_video_1.srt
My_video_2.mpg
My_video_2.srt
My_video_3.mpg
My_video_3.srt
My_video_4.mpg
My_video_4.srt
My_video_5.mpg
My_video_5.srt

In playlist mode (i.e. "play folder" option in VLC or MPC-HC), the .mpg videos play in order, and the corresponding .srt subs are correctly displayed (if subs are enabled in the player).

I am wondering if there is any tool that can accept the .mpg/.srt files as input, and generate a single .mkv file containing the video and subs as output, and which can be played properly (in proper order, with optional subtitles) using a player that can read .mkv files. Also, I just want to "encapsulate" (to use VLC's term) the data within a MKV container. I do not wish to reencode/recompress the original video or audio in any way.

Thanks in advance for any replies :)

[sneaker_ger]

Mkvmerge should be able to pull it off, but it may need more than one step. (First mux each mpg with corresponding srt, then append all parts.)

[Avisynth_challenged]

Mkvmerge should be able to pull it off, but it may need more than one step. (First mux each mpg with corresponding srt, then append all parts.)

Thanks for the input. So just so I understand you correctly, you mean:

STEP 1: Mux mpg1/srt1 to output mkv1, and repeat for segments 2-5.

STEP 2: Join the resulting MKV files 1-5 into a single .mkv file.

And both steps above can be done with Mkvmerge... correct?

Thank you once again :thanks:

[sneaker_ger]

Yes, that should do it. You could also try single step (directly append all tracks), but I'm not sure if it will append the subtitle tracks reliably.

[Avisynth_challenged]

Yes, that should do it.

Thanks a bunch. I will definitely try it out.

[sneaker_ger]

Please see my edit and try single step first. It may or not work, but if it does it is easier and faster.

[Avisynth_challenged]

I played around with Mkvmerge. Great suggestion, and great tool. Thanks.

It automatically appends the .mpg files that have numerically ordered filenames (file1.mpg + file2.mpg ...) inside the .mkv container it generates as output. That is, I only needed to add "file1.mpg", and it automatically processed it, plus "file2.mpg"... "file5.mpg", in correct order. Very convenient.

Mkvmerge does not, however, do the same thing for .srt files that have numerically ordered filenames (file1.srt + file2.srt ...). And actually, this makes sense. Each .srt is unique for the corresponding .mpg from which it was derived, so appending would not make sense, since all .srt files begin at time 0:00:00. I cannot expect Mkvmerge to make on-the-fly timing changes required to create new subtitle output that corresponds to the joined/appended .mpgs.

So I need to go back to the .srt generator I used, which is CCExtractor (Windows GUI), to make a single .srt file from the segmented .mpg input files. I'll have to see if I can automate this step in CCExtractor, as I have a number of segmented .mpg videos to process.

I am very pleased with what I've been able to accomplish with Mkvmerge. I thought I would have to resort to an mpeg joining tool (like VideRedo) to do the job, but dumping the .mpg segments into a single MKV-encapsulated file is much easier, and faster. On my machine, a test case took about 2 minutes to create a .mkv file (Mkvmerge). The same test case took about 3 minutes to create a new .mpg file (VideRedo). Big time saver, in my book :)

Thanks again for all your help.

[sneaker_ger]

Mkvmerge does not, however, do the same thing for .srt files that have numerically ordered filenames (file1.srt + file2.srt ...). And actually, this makes sense. Each .srt is unique for the corresponding .mpg from which it was derived, so appending would not make sense, since all .srt files begin at time 0:00:00. I cannot expect Mkvmerge to make on-the-fly timing changes required to create new subtitle output that corresponds to the joined/appended .mpgs.

The thing is: I think it is supposed to be able to do it, but maybe this feature hasn't been tested enough.

It may also depend on how mkvmerge appends the mpg files. It can regard them as a single big file (like a binary split) or as several independent videos. (In addition to that there are also two additional append-modes)
See the mkvmerge docs on appending for more info.

[Avisynth_challenged]

Thanks for that. I'll continue testing and studying the documentation. If I can get it to work completely in one step (instead of two), that will be so awesome, since the speed of Mkvmerge is (in my view) it's greatest advantage. Converting a multi-part .mpg into a single .mkv using Mkvmerge is as quick (on my system) as doing a copy-paste operation on the .mpgs themselves in Windows. I am amazed that I am only limited, in terms of processing speed, by the I/O bandwidth of the SATA hardware in my system (and maybe a little system overhead in Windows).

In short, I am now a big fan of Mkvmerge :D

[Avisynth_challenged]

In short, being able to append multiple .srt files directly with Mkvmerge (i.e. in one step, using the GUI) is not possible as it is with video input files. (Edit: it can be possible to do it with the CLI, but it is somewhat cumbersome as you will see.) I found an online page written by the author of Mkvtoolnix in which he answers the question "Is it possible to append subtitles so that it works?"

His response (dated March 22, 2012) was this:

This is absolutely possible if you know how mkvmerge works. You don't? Don't worry, I do, and here's the gist:

When mkvmerge appends a track onto another one it calculates its total duration. This is usually timecode + duration of the very last packet seen for this track. However, subtitle tracks are treated specially: for them the duration of the whole container they're read from is used instead.

If you read subtitles from an SRT file then the track's duration is unfortunately also the container's duration -- because an SRT file doesn't have any other track inside safe for the subtitle track. But if you read the SRT track from, say, a Matroska file which also included a video track then the subtitle's total duration would be the Matroska file's duration -- which in turn would probably be the video track's duration.

So there are two ways to achieve what you want:

1.Do a two-pass muxing. First mux file1.h264 and file1.srt into file1.mkv. Then mux file1.mkv and append both file2.h264 and file2.srt. In command line terms this looks roughly like this:

$ mkvmerge -o temp.mkv file1.h264 file1.srt
$ mkvmerge -o final.mkv temp.mkv +file2.h264 +file2.srt

2.Stay with a one-pass muxing and delay the second subtitle file manually by some amount, e.g. 10s for the example you've posted. Again in command line terms:

$ mkvmerge -o final.mkv file1.h264 +file2.h264 file1.srt --delay 0:10s +file2.srt


*Source*
https://www.bunkus.org/answers/?qa=174/is-it-possible-to-append-subtitles-so-that-it-works

[sneaker_ger]

I think this may be one of those cases where Mosu forgot about his own implementation.
Sample (execute merge.bat):
http://www.file-upload.net/download-6737330/srt_append_sample.7z.html

(I'm kinda busy starting now, so my answer could take a bit.)

[sneaker_ger]

Oh, wait. I think this sample might not be suited since the lines go right to the end of each part. I will have to make a different sample, but probably not before Wednesday. Maybe Mosu will chime in in the mean time, though.

[Mosu]

@sneaker_ger:

First, "--append-mode" is a global setting. My guess is your intention was to have it set to "track mode" for the first two cases and "file mode" for the SRT file. This does not work.

Second, "--append-mode" only makes a difference if at least one input file ocntains more than one track. In your example file none of them do. Therefore you can leave out "--append-mode" completely. This can be proven by creating two sample files with "--engage no_variable_data" and comparing them binarily. Here's how I do this with zsh in Linux (cmd.exe has similar instructions, I'm certain):

export MKVMERGE_ENGAGE=no_variable_data
mkvmerge -o merged-append-mode.mkv --append-mode track a.h264 + b.h264 + c.h264 + d.h264 + e.h264 + f.h264 --append-mode track a.ac3 + b.ac3 + c.ac3 + d.ac3 + e.ac3 + f.ac3 a.srt + b.srt + c.srt + d.srt + e.srt + f.srt
mkvmerge -o merged-no-append-mode.mkv a.h264 + b.h264 + c.h264 + d.h264 + e.h264 + f.h264 a.ac3 + b.ac3 + c.ac3 + d.ac3 + e.ac3 + f.ac3 a.srt + b.srt + c.srt + d.srt + e.srt + f.srt

Third, now let's compare the result with how an appended file created with my advice above would look like. First, create all intermediate files (a.h264, a.ac3 and a.srt into a.mkv, same for b through f):

for part (a b c d e f) mkvmerge -o ${part}.mkv ${part}.h264 ${part}.ac3 ${part}.srt

And append them together:

mkvmerge -o merged-method-2.mkv a.mkv + b.mkv + c.mkv + d.mkv + e.mkv + f.mkv

Last, compare the timecodes for the very last subtitle entry for both methods:

for src (append-mode method-2) mkvinfo -s merged-${src}.mkv | grep 'track 3' | tail -n 1

The result is (first line for your method, second line for my method):

I frame, track 3, timecode 84125 (00:01:24.125), duration 1626.000, size 10, adler 0x12f6035d
I frame, track 3, timecode 91044 (00:01:31.044), duration 1626.000, size 10, adler 0x12f6035d

Your way is better in this case, because the whole movie is only 1:25 long, and my way would shift the subtitles off quite a bit.

So my answer is, unfortunately, incomplete and appears wrong. However, my method works just fine when I use "--append-mode track" instead of the default:

mkvmerge -o merged-method-4.mkv --append-mode track a.mkv + b.mkv + c.mkv + d.mkv + e.mkv + f.mkv
mkvinfo -s merged-method-4.mkv | grep 'track 3' | tail -n 1

Result:

I frame, track 3, timecode 84125 (00:01:24.125), duration 1626.000, size 10, adler 0x12f6035d

Unfortunately "--append-mode track" does not always do what you want it to, therefore I cannot recommend it for all cases. Otherwise the option wouldn't exist in the first place.

When you have your test case I'll look at it.

[Mosu]

Additional information. The reason why there are two different append mode implementations is that mkvmerge simply cannot know which one to chose. It is too flexible for that.

The "file" mode is usually used when you append stuff that comes from two distinct source files. For example, a while ago you encode a very long movie into two AVIs. Now you want to make one big mkv from them. You use the default, "file" append mode.

Second example: you have a long mkv you want to split with mkvmerge. Later you want to re-merge them into a single big file. Such a case would work with the "file" mode as well, but it will work even better with the "track" mode because that way the packets surrounding the cut point are interleaved better.

I could draw up some diagrams one day for this. But not today.

[Avisynth_challenged]

Thanks to all who have responded. As I am using Mkvmerge as a means to combine successive video clips into one "MKV container file" for archival purposes, I have a follow-up question.

Currently, I am putting individual files, i.e.

video_1.mpg,
video_2.mpg...
...video_n.mpg,
+
video_all.srt,

into a single .mkv file, i.e. "video.mkv".

Now at this point, I can either keep the original source files (.mpg's + .srt), or I can delete them once they have been archived into the .mkv file.

But can I take the .mkv file and recover the original source files back, using any splitter or demux utility... perhaps within Mkvtoolnix?

Once again, thanks to all for the helpful discussion. It is very much appreciated.

[sneaker_ger]

Mkvtoolnix can only demux and/or split. If you combine it with an mpg muxer (ffmpeg) you could get the original files back, more or less.

If you want to get bit exact copies of the original files back you could use something like xdelta.

(I haven't looked at the split sample again, yet)

[Avisynth_challenged]

I appreciate your helpful responses. I'll have to check out xdelta next :)

[sneaker_ger]

Finally came around looking at the sample thing again:

@sneaker_ger:

First, "--append-mode" is a global setting. My guess is your intention was to have it set to "track mode" for the first two cases and "file mode" for the SRT file. This does not work.

Second, "--append-mode" only makes a difference if at least one input file ocntains more than one track. In your example file none of them do. Therefore you can leave out "--append-mode" completely. This can be proven by creating two sample files with "--engage no_variable_data" and comparing them binarily. Here's how I do this with zsh in Linux (cmd.exe has similar instructions, I'm certain):

I indeed missed the part about it being a global option and that it does not affect single tracks.

I think I do understand when to use file and track otherwise, though. (I.e. "track" will not leave any gaps in the timecodes at the append points, which is desired for tracks that were originally in one big file)

About a second sample: I did create and test one now, but the result is still the same. All raw 264 + ac3 + srt files were appended in one step (without prior muxing them into many mkvs) and the resulting subtitles are in sync. And I'm not talking about "just in sync", but bit for bit identical to the original srt track. Thus I will not upload the second sample.
Seems like mkvmerge does wonders sometimes...