Joints 1.0.2: joining files with unequal audio/video

[Efenstor]

That's cool!
Donald, do you sleep at night? Looks like you're coding without a break.
Take a break.

[Guest]

If you have clips like this they should NOT need special processing by Joints I'd like to see a sample please. If the streams are just broken binarily in an arbitrary way like VOBs, then it is an issue. You can give me just the start of such a file that was created after an automatic split.

[Turtleggjp]

I'd like to see a sample please. If the streams are just broken binarily in an arbitrary way like VOBs, then it is an issue. You can give me just the start of such a file that was created after an automatic split.

Ok. When I get home tonight I'll upload a sample. Would you like to see the end of the file before it as well?

[Guest]

Ok. When I get home tonight I'll upload a sample. Would you like to see the end of the file before it as well? That would be useful, so yes please.

[Turtleggjp]

Uploading the samples now...

I couldn't help taking a look at the data as I was cutting it, and I noticed some things that might help:

1. The first thing I noticed is that at the end of the regular clips are several null packets (PID 0x1FFF). The 2GB file also has these null packets, and the new file also begins with some null packets. I do not see any null packets at the start of any of my other clips.

2. Each new file created when I start recording has the extra 4 bytes at the front of each packet start with 0x00000000. In the case of the sample I'm uploading where the file was created after a 2GB split, the first 4 bytes are 0x31EBAFE5. The first 4 bytes in the last packet of the first file are 0x31EBA715. They are very close, and are most likely sequential.

3. The continuity counter on both the video and audio PIDs always seem to start at 0 with new clips. As far as I can tell, the continuity counter for both PIDs is continuous across the file split.

Just some food for thought while the files finish uploading...

[Guest]

The four byte field is a counter, so it should increment.

It sounds like a clean cut, so there should be no problem joining it with Joints. Why do you think it is a problem?

[Turtleggjp]

The four byte field is a counter, so it should increment.

It sounds like a clean cut, so there should be no problem joining it with Joints. Why do you think it is a problem?

My point is that it is a clean cut, and no special processing is necessary, nor should even be attempted. I remember reading over on dvinfo.net that people were experiencing a gap in the audio when importing these clips into their video editors (Adobe Premiere, Final Cut Pro, etc.). It was driving them nuts because the only way it played back perfectly was on the camcorder! Finally, some "genius" suggested just copying the two files together with "copy /b" and it was like a miracle to them! All I could think of while reading that thread was "duh!"

Anyway, here they are:

Last ~10MB of first clip: http://www.mediafire.com/?lkmjmzvtnm2

First 10MB of second clip: http://www.mediafire.com/?jnzdxkqxgjf

If you join them with this DOS Copy command:

copy /b "00002 (10MB).MTS"+"00003 (10MB).MTS" "L:\Gala test.m2ts"

the result plays nice and smooth over here.

Looking at the raw data again, the last non-null PID packet in the stream has PID 0x1100 which is the audio track. The packet does not have an adaptation field, which would suggest that the audio data did not come to a natural ending point (or the end of a PES packet). If Joints were to conclude its processing of the file at this point, it would probably not have a complete audio frame. A quick check of a typical file from my camcorder shows that the last packets for both the audio and video PIDs in the stream both have the adaptation field in them. It's my understanding that these adaptation fields in the transport packets are there to pad the packets with extra space after the PES packet has ended.

Anyway, you have the samples now, so you can draw your own conclusions...

[Guest]

Until you tell me theoretically why there should be a problem, or better yet demonstrate a problem!, when processing with Joints I can't get excited about this. Joints will simply see no correction needed at that joint.

Bear in mind that when loading all the files into DGIndex they are combined in an identical way to the DOS COPY /b way. So the only difference could be if Joints does or does not detect a correction needed at that joint.

[Turtleggjp]

Ok, I'm not 100% sure it will cause a problem, I just wanted to bring it up because I saw it as a potential problem. Those samples are from a series of 4 clips. I will run Joints on all 4 and see what the results are.

EDIT: Here is the log from Joints on these 4 clips:

