View Full Version : Files undersize/incomplete
CWR03
22nd July 2005, 08:23
After a power failure I suddenly have problems creating files properly with Gordian Knot. A file that should be 25 minutes may only be 8, the file size corresponds to the length of the file (i. e. should have been 25 minutes/175MB, outcome is 8 minutes/56MB). I have completely uninstalled Gordian Knot and all codecs, run error-check and scandisk, reinstalled everything with no real change except that I can randomly get a good file.
CWR03
23rd July 2005, 19:33
I have removed a (possibly) bad stick of RAM - afterward I reset all XviD codec settings to default and tried again. This time I got a complete file, but far undersize from what I had set. The amazing thing is that the file looks extremely good despite the fact it's half the size I had specified.
CWR03
24th July 2005, 08:12
I've managed to get the encode to complete, until it gets to muxing, at which point I only get a small portion of the file. If I knew how to mux the audio/video together myself I'd do it, but I have yet to get it to work.
jggimi
25th July 2005, 15:17
Looking at the first log:
I see no compressibility test, no audio stream size or overhead in the bitrate calculator, no recalculation of the video bitrate after conversion to mp3. Is that is what you intended? If so, fine, as long as you understand the limitations of this sort of encoding process (such as variable quality and variable final file size).
But then I see that only 12288 frames were found from the .avs file, while 45660 frames were expected. This means that either the .avs had a problem, or there was a problem with its source (such as a .d2v from DGIndex).
Looking at the second log:
I see the same procedures (no comp test, etc), but this time an OGM encode. This one is of a different source, and there were no apparent other issues with the source. Undersize may certainly be caused by lack of compressibility test.
Looking at the third log:
I see similar settings for this OGM encoding (no comp test, no accounting for audio, no overhead, etc) but this time allowing a recalculation of video bitrate after audio size has been established). No problem with the source seen.
---------------------------
1) To learn to use VdubMod to mux manually, or for other procedures, see:
http://www.doom9.org/vdubmod-procedures.htm
2) Compressibility testing is important, both for quality as well as size management. See http://forum.doom9.org/showthread.php?t=24584
CWR03
25th July 2005, 19:28
All interesting - I suspected the compressability test might improve on some of my encodes, though most of them (primarily movies) have come out extremely well. I will say I have never used the compressability test, and never before now had any issue at all with the file resizing, and certainly not with getting only a partial file. I'll certainly start using it - perhaps it'll help on an occasional problem I see with some strange artifacts.
I apologize for not sticking with the same settings and source for the logs - I had forgotten that I tried a few different settings, including unchecking the Recalculate, trying to figure things out on my own. I did set the audio stream size into Gordian Knot on a couple test runs and it made no difference.
I prefer OGM as it seems to have less audio overhead allowing for a higher video bitrate, and with nearly all the encodes that failed to produce a complete file, the video_Movie file and the audio file sizes added together equaled my target file size. As far as remuxing myself, the guides aren't written for the first time user (It said to open the video file and add the audio stream, but it doesn't say how to add the audio, and I screwed with it for a good two hours and never figured it out), on top of which the program would often crash or simply closed with no warning or error.
Edit: I did run the first log's corresponding encode with DGIndex's Video > Field Operation set to None, and used IVTC for the encode, had the same error in file size at least four times, and each time I reran DGIndex anew.
jggimi
25th July 2005, 20:23
XviD has a history of needing to be completely removed before re-installing -- if that's not done, symptoms can include a lack of bitrate control, causing size difficulty. It's possible a removal and clean re-install of XviD will solve your size troubles, all by itself.
As to only "partial" encoding; this is usually a different problem, that can have many different root causes. One can open an .avs with VdubMod, and scroll around through the editor, and see if all frames are available or not. If the frames are all there when using VdubMod as an editor, but then, not "there" during encoding, I would tend to think there's a problem with the codec. But if VdubMod doesn't see the frames it should be seeing, it could be the ripped VOB set, an AVS filter, even a problem with the source DVD -- there are many possibilities.
CWR03
27th July 2005, 23:35
I guess I figured it out, sort of - I clipped beginning and end by one I-frame in DGIndex and it encoded properly. It only took about 60 trial encodes of the same 22-minute file to figure out.
jggimi
28th July 2005, 14:23
I sent a private message to Don Graft -- DGIndex is his tool -- asking him to take a look at this thread.
If you would like to make a VOB fragment available that includes the bad leading GOP that you bypassed, Don would be willing to examine it.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.