tmpgenc freezes after build

[nttaylor]

Ach! TmpGenc DVDAuthor 3 spent 5 1/2 hours "building track 1" as it prepared to burn a DVD. The DVD should have been two tracks (the second track is very short) The avi source file for track 1 came correctly to an end, but then TmpGenc's progress bar just sat at 96%, and nothing else happened after that. It's still sitting there now, another several hours later.

Has anyone else seen this behavior? Do you know how to fix it? If I have to restart the program, is there a way that I can at least hang on to what it's done so far, so that I don't have to do it all over again?

I'm running XP, by the way.

with thanks,

nttaylor

[setarip_old]

Hi!

5 1/2 hours for the first track seems to indicate a problem.

Load the .AVI into GSpot and post a screen capture back here...

[nttaylor]

Thanks, setarip_old,

I've attached the GSpot screen cap.

Also, I don't really know how I should set up TmpGenc for the best quality DVD, but not go overboard either.

When I did this failed burn, I had TmpGenc's "picture quality" slider (under source->Track 1->settings->video) to 100% and "rate control mode" as "smart rendering 2 pass VBR". The settings were the same for Track 2. On both tracks I lowered the "bitrate" slider until the output would fit on a 4.7Gb disc.

Under "advanced video settings" I set "motion search precision" to "high"

Under "output" I set "target size" to "single layer DVD media (4.7Gb) size" and under the "post output process" tab I checked the box that says "write to the media disc after output completion"

All the other settings were TmpGenc defaults. I assume it's the "2 pass VBR" that made the time as long as it was, since the whole movie played through twice before it "finished" (i.e. got stuck). The high motion search precision probably slowed things down as well.

Should I not bother with some of these settings?

Thank you for all of your help.

nttaylor

[setarip_old]

You seem to have other possibly related problems:

http://forum.doom9.org/showthread.php?p=1021118#post1021118

[Guest]

Please do not crosspost, per forum rule 8. Thank you.

[setarip_old]

@nttaylor

I would speculate that the problem lies with the whopping 25.7GB filesize, including "19.7GB unneeded bytes at end of file".

Additionally, it appears to be comprised of three distinct parts that have been joined.

How did you create this .AVI?

[nttaylor]

Hi Seatrip_old,

Regarding the "related problems", I fixed them - my computer was overheating because of dusty fans.

As for how I created the .avi file: I am trying to convert a laserdisc to DVD. I played the movie from my laserdisc through a Canopus ADVC300 converter and captured the output with Windows Movie Maker. There were orginally three .avi files because each side of the laserdisc only holds about 45 minutes, so the three files were sides A & B of disc 1, plus side A of disc 2.

I then trimmed the beginnings and ends of the three files in VirtualDub and also used VirtualDub to join them together (I used "file->append .avi"). Whenever I re-saved these files in VirtualDub, I had a setting under the "video" tab set to "direct stream copy".

Why would all those extra unneeded bytes be at the end of the file when I trimmed eveything in VirtualDub before joining them? On the other hand, why would VirtualDub not save a whole new .avi with new headers? Does it have to do with the "direct stream copy" setting? I'm surprised that you were able to tell that it had been created out of three separate pieces.

thanks for your continuing help,

nttaylor

[nttaylor]

Oh, sorry I misspelled your handle, setarip_old,

nttaylor

[setarip_old]

Why would all those extra unneeded bytes be at the end of the file when I trimmed eveything in VirtualDub before joining them?I have no idea what caused this to happen, but I'd suggest you take a different approach:

Do NOT join the three trimmed .AVis. Instead, use TMPGEnc DVD Author to "Add file" for each of the three (NOT "Add new tracks"), so that TMPGEnc DVD Author will create one TITLE encompassing the three .AVIs.

Among other things, this should eliminate the huge "19.7GB unneeded bytes at end of file".

[nttaylor]

Thanks, setarip_old,

I tried it your way and everything went smoothly.

It still took 5+ hours to burn, but (I think) that's because I set motion search precision to "highest". That doesn't sound unreasonablt to you, does it (for a 2 hr. movie)?

nttaylor

[setarip_old]

Thanks, setarip_old, I tried it your way and everything went smoothly.I'm glad to hear that ;>}It still took 5+ hours to burn, but (I think) that's because I set motion search precision to "highest".That IS likely the reason. With the "standard" TMPGEnc (NOT talking about TMPGEnc DVD Author), I found that setting Motion Search Precision to highest did NOT yield obviously better results, but sure took a lot more time!

You might want to experiment with a lower setting...

[45tripp]

preferred setting for motion search with
tmpg plus is 'fast'
with tmpg xpress is 'standard'

gl

[stegre]

I think in this case the "19.7GB unneeded bytes at end of file” is a GSpot bug; I may have fixed it already, but have been so busy I haven't yet had a chance to confirm that, nor consolidate various other fixes & updates and post an updated version.

There's are, or at least were, a lot of 32-bit variables used to store file lengths, and they overflow at 4GB. It's not something that comes up a lot (except for DV), so I hadn't really noticed the problem during a lot of early testing, though I have gotten occasional reports about it.

I shouldn't say "I think" - it's definitely wrong. If GSpot's warning message in the screenshot was correct, the usable part of the file is only 25.7GB - 19.7GB = 6GB, which is much too small for a 2hr 2min DV file. That's why it also came up with much too low a bitrate for DV, in about the same proportion.

Without sound, not to mention the redundant sound in a type 2 DV, that file size should be at least (25Mbps x 122 minutes x 60 secs/min) / (8 bits/byte) which is 22GB right there. Add in the two copies of the soundtrack & misc overhead and 25.7GB is probably just about correct.

I'll be changing all file length related variable in GSpot to 64-bit shortly (that's just a programming change - not something that requires a 64-bit O/S, btw). That'll up the limit to 7,179,869,184 gigabytes which is 1,677,216 terabytes which is 16,384 petabytes which is 16 exabytes. That's 8000 times larger than Google's entire storage capacity which. of course, they use to cache the entire Internet, amongst other things.

So that should get rid of that error for a while, anyway :p

[setarip_old]

@stegre

Hi!

Just in case any of the posters to this thread don't know who you are, you might mention that you are the author of "GSpot" ;>}