00002.mts,29535,30796,0,30796
00003.mts,29310,30561,30796,30561
00004.mts,29610,30875,61357,30875
00005.mts,1485,1550,92232,1549

It looks like it worked just fine, so I guess you are correct in that this won't be a problem. I think it would be more of a problem if Joints was actually extracting the audio from the clips, but since it is just counting frames, it should be ok.

[Turtleggjp]

@neuron2. Were you able to use a version of eac3to that was able to cut the AC3 audio in Ratatouille? I just used eac3to version 3.05 on Meet the Robinsons (another seamless branching title) and was comparing the results to what Joints produced. The two programs produce almost the same result for me. Joints' file was one frame shorter than eac3to's, but that was just because Joints cut the very last audio frame, and eac3to didn't. The two files start and end in sync with each other (except for the extra frame at the end of eac3to's file), but at times they are not the same. It looks like one program cuts a frame when the other doesn't, de-syncing them, then at the next joint, the opposite happens, and they are again synced (I'm talking about the files' sync with each other, not lip sync). I'll have to do some closer examining to find out who is doing what, and even trickier to determine will be who is right and who is wrong (if that even matters, we're talking about 32ms of sync here). Anyway, I was just curious to know if the same thing was happening with Ratatouille.

[Guest]

I just used eac3to version 3.05 on Meet the Robinsons (another seamless branching title) and was comparing the results to what Joints produced. Please give me a link to that version of eac3to and tell me the exact command line you used.

[Turtleggjp]

You can get the latest version of eac3to in this thread:

http://forum.doom9.org/showthread.php?t=125966

If you want the exact version I used, I'm uploading it here:

http://www.mediafire.com/?242wzfuwnym

The command line I used is here:

"E:\Apps\EAC3to\3.05\eac3to.exe" f: 1) 1: "L:\Blu Ray\Meet the Robinsons\Chapters.txt" 2: "L:\Blu Ray\Meet the Robinsons\Robinson.mkv" 3: "L:\Blu Ray\Meet the Robinsons\Robinson.flac" 3: "L:\Blu Ray\Meet the Robinsons\Robinson (from PCM).ac3" -640 4: "L:\Blu Ray\Meet the Robinsons\Robinson.ac3" -keepDialNorm 7: "L:\Blu Ray\Meet the Robinsons\Robinson1.ac3" -keepDialNorm 8: "L:\Blu Ray\Meet the Robinsons\Robinson2.ac3" -keepDialNorm 9: "L:\Blu Ray\Meet the Robinsons\Robinson1.sup" 12: "L:\Blu Ray\Meet the Robinsons\Robinson2.sup"

May need some slight modifying for Ratatouille. I can help you with this if needed.

[Guest]

Couple questions:

1. Why is your input an MKV file? We are talking about sourcing multiple M2TS files!

2. What is that "f: 1)" thing in the options?

Please just explain your command line so I can understand what you are doing with it. I am not an eac3to user.

[Inspector.Gadget]

F: is the input - presumably a disk below AnyDVDHD or a mounted image.

The MKV file is the video output: in eac3to-land, 2: is the video track (1: is the chapters) and eac3to uses Haali's dsmux to dump the main movie video (or that of another playlist, with appropriate options) to an MKV file.

[Guest]

What is 1)?

[Inspector.Gadget]

1) I believe designates the playlist to encode. eac3to does parsing similar to BDInfo: it lists all substantial playlists on the disc, starting with the largest (usually main movie). Here, I think the 1) is redundant: both "eac3to F: 1) ..." and "eac3to F: ..." would have worked here, and I always do the latter.

[Guest]

OK, thank you, sir.

[Turtleggjp]

I think he explained it pretty well, but I'll give my explanation too:

