Log in

View Full Version : Nandub filesize limit ?


Demone
10th November 2003, 14:53
I'm trying to encode LOTR-2 using sbc.
At 90-100% of divx quality the final .avi file should be 4.3GB but nundub crashes at 80-90% of its completion.
Now I know that an avi file has a 2GB limit (BUT only to work properly!), infact I planned to cut into pieces inferior to 2GB the final avi, but the problem is that nundub is unable to finish the encoding.
When I encoded LOTR-1 with virtualdub + Divx5 I finished having a 3.8GB file that was unplayable, but once cutted into 2 pieces, played fine as expected.
Do you know if there is a filesize limit of Nundub, the Divx3 codec or something else ?

Any new version of Nundub (I saw that some ppl touched the source) that solve the problem ?

Thanks

esby
10th November 2003, 15:36
What error message are you getting exactly with nandub?

I haven't really experienced encoding with such filesize.
(It's very difficult to reach that when you encode a 25 min anime episode...)

But what i can tell is that:

***
Or you are having a problem with this a filesize exceeding 2gb and nandub would not support it (cannot confirm myself).
-->If that the case,
try splitting the file in two encodes
Using for example two avs scripts ,
with trim(0,xxxxx)
and trim(xxxxx,0)

***
Or you are having a problem with a 4gb limit linked with your os...
Meaning divx5 does not crash cause it stays under this limit,
while nandub crashes cause it reaches it.
-->If that the case, splitting the encode should work too.

***
Or you are having a very specific problem at 80-90% of the encode
that make nandub crash by itself, but not necessary linked to the filesize.
-->Try splitting the encode in several parts (eg 25% ; 50% & 75%)
and try to locate the bad frame causing the errors.




For your other question about a new version of nandub:

There are 4 known 'version' of nandub besides RC2 & prior:

- an aborted rc3 which was modifying only sound encoding.
(search this forum for the old thread speaking of this version.)

- a russian 'nandub2' that is based on an exotic codec/filter
and with no source (!gpl) that i won't personnaly suggests.
(search this forum for the old thread speaking of this version.)

- a modified rc2 version by VAX that add filesplitter & stat file reader, no others modifications.
(search this forum for the old thread speaking of this version.)

- a nandub one pass by undercut that can be interresting. http://www.undercut.org/Nandub_OnePass/
You might take a look on his site for his interesting 'codec pack'...

- my nandub mod, based on rc2, labeled 'nandub ndy' with mostly some changes in the antishit algo (much better from my point of view).
http://esby.free.fr

I guess that's all we have for the different nandub version beside rc2.

I doubt they'll solve the problem you have anyway,
but you might end with a better result with some of these.


esby

Demone
10th November 2003, 15:55
Thank you very much,

I thought to trim() but I'm using the 1st pass statistic (btw aiming at 100% Q is not useful at this point I know, but it let me use the .ecf with tweaked keyframes positions from gknot).

I'm quite sure that its not a corrupted .VOB problem as a friend of mine experienced it too and solved with trim().

I know there is a 4GB limit of the fat32 (the kind I use) but actually the current crashing filesize is not even at 4GB.

*** Nandub doesnt explode only itself (often at 99% of the encoding), infact if I abort encoding (when filesize is more than 2GB) nandub crashes too and apparently is unable to close the avi that, this way, result corrupted (I know that in the avi file some informations are at the ending part) ***

I suspect that the crash is generated from the fact that nandub finished encoding and is trying to close the avi file with something but in some ways unsuccesfully.

If its of help I can send the memory dump screen of the crash.

esby
10th November 2003, 23:41
I guess the best work around solution would be to trim...
For the first trim, do two pass with a choosen bitrate
and for the second, do the same with another choosen @bitrate
the bitrates used could be equal to the original bitrate you planned to use,
but this way you could or can allow more bitrate to the first part
if you think it needs more, etc.

esby

theReal
12th November 2003, 21:57
I've encoded Lotr II on four CDs (using both original AC3 Soundtracks, German and English) and ran into problems when trying to mux the avi with the AC3 soundtracks (in VDubMod 1.5.1).

Luckily, VDubmod has an option to automatically split the file in 700MB pieces when saving, so it finally worked.

I tried different ways to get the file into one big 2800 MB file, but it wouldn't work, even when I chose Matroska instead of Avi as a filecontainer (I thought Matroska should support files >2GB, but for me it didn't work)