is this reliable method to join m2v? / VOB losslessly through mkvtoolnix

[efc1978]

Hi,

I have 2x 1 hour each m2v's and a 2 hour PCM WAV I put through mkvtoolnix to play as .mkv off USB on my Blu-ray recorder, however when the video gets to the end point of the first .m2v / start point of the second .m2v it stops playing, so I guess there's a problem with the .mkv changing from one m2v to another, I wasn't sure how to losslessly join 2 m2v's but I had the idea to take the 2 original m2v's and PCM WAV audio and mux into VIDEO_TS using Muxman, I then loaded the first VOB from the VIDEO_TS folder that Muxman made into mkvtoolnix which automatically then loaded all the other VOB's and output as .mkv.
Now the .mkv I have plays all the way through.
Does this sound like a technically OK method to resolve the problem of the original 2 separate m2v's not working separately?
I guess this should be lossless and am not sure if there's 'better' options I should take for reliability?
As a side question, if I mux a celltimes text when making the VIDEO_TS folder with Muxman would the output .mkv after running the VOB's through mkvtoolnix keep the tracks?
Thanks

[El Heggunte]

copy /b part_1.m2v + part_2.m2v full_clip.m2v

[efc1978]

Thanks, but I don't know how to use this?, I don't work much with video,
is that for command prompt?
Is the way I described going to work OK losslessly anyway?
Thanks

[manono]

Does this sound like a technically OK method to resolve the problem of the original 2 separate m2v's not working separately?

Yes, that's how I would do it - by using the 'Add' button in Muxman - with or without the audio. There's a chance you'll get some corruption if where they join isn't at a GOP boundary, but I guess it didn't happen in your case.

I think you can also join 2 M2Vs using DGIndex, although I haven't tried and I'm not at my encoding computer at the moment. Open the two together and then go 'Save Project and Demux Video'. The result should be the joined M2V files.

Is the way I described going to work OK losslessly anyway?

Yes, of course, since Muxman doesn't reencode. And neither does DGIndex.

[hech54]

Sounds like you need to start over and STOP messing with VOB files. Convert the DVD to an mkv file. There is no need for anyone to poke around inside a VIDEO_TS folder searching for the appropriate VOB file....they are all linked together in ways you do not need to understand.

[efc1978]

Does this sound like a technically OK method to resolve the problem of the original 2 separate m2v's not working separately?

Yes, that's how I would do it - by using the 'Add' button in Muxman - with or without the audio. There's a chance you'll get some corruption if where they join isn't at a GOP boundary, but I guess it didn't happen in your case.

I think you can also join 2 M2Vs using DGIndex, although I haven't tried and I'm not at my encoding computer at the moment. Open the two together and then go 'Save Project and Demux Video'. The result should be the joined M2V files.

Is the way I described going to work OK losslessly anyway?

Yes, of course, since Muxman doesn't reencode. And neither does DGIndex.

My original source is 2xDVD's, I cut out the 2 bits I wanted using DVD Shrink, I believe DVD Shrink 'no compression' setting cuts losslessly, and only on GOP boundaries? I then used PGCDemux to get the 2 m2v's which I want to be joined so when playing as .mkv it doesn't stop as it did when the first mkv ends / second mkv starts.
My main concern was whether running the VOB's (that were made to join the 2 m2v's) through mkvtoolnix was OK to end up with an .mkv, as I haven't seen much info about people putting VOB's through mkvtoolnix, but I think it's OK as it seems to all be working well...

[efc1978]

I used GSpot to get the Visual Gop Structure of both the m2v's.
Can you tell from this if everything should run without glitches?, they are the m2v's from VOB's I losslessly cut with DVDShrink.
Looks like both m2v's start on B/Bidirectional frame and both end on P/Predictive frame, but I'm not sure how good/bad that is for smooth playing without glitches!?

1) start of m2v 1
2) end of m2v 1
3) start of m2v 2
4) end of m2v 2

START of first m2v

END of first m2v

START of second m2v

END of second m2v

[manono]

No, I can't tell anything from those pictures, although I'm sure I could if I read up in GSpot what the different colors all mean. It doesn't really matter anyway, if the joined M2Vs (or DVD after authoring using Muxman) play okay. Also, cutting the VOBs as you did using DVDShrink makes the cut okay. I thought maybe you had encoded them yourself where it's possible to end on an P or B frame, and not an I frame.

[efc1978]

No, I can't tell anything from those pictures, although I'm sure I could if I read up in GSpot what the different colors all mean. It doesn't really matter anyway, if the joined M2Vs (or DVD after authoring using Muxman) play okay. Also, cutting the VOBs as you did using DVDShrink makes the cut okay. I thought maybe you had encoded them yourself where it's possible to end on an P or B frame, and not an I frame.

Yes I've always read that DVDShrink cuts only on I frames, but strangely according to GSpot green blocks are B frames, blue blocks are P frames and red blocks are I frames, which means those pictures I put in my last post are saying that both of my m2v's start with B frame and end with P frame, which seems odd considering I've always been told DVDShrink only cuts on I frames (red blocks).
*bye the way if I add a celltimes text when muxing the m2v's to VOB's in Muxman, should the tracks/chapters work once the VOB's have been output as mkv in mkvtoolnix?, or will the chapters be lost?
Thanks

