HCenc encoding problem (2nd pass)?

[Alex_ander]

Yeah, it's more safe to type parameter names directly (although there is some chance the right ones will be used, in newer versions of Decomb the first parameter in the list is field order, the next one is guide). And of course no deinterlace filter should be used afterwards since progressive is expected and at this point the script should be tested (maybe with both field order values) and adjusted (telecide either left or removed - if it doesn't return progressive).
Manono, which methods are mainly used for interlacing film to PAL? Is it something like hard pulldown? I remember doing a trick to recover inserts from progressive PAL DVD that had been interlaced into NTSC broadcast (bob-deintelaced those parts and tdecimated to 25 with cycle 12). So if here it happens to be interlaced this way, some similar approach could help.

[ecc]

As for where I get my scripts from, I've been basically modifying previous scripts of mine that have worked.

I burned the subtitles in because it had only just occurred to me to try adding subtitle=64 to the beginning of each chapter selection. Previously, I just added it to the play command but when I selected a scene from the scene selections menu (sometimes I cap the ones from the original disc, sometimes I create new ones), I'd have to turn the subs back on with my remote.

I left Tdeint in accidentally. I read up on the telecide command to see whether or not to deinterlace but forgot to delete it from the script.

How does this look?

loadplugin("c:\program files\avisynth 2.5\plugins\dgdecode.dll")
loadplugin("c:\program files\avisynth 2.5\plugins\decomb.dll")
mpeg2source("d:\one\video_ts\vts_01_1.demuxed.d2v" )
assumebff()
Telecide(0,2)
lanczos4resize(720,480)

I always check the file information in VirtualDub to see the running time and it is correct before encoding. When I open it after the encoding, that's when the running time is inflated. Strangely, the Divx decoder in Virtualdub lets me scan through the entire file (including the extra bits) while the file always freezes DGIndex (not only that but when I close the DGIndex window, its still open as a process and stays at around 99% of CPU usage until I open up the task manager and close the process).

