Making a DVD using PixeDV and Toast 6

[Frobozz]

PixeDV that is bundled with the ADS USB Instant DVD for Mac can be used with Toast 6 to make DVDs in less time than using CaptyDVD. While this is a time saver, the resulting DVD does not have any chapter markers (which is an option with CaptyDVD).

I have found the best capture setting in PixeDV to be mpeg 2, 720 X 480, 5.5 mbps video, VBR and 384 kbps audio. On my 933 mhz G4 iBook the 6.0 mbps video setting ends up with severe video/audio sync problems when authored by Toast or when demuxed. There is no such problem when the setting is 5.5 mbps or less.

After capturing the video, go to Album in PixeDV, select the video and choose MPEG Cutter. You must cut at least one second off the end of the video in order for it to work in Toast. It also sometimes works to select the file and choose Export MPEG to... which creates separate m2v and aiff files.

The next step is to drag the cut mpeg (or m2v) into the Toast video window and follow Toast's steps for burning a DVD. Toast will author the DVD without re-encoding the video. CaptyDVD always re-encodes the PixeDV mpeg and writes a new mpeg which takes a lot of time.

If anyone knows of a way to keep CaptyDVD from re-encoding the PixeDV mpeg I'd love to know about it. In the meanwhile, Toast does a fine job as long as there isn't a desire for chapter markers in the video.

[brett]

are you sure captydvd isn't just reencoding the audio? for instance, if it is taking less than an 30-45 min or so to generate a whole video_ts folder, it probably isn't reencoding the video -- even though it _does_ write a new .mpg for its own purposes.

i always use captydvd to author the video_ts folder and then burn with toast per our leader's guide.

a thought: if you don't want to cut off that last second of the .mpg in pixedv and go straight to toast, try demuxing and remuxing the ,mpg with something like jvalliant's demux:

http://homepage.mac.com/jvaillant/.cv/jvaillant/Public/demuxR5K.v03.dmg-link.dmg

and remuxing with missingmpegtools, or whatever. the same attack _may_ also solve some problems with the 6mbps sync issue you note. in the same vein, the tools for replaytv mpegs have been found to work wonders on nonstandard mpegs with seemingly other-worldly timecode issues. bottom line, if the cutting the last second thing or the 6mbps thing are hurdles you'd like to clear, there might be a way out there to clear them.

it seems like the pickiness of mpegs, mpeg editors, and mpeg dvd authorers is BOUNDLESS. one workflow simply will not work for another workflow with but a single different step or resource -- oh well, at the end of the day you can usually find one that works -- thanks for the heads-up on yours!

[AntnyMD]

Cutting off a second or two at the end shouldnt be a problem in a normal use situation. I always capture with a few seconds of trim area at the beginning and at the end. Plus if you're capturing television, you're editing out the commercials anyway, which serves the same purpose (it forces PixeDV to rewrite the MPEG stream to your hard drive with proper headers, which it doesnt seem to do well, or at all, when you're capturing on the fly).

[Frobozz]

Thanks brett and AntnyMD for helping me understand what is happening here.

CaptyDVD is probably just reencoding the audio. That process along with writing its own mpeg file takes about 40 minutes for one hour of video on my Mac. It took twice that long until I checked the "Give Priority to CPU Processing" box in CaptyDVD preferences. Still, Toast gets right to building the VIDEO_TS folder so that time used by CaptyDVD is saved.

I'm still new to this and trying to learn what happens when different settings are chosen. Without the info on this site and the Toast forum this whole endeavor would be hopeless for me.

The problem with encoding at 6.0 mbps in PixeDV is that the video is dropping frames. If I demux the mpeg using bbDEMUX the video ends several seconds per minute before the audio. What happens is the last video frame continues until the audio finishes. I'm writing the file to the internal drive on my G4 iBook. I figured this was a hardware problem with my system, but maybe it is commonplace with others.

[AntnyMD]

My best educated guess is the data cannot be written to your hard drive fast enough. I'm thinking a higher RPM hard drive would enable 6Mbps captures. However, since you can do 5.5Mbps captures just fine, the 1/2 megabit difference will be negligable.