MPEG2 to MPEG2: videos shorten or freeze w/ TMPGenc and CCE

[poorquoi]

I used Womble MPEG2VCR v3.14 to cut the original .VOB files into individual MPEG2 files and saved them as MPEG2 Program Stream w/o changing anything.

So now I've these MPEG2 music videos that have AC3 as audio. I demultiplexed the video and audio using tmpgenc so I got a file with .m2v and .ac3 (I chose audio channel 0x81, not 0x80).

Since each .m2v file is huge (377MB), I used tmpgenc to convert it to the same format and size so it's compliant with dvd standards (.m2v) using the option ES video only. There's no audio.

But when encoding many similar files, most video stream files freeze tmpgenc or vice versa or they're encoded incorrectly when finished. I've the settings to Motion Estimate Search (fastest) and DC Component Precision to 8bits.

The video stream should usually take about 20-30 minutes to finish since they're about 5-6minutes in length. But the ones that freeze get stuck at some percent for hours. I've to End Task TMPGenc.

The encoded video stream that are finished (.m2v) are much shorter (length) than the original .m2v when I play completely w/o fast forwarding w/ my PowerDVD v5.0 or any MPEG2 capable program including Womble MPEG2VCR v3.14.

So when I try to multiplex the audio back (already converted to MPEG 1 Audio Layer 2 at 256kpbs @ 48K Hz using BeSweet GUI using tooLame 0.2k), the video usually end one or two mintues before the audio. I even tested with the original .ac3 audio files, but same result.

But when I remultiplex the audio (.mp2 or original .ac3) with the ORIGINAL .m2v video stream, I don't have any problem except for the huge size.

CCE 2.50 also has the same length problem when I converted a .m2v to .avi. The .avi plays w/ correct length, but the encoded .mpv is short.

What can be the problem? My computer is not overclocked and the memory settings are pretty relaxed. I've PC2100 256MB of RAM with Althon XP +1800. Windows XP Por. I also checked all the video streams for errors with VirtualDubMob (capable of opening MPEG2 and AC3), but none of them have any error or bad frames.

[willy_annand]

Try this quick test to see if it is MPEG-VCR or your Encoder.

Take one of the files, load it into VirtualDub, save it as an AVI, use Huffy codec to save space (Huffy is lossless so it will not effect the quality).

Then load the AVI file into TMPGEnc, use the "Normal" Motion Search Precision, the encode should take just slightly longer than realtime. (On my Pentium 4 2.6GHZ it take 75 minutes to encode a 60 minute clip).

Test the output to see if it works. If it does, then it is your MPEG-VCR output that is at fault, VDub will correct it on loading and saves correctly in Huffy.

If you are going to be editing anything, it is a good idea to capture/rip to AVI. It will save you lots of time and you will not get any quality loss.

BTW, 377MB is not big at all. Quality MPEG video is about 2.3GB per hour.

[poorquoi]

I tried your suggestion and that seems to solve the freezing and the incorrect length. Since convertering to .avi file using Huffy results in 3-4Gig per 5-7 minutes, I can't do a batch of them (15 files).

What I do now is using VirtualDubMod as frameserver. However, I can't seem to find a "batch" mode for frameserving. So I had to open 15 instances of VirtualDubMod each serving one file. Now I can do all of them in sequence using TMPGenc "Batch Encode".

So does this mean Womble MPEG2VCR v3.14 seems to the problem? I did manage to get two of the many files encoded correctly w/o frameserving or converting to .avi format. I've yet to find a .vob cutter and joiner that loads each of the .vob as one.

As for the 377MB isn't too big. That's correct. I've a 80gig hd, but I'll be using a 20gig hd as storage to put in my standalone dvd player.

[willy_annand]

I have had problems with MPEG-VCR.

it seems that software players can handle MPEG-VCR output but stand alone players are not as forgiving. My guess is that software players have builtin error correcting routines while stand alone players expect 100% compliant streams.