"E:\Apps\EAC3to\3.05\eac3to.exe" f: 1) 1: "L:\Blu Ray\Meet the Robinsons\Chapters.txt" 2: "L:\Blu Ray\Meet the Robinsons\Robinson.mkv"\
3: "L:\Blu Ray\Meet the Robinsons\Robinson.flac" 3: "L:\Blu Ray\Meet the Robinsons\Robinson (from PCM).ac3" -640 \
4: "L:\Blu Ray\Meet the Robinsons\Robinson.ac3" -keepDialNorm 7: "L:\Blu Ray\Meet the Robinsons\Robinson1.ac3" \
-keepDialNorm 8: "L:\Blu Ray\Meet the Robinsons\Robinson2.ac3" -keepDialNorm 9: "L:\Blu Ray\Meet the Robinsons\Robinson1.sup" \
12: "L:\Blu Ray\Meet the Robinsons\Robinson2.sup"

My source is "f:" F is my Virtual Drive, so I am basically pointing to the root of a Blu Ray disc. Running eac3to with this alone give a list of "playlists" or "titles." These are numbered as 1), 2), 3), etc. I chose "1)", as that is the main movie in English. Running eac3to with these two commands gives a list of "items" listed as 1:, 2:, 3:, etc. Each item can be a list of chapters (usually the first one), video tracks, audio tracks, or subtitle tracks. What follows next in the command line is a list of all the items I want eac3to to extract. You asked about the MKV in the command line, that was me telling eac3to to extract the video track and mux it to a .MKV file. All you need to be concerned with for the sake of comparison with Joints are items 4:, 7:, and 8:. These are the three AC3 soundtracks. 4: is the main english soundtrack, 7: is the english commentary track, and 8: is the soundtrack only with no dialogue. When I did my comparison with Joints earlier, I only looked closer at item 4:, but the others look very close to eac3to's output as well, probably just missing the last frame.

[Guest]

I've done some testing and understand it all now.

First, if you just use "eac3to -demux" with a list of M2TS files as I did before, it does not do any gap adjustment. But if you use the track decoding syntax, e.g.:

4: "rat.ac3"

then the gap adjustment is performed and the result is equivalent to Joints.

So Joints is superfluous unless you do not have all the software packages that are needed to run EAC3TO.

Now I'm thinking that Joints should demux the audio and adjust it on the fly as EAC3TO does, eliminating the need to demux it first with DGIndex.

And then the Joints functionality should really be integrated transparently into DGIndex.

So much to do, so little time...

[laserfan]

I've done some testing and understand it all now... So much to do, so little time...Don't know how you get to it all! :eek:

Thanks for following-up with eac3to and reporting back here. I for one appreciate your (and the OP's) unflagging attention to "get everything right". :cool:

[Turtleggjp]

To me, the most ideal solution is to have programs like eac3to, DGIndex, and even tsMuxeR do what joints is doing. I think I asked for this a long time ago in the tsMuxeR thread (back when development was stalled at 1.8.4). Eac3to seems to handle Blu Rays just fine, it was just lacking support for my camcorder files. Hopefully by having Joints out there with its source code, more programs will support such things.

@neuron2, Would you be able to integrate Joints' code into your NV tools without any GPL hassles? I only ask because for AVCHD camcorders, having Joints' functionality in regular DGIndex won't do much good, as it only works on MPEG2.

[Guest]

Eac3to seems to handle Blu Rays just fine, it was just lacking support for my camcorder files. It should work fine on your files. Why do you say it doesn't.

eac3to file1.m2ts+file2.m2ts 4: "output.ac3"

Would you be able to integrate Joints' code into your NV tools without any GPL hassles? The only hassle-free way would be to get permission from the license holders for the AC3 code I used. But it would not be too hard to rewrite that part using my own coding. It just fetches frames one-by-one from the file and then either writes them or not. I already have AC3 parsing code of my own that I use for demuxing.

[Turtleggjp]

It should work fine on your files. Why do you say it doesn't.

eac3to file1.m2ts+file2.m2ts 4: "output.ac3"

I thought I did try that a while ago. I will try it again and see if it works

[Prthivi]

Neuron2, is this cut and join work on DVD that the audio not sync when demux and remux because of silence?

[Guest]

You need to cut the silence at the beginning.

Open the VOB(s) in DGIndex. Hit > to skip the black video. Then hit [ to start the project there. Continue as usual.