[manono]

Maybe GSpot is wrong. I don't know and don't much care. If the DVD plays okay, then that's all that matters. I agree that the pictures look screwy if DVDShrink cuts on I-Frames only (as it should).

If you add chapter points when authoring in Muxman and if the chapters work when playing the DVD, then I believe the chapters will be kept when 'repackaging' the DVD as an MKV. But I don't mess with MKVToolNix much and maybe someone that knows better can confirm (or deny).

[efc1978]

OK thanks seems all will be OK then.
One final question, I made the same .mkv three times by the exact same process using the exact same files.
eg. Muxed an m2v with PCM WAV in Muxman, and then simply loaded the VOB 1 which automatically loaded VOB 1 to VOB 9 into mkvtoolnix and exported as mkv.
I then made an MD5 for each of the 3 mkv's, but all 3 MD5's were different, I expected them to be the same considering the 3 were
made of the exact same files using the exact same lossless process?, is it normal for the MD5's to be different in this case? (the mkv's were the same bytes size though).
Thanks for your help.

[jagabo]

Gspot isn't wrong. You're viewing frames in presentation order, not encoded order. The order in which frames appear in the encoded stream isn't the same as the order their supposed to be viewed. A presentation order sequence like IBBP is stored as IPBB (encoded order) because the P frame must be decode before the two B frames can be decoded. So during decoding the I frame is decoded and displayed. Then the P frame is decoded but not displayed. Then the two B frames are decoded and the first one displayed, then the second B frame is displayed, then the P frame is displayed.

Also, when viewing in encoded order open GOPs lead to the last frames of the previous GOP appearing after the I frame of the next GOP. This is because the last B frames of the prior GOP can reference the I frame of the next GOP -- and that I frame needs to be decoded before those B frames can be decoded. An editor that cuts only on I frames leaves those B frames from the prior GOP after the I frame of the first GOP. This is why cutting open GOPs often leads to a few corrupted frames at the start of the clip.

What I'm not sure about is why the first two frames of the clips are B frames. They could be the orphaned B frames from the previous GOP but all the other GOPs are closed. Or maybe the encoder always starts the first GOP with a pair of B frames.

[efc1978]

Gspot isn't wrong. You're viewing frames in presentation order, not encoded order. The order in which frames appear in the encoded stream isn't the same as the order their supposed to be viewed. A presentation order sequence like IBBP is stored as IPBB (encoded order) because the P frame must be decode before the two B frames can be decoded. So during decoding the I frame is decoded and displayed. Then the P frame is decoded but not displayed. Then the two B frames are decoded and the first one displayed, then the second B frame is displayed, then the P frame is displayed.

Also, when viewing in encoded order open GOPs lead to the last frames of the previous GOP appearing after the I frame of the next GOP. This is because the last B frames of the prior GOP can reference the I frame of the next GOP -- and that I frame needs to be decoded before those B frames can be decoded. An editor that cuts only on I frames leaves those B frames from the prior GOP after the I frame of the first GOP. This is why cutting open GOPs often leads to a few corrupted frames at the start of the clip.

What I'm not sure about is why the first two frames of the clips are B frames. They could be the orphaned B frames from the previous GOP but all the other GOPs are closed. Or maybe the encoder always starts the first GOP with a pair of B frames.

Thanks, I've looked at the original DVD's which were made 10 years ago which I received from someone before I made the cuts with DVD Shrink, and both of the original DVD's I have also start with 2 green B frames...
I have no idea but everything seems to be working fine so I won't worry about it.
Thanks

[efc1978]

The VIDEO_TS folder Muxman made by muxing 2 m2v's and a PCM WAV is 8.18GB, but when I put VTS1 to VTS 9 through mkvtoolix output as .mkv the output result is 8.04GB, I didn't expect to lose that much size in a lossless process but I guess it's normal?

Just out of curiosity, what changes could an MD5 be finding?, I demuxed the final output mkv with tsmuxer and made an MD5 of the demuxed PCM WAV and also the original PCM WAV audio, the MD5 of the demuxed PCM WAV audio from the .mkv and the original PCM WAV were different, so I then converted both WAV's to FLAC and made .ffp checksum, and they were the same..., so I guess they must be the same but MD5 says different.

I've also noticed if I put the exact same files through mkv toolnix, the output MD5 is always different, I don't understand why the exact same files through the exact same process give a different MD5 each time, but I guess it's normal for MD5 to do this?

[jagabo]

VOB can have quite a lot of overhead.

Different muxers pad WAV files differently. So an MD5 checksum of the WAV file will be different than the MD5 of the raw content.

Each MKV file is stamped with a unique 128 bit ID. The MD5 checksum includes that ID.

[efc1978]

VOB can have quite a lot of overhead.

Different muxers pad WAV files differently. So an MD5 checksum of the WAV file will be different than the MD5 of the raw content.

Each MKV file is stamped with a unique 128 bit ID. The MD5 checksum includes that ID.

Thanks.