These are the HCEncGUI settings:
profile=fast
aspect ratio=16:9
all frames
average bitrate (calculated with videocalc-1.1.)
autogop=15(as recommended for PAL though should I change it since I'm resizing it for NTSC?)
dc prec=10 (as recommended by the guide for DVDs)
CPU=auto

One question, I usually rip the files to my second harddrive and process them in there. Should I I have files on my main harddrive with the program? Could something be happening as its working across harddrives? I've noticed that with DVDAuthorGUI that processing is significantly slower if the m2v and ac3 files are in one harddrive but the final DVD folder is to be written to another drive.

[manono]

in newer versions of Decomb the first parameter in the list is field order

In the most recent version of Decomb, there's no field order parameter at all in Telecide. That's why the doc recommends adding it before Telecide.

Manono, which methods are mainly used for interlacing film to PAL?

Besides the fields being out-of-phase? Fieldblending an NTSC source when converting to PAL is probably the main way. Another way is to add a frame every second by adding a field every half second. That will result in half the frames appearing progressive and half appearing interlaced. You get a field reversal every half second. Instead of every field being repeated once, every half second a field is repeated twice. Then there are the silent films on PAL DVD which almost always appear interlaced, although they can usually be made progressive with the right use of an IVTC.

I burned the subtitles in because it had only just occurred to me to try adding subtitle=64 to the beginning of each chapter selection.

I don't understand. Are you encoding all the chapters separately? If they are all chapters from the same movie (?) that shouldn't be at all necessary. And if you're not encoding them all separately, but the subtitles stop playing after each chapter, then something's wrong with your authoring program, or how you're using it. This doesn't happen to other people. I mux using Muxman and stick the reauthored movie back into the original DVD using VobBlanker. The subs play all the way through with no problem. In fact, if I'm understanding you correctly, this is the first I've ever heard of this particular problem.

autogop=15(as recommended for PAL though should I change it since I'm resizing it for NTSC?)

Yeah, you should set it back to 12, probably.

[ecc]

If they are all chapters from the same movie (?) that shouldn't be at all necessary. And if you're not encoding them all separately, but the subtitles stop playing after each chapter, then something's wrong with your authoring program, or how you're using it. This doesn't happen to other people.

The subtitles do not stop after each chapter. If I just hit play (having stuck subtitle=64 before it in the XML file) then it play through with the subtitles. If I select a chapter from the chapter menu, then it plays from that point on but without the subtitles or any audio option other than the first one. The way the XML tips guide is set up, it supposes that you are only going to have play options in your menu such as "play English" or "play Japanese" that you would then add a subtitle command to. The chapters as listed in the chapter menu section in the XML file just say "title # chapter #" so its pretty much going to play from that point on with the first audio stream you've added. My friend's DVD player picked up the English subtitle track always on a DVD I made but that was probably because of a player setup option rather than something in the file structure.

[manono]

My friend's DVD player picked up the English subtitle track always on a DVD I made but that was probably because of a player setup option rather than something in the file structure.

Yeah, that's what I was going to suggest next. That's how I have mine set up, and I always get subs, even in the English language movies, unless the DVD has an explicit command not to play the subs (a command I can remove).

After the authoring is done, it's a fairly simple matter to turn on the subs using PGCEdit. Here's a guide:

http://download.videohelp.com/r0lZ/pgcedit/third_party/2cool/subtitles/subtitles_on_de...lt_pgcedit.htm

It looks complicated, but there's only a little that has to be understood. After doing it a couple of times, it'll take all of about 15 seconds to have the subs play automatically. Ordinarily you just add a simple precommand to the menu.

Sorry, then. I misunderstood the problem you were having.

[ecc]

Before I can do that, however, I have to find out what's adding those extra bits at the end of the file. It does not appear to be the assumefps(23.976). I'm not using Tdeint here but I had used that before on successful projects. I also used lanczos4resize without a problem. Since it already is yv12 then the convert to yv12 shouldn't have caused the problem either, right?

[manono]

Before I can do that, however, I have to find out what's adding those extra bits at the end of the file. It does not appear to be the assumefps(23.976). I'm not using Tdeint here but I had used that before on successful projects. I also used lanczos4resize without a problem. Since it already is yv12 then the convert to yv12 shouldn't have caused the problem either, right?

No, nothing in the script is causing the problem. Didn't you say that there was some kind of a problem with the D2V? If you open it in Notepad, is it complete? If you scroll to the bottom of the D2V, does it give you the film percentage? It should say 100% VIDEO.

Can you get a different DGDecode.dll and DGIndex and make a fresh D2V? Maybe first try the most recent DGMPGDec 1.5.0 beta 13 if you don't have it already. I'm fairly certain it's somehow DGIndex/DGDecode related. Without any evidence at all on which to base that hunch.

Failing that, do you have a different encoder you can use, to rule out the fault being HCEnc's?

[ecc]

The previous d2v file I did with the older DGIndex with .dll #13 says 100% video. I did another one with a newer DGIndex (.dll #16) and it looks the same though for some reason the file size is larger (the older is 773KB and the newer 798KB).

Of course, using this d2v, VirtualDub has an error saying DGIndex/DGDecode mismatch. Do I have to copy the .dll from the new DGIndex to Avisynth's plugins folder?

[ecc]

error loading Avisynth script, MPEG2Source: DGIndex/DGDecode mismatch. You are picking a version of DGDecode, possibly from your plugins directory, that does not match the version of DGIndex used t

I receive this error when I try to load the .avs script now. I copied the .dll from the version of DGIndex I used into the Avisynth plugins folder but it still gives the error. I even copied it into the HC folder. The .d2v calls it #16 but its not the same version # as the #16 already in the folder but that version actually has 16 in the name while the one from DGIndex is just called DGDecode.dll (version 1.4.9.0).

[ecc]

I ran it through FreeEnc and it encoded fine EXCEPT for the low bitrate. I entered the same average bitrate and maximum bitrate that I would've used in HCEncGUI and subtracted 1500 from the average bitrate (as per one of the threads) for the minimum bitrate and somehow wound up with a file well below single layer size: 2.91 GB instead of ~4.4 GB. What gives?

I'm guessing that's an issue with FreeEnc but I guess it shows that some setting in HCEncGUI is to blame since the avs went through FreeEnc without issue but I really do like the HC GUI since it offers a visual preview and this bitrate thing in FreeEnc is annoying. Other than 16:9, progressive, and the birates, there's not a lot of control in FreeEnc (which may or may not be a good thing).

The only thing I noticed that I forgot to mention yesterday regarding the last HCEnc encode was that the m2v file was originally 4.95 GB and I had used a bitrate calculated in vcalc for a single layer disc size but the resulting encode was also 4.95 GB. For some reason, is HC encoding the movie itself for the single layer size and then for some reason adding more video at the end to get back to the original size?

Looking back at the previous conversions I had done, they were all single layer disc size to start with. Does HCEnc have a problem reducing a video file by a certain amount?

[manono]

I receive this error when I try to load the .avs script now.

Don't use those HCEnc .dlls. Get the newest version of DGMPGDec (follow that underlined link), and make the D2V from the included DGIndex, and use the included DGDecode.dll in your script.

Does HCEnc have a problem reducing a video file by a certain amount?

No, it's all a question of bitrate. I'm sorry but I don't use HCEnc enough to be able to troubleshoot your problem. Perhaps Hank315 will come back and help out.

[ecc]

apply pulldown afterwards using DGPulldown set for its default 23.976->29.97. That'll serve the same purpose as the AssumeFPS(23.976fps) in the script.

Okay, another problem. Even though I am not satisfied with the 2.91 GB version, I plugged it into DGPulldown.exe with the 23.976 to 29.97 pulldown command and instead of slowing it down, it seems to have sped it up. I haven't watched it but the PAL running time was 1:49:07.76 but the running time after pulldown is 1:31:01.92.

What happened there?

Also, the resulting file out of FreeEnc says in the DGIndex profile that its MPEG1 even though its 720x480. I thought FreeEnc was an mpeg2 encoder.

[Alex_ander]

How do you test duration (e.g. MPC can report wrong numbers for elementary streams)? What will VDubMod say?

[manono]

I haven't watched it but the PAL running time was 1:49:07.76 but the running time after pulldown is 1:31:01.92.

How are you determining the running times? Did you actually mux the audio and the video to see if it's in synch or not?

[ecc]

The PAL running time I get from just playing the disc. The NTSC running time I get from opening the file information tab after opening the AVS in VirtualDub.

Its got to be something with DGIndex/DGDecode. I downloaded some .avi short films off the internet in PAL (720x576 at 25fps) and created Avisynth scripts with assumefps(23.976) and ran them through HCEncGUI and they all came out flawlessly (even at the low bitrates I set for the m2v to match the original size of the avi.

[manono]

The NTSC running time I get from opening the file information tab after opening the AVS in VirtualDub.

Which AVS? The one that you were going to encode in HCEnc? Or did you make a new D2V file and a new AVS after the encoding and after applying DGPulldown?

The reason I ask is that the ratio of 1:49:07.76 to 1:31:01.92 is exactly the same as that of 29.97fps to 25fps (1.1988). That is, it's the length you'd get taking your original 25fps PAL DVD and speeding it up to 29.97fps. I don't think this is just a coincidence. So, did you feed HCEnc a 29.97fps AVS? Or perhaps you encoded for 29.97fps and hadn't applied Pulldown yet? I'm getting just a little tired about having to guess the reasons for your latest screwups.

Did you solve your D2V problem? Do you now get M2Vs without the extra footage? And I'll ask again. Did you run the MPV (or M2V) through DGPulldown and actually mux it with the audio to find whether or not they're in synch?

[ecc]

When I was inserting the assumefps(23.976) into the script, I would check the file info with VirtualDub and confirm the running time when I opened the avs in HCEnc.

After I was instructed to use DGPulldown to do 23.976 to 29.976 instead of assumefps, I of course would have a pal running time before and after the initial HC encode. The NTSC running time I was expecting was that of the ac3 that I changed the framerate from 25 to 23.976.

The PAL running time was 1:49:07.76. The NTSC running time based on the ac3 file should have been 1:53:46.

So, no I did not feed a 29.97 script into HCEnc. I left the fps as 25fps with the expectation of changing it afterwards with DGPulldown from 23.976 to 29.97 as advised.

And I have not yet figured out why those extra bits end up at the end of the processed m2v. The D2V files that both DGIndexes have spat out are 100% video since they encoded it as interlaced 25 fps instead of just speeding up the progressive stream.

I also haven't been able to open the d2v file made with the newer DGIndex even using the newer .dll's file path in the script.

[manono]

I also haven't been able to open the d2v file made with the newer DGIndex even using the newer .dll's file path in the script.

You got the latest DGIndex and the latest DGDecode.dll, made a new D2V file, and can't open a basic script? I don't know. I give up and will retire from this discussion. Good luck.

[ecc]

I think I have to give it up too. I uninstalled Avisynth, HCEncGUI, and DGIndex and downloaded all of the new ones all over again and ran the file through and I still ended up with the extra bits that brought the m2v back to its original size. Once again, there is an "exception during decoding" at the end of the film itself before the extra bits so I can't chop that stuff out.

I have no idea why this doesn't work for me since HCEncGUI handled the avi files I converted nicely.

Can HCEncGUI accept avs files from video demuxed with other demultiplexer programs?

[ecc]

I encoded the avs script (with assumefps) in FreeEnc after adjusting the ini file to get a higher bitrate. The file had the right NTSC running time in GSpot at 23.976 and then after I used DGPulldown. When I plugged it into DVDAuthorGUI, I got the error "too many dropped frames -exiting". Just muxing it with Imago Muxer didn't bring up an error but it quit at approximately the same place.

Can this be fixed? I'm about ready to give up.