Woodstock wrote:But, recoding the video would break the branching created for the original source, assuming the recoding software (in my case handbrake) could figure out the "combo" file generated by Xin1generator.
There is no any special in the MKV created by Xin1Generator: Imagine a movie with the normal edition and the edition with alternative end. So, the first edition has the segments 1-2-3 and the altenative the segments 1-2-4. Imagine that you select in the program the "alternative" as main movie and the normal edition as the second edition to be included in the MKV.
So, the MKV created would include all the segments in following order 1-2-4-3 (first the segments of main movie, and following the different segments of next editions). If you see the video, you will have one movie, and after the end credits some parts of the movie, which are used to "create" the other editions.
In order to control which parts of the movie are shown in each edition, MKV ordered chapters are used. For example, if each segment is 10 minutes lenght:
-Edition1
chapter 1 - Start 00:00:00.0000 - End 00:10:00.000
chapter 2 - Start 00:10:00.0000 - End 00:20:00.000
chapter 3 - Start 00:20:00.0000 - End 00:30:00.000
- Edition2
chapter 1 - Start 00:00:00.0000 - End 00:10:00.000
chapter 2 - Start 00:10:00.0000 - End 00:20:00.000
chapter 3 - Start 00:30:00.0000 - End 00:40:00.000
Note that when playing "edition 2", first two chapters are the same as edition 1, but third chapter starts in minute 30 (instead of in minute 20 of edition 1).
When you are recoding, you are recoding a video file, with no information about the branching, which is stored in the xml file of chapters (which is not recoded).
Additionaly, the program generates a file with a list of frames that need to be encoded as I-Frames if re-encoding, but I really don't know how to used (as I don't recode).
Woodstock wrote:But the arguments either way might be moot - Given that a recoding can shrink the file significantly, you could potentially keep multiple versions around while maintaining a space saving. Example: Raw 2D rip of Star Trek Beyond is just under 31GB; Recoded to h264 video, it's just under 6GB.
I agree with you that if you are compressing so much the movie, it is not necessary to "save space" keeping different editions of the movie in the same MKV file. Hovewer, I do not recode the movie, and when keeping the "raw" information of the bluray, the space saved can be several Gb.
Woodstock wrote:Both versions of Blade Runner that I keep on my system total 7GB, which is less than half the size of the smallest of the 4 raw files. I don't see from the description how it would work on a title like Blade Runner anyway, since the 4 versions are spread out over 3 disks.
In this case (different editions in different disks) the program is useless. It is only valid when different editions are in just one disk.
Woodstock wrote:How do things like "smart" TVs deal with the constructed MKV file? What about popular media players (discounting Apple products, because they don't "do" MKV anyway)?
The only requirement is that the player must "understand" the "ordered chapters". When playing in a computer there is no problem, since VLC, MPCHC, and any program using Haali Splitter understand this information.
However, when playing in other "hardware" devices surely the "ordered chapters" are not taken into account, so it is not possible to access the alternative editions. But not all is lost: As the first (main) movie is correctly ordered in the MKV, it can be played in any device. In this situation, after the end credits some additional scenes will be shown, but this does not affect to the main movie.