have you seen the code?

[les_stockton]

Yes, I know that, but have you seen the code?
There's no reason I can think of, that another codec, providing it has similar characteristics to the ones Nandub currently supports, can't be added. I'm asking for programming help, or at least someone to point me in the right direction.
Unless someone can tell me that they know for a fact that it can't be done, I just can't accept that answer, unless some details can be given as to why.
Any help, opinions, are appreciated, and thanks for the prompt response so far.

[LigH]

Of course, in general it could be posible to add support for another codec. Nando already did that once: First Nandub was only made for DivX 3.11alpha; later he added support for one MS-MPEG4V2 version.

The main reason why it would be so hard is that Nandub patches some memory locations in the running instance of the codec; doing the same for other codecs would require that you absolutely exactly know where in the memory which encoding parameter is located; if you got it wrong and you try to patch a different memory location, you will get either undesirable results or - even more probably - crashes. And you will have to write it for one special version: another codec build, another variable location!

Much better is the way that e.g. XviD goes: XviD codecs write Nandub compatible stats files which can be optimised and saved by Gordian Knot and used by the codec for the second pass; this results in absolutely fantastic quality. DivX 4 and 5 use their own log files but practically do it in a similar way.

My personal conclusion is: As long as a codec does not provide any open interface for 2-pass VBR encoding or encoding parameter access, I'd *not* recommend to do it with brute force. But it is your time you'll spend - I'd wish you much luck. (BTW: Which codec are you interested in?)