You can definitely join existing MPEG files. MPEG2VCR will do this more effectively than TMPGEnc. See this link for the demo download:

MPEG2VCR

I render all to mpg in Vegas, putting in chapter markers and including them in the rendered file. Then in DVDA, I make my initial menu button the "play all" button and create a scene selection menu which is automated because the chapeter points are already there.

I render all to mpg in Vegas, putting in chapter markers and including them in the rendered file.

Yep, that is definitely the way to do it. Unfortunately, it is not the practical way to do it. In many cases, you want to render a project in small chuncks. Or, at times you need to use MPEG and AC3 files created several months ago that are archived on the server somewhere which you now want to combine with newer MPEG/AC3 files. Most programming and other computer experience says that you should break projects up into small chunks and tackle each one separately. DVDA doesn't (yet) allow it. Fortunately, Sony would have to be deaf, dumb, and blind not to have figured out that this shortcoming needs to be fixed, so I am 100% confident (without actually knowing anything for sure) that it will be fixed in the next release.

johnmeyer, thanks for your comments.

Since my projects are usually short, rendering the whole deal is not an issue for me.

As to the end-actions issue, I agree that it's simply astounding that DVDA doesn't have that capability. I'm not sure, however, that having end actions would allow you to render chunk by chunk and combine in DVDA with acceptable results. There was a lot of discusssion on DVD Workshop boards (back in DVD WS 1.2 & 1.3 days) about little "jumps" between segments that were imported and set to play back to back. (I'm guessing it was like the blip at the layer change on DVD-9 disks.) There were comments that this was not a software bug, but was unavoidable because of the DVD spec or something like that. The proposed solution was to fade to black at the transitions.

Now, I don't know if the statement that the "jump" is unavoidable is correct or not, and I'd like to hear from people who have used end actions to link segments in other authoring apps.

Nolo

I'm not sure, however, that having end actions would allow you to render chunk by chunk and combine in DVDA with acceptable results. There was a lot of discusssion on DVD Workshop boards (back in DVD WS 1.2 & 1.3 days) about little "jumps" between segments that were imported and set to play back to back.

The little "jumps" would NOT be noticable IF you fade out and fade in each clip. Just make sure you go to black between each clip and you won't see the "jump" happening.

So jetdv, are the little "jumps" unavoidable irrespective of authoring app?

The "jumps" are caused by the fact that the simple-minded way to deal with individual MPEG files imported into a project is to simply create a separate titleset (VOB files) for each one. When one titleset it finished, the player looks to the IFO files for instructions on where to play next. Apparently, the way DVDs are designed, this jump takes time (probably because the data is recorded in a spiral, and going to a different titleset requires a lot of head movement to go to the directory and then traverse the spiral to get to the next piece of video).

The "pro" way to deal with this would be to merge the individual files together "behind your back." DVDA could simply create a single MPEG file from the individual files, using the same technology found in the semi-free TMPGEnc and the low-end merge-cut program from Womble (MPEG2VCR). The chapter stops and menu items would then work on this one file. Play would continue from where one MPEG file ended and the next began, without interruption because all the video and audio would now be in one file.

Given that Sony has all the MPEG tools and source code already in place for Vegas, DVDA, etc., the merging operation would be a trivial library to create. I sure hope they implement this in DVDA 2.x. It is a necessary piece of "plumbing" and would be the "right" way to handle multiple MPEG files where you want them to play continuously from one file to the next.

johnmeyer, if you "rip" a commercial DVD, you get a bunch of sequentially numbered VOBs on your hard drive (as well as the IFO and some other files). Is that separation of the video stream into separate files an artifact of the ripping process, or are there VOBs on the disk that are separate data files and the disk been set up so that the VOBs are somehow played back seamlessly?

The VOBs from the same titleset are designed to be played one after the other. They all have the same name, with the last digit being different (e.g., Vts_01_1.vob, Vts_01_2.vob, etc.). Now that you mention it, the "jump" happens even when the files are on the computer, and the disk on the computer can move to a new file in a few milliseconds. Therefore, the "jump" must be due to the logic used to go to a new titleset.

The one thing I know for sure is that if you combine the MPEG files (and AC3 files) together prior to authoring, then everything will play without interruption (an obvious statement, because that is what happens when you add chapter points in DVDA).

I think the jump is an artifact associated with moving from the title set, back to the video manager and then to the new title set. I have a project built with DVD Lab which puts all of the video clips into the same title set, and I don't recall seeing a jump when moving between clips.

The organization is a toss-up for me; it's easier to navigate around within a title set, so from that perspective I like how DVD Lab lays things out, but it's hard to find things unless you keep careful track of how you added things to the project. With DVDA it's a little easier to find things, but a PITA to navigate between title sets since you always have to go back to the video manager.

John,
I am so glad this forum has a DVD geek like you in it... I know the SOFO guys are not dull tacks, but it's great to have someone like you to educate us and help keep Sony honest.
I use the term "geek" in the cool and admirable sense, of course.
Nate