Are you sure you used the same compressor + settings as the one you used before?
If so, how much bigger is the result?
Is both a h<a>.diff.<b> and h<a>.<b> present after program completion, where <a> is some number, and <b> is some number?
If true, then there was a problem with cleanup midway through program execution. 'h2.2048' (an example of h<a>.<b>) is the sector store for the second image. 'h2.diff.2048' would be the diff from 'h1.2048' to 'h2.2048'. Only one of these need to be stored to be able to rebuild the second image.
Otherwise, is a h<a>.diff.<b> present after program execution?
If false, then the diff stage was found to not be beneficial. In this case, at worst the merged files should only be marginally bigger.
If true, then for at least one image, diffing was deemed beneficial before compression (the 'diff' file was at most 7/8 the size of the 'to' file). It is possible that the compressed 'diff' file is bigger than the compressed 'to' file, but given the initial size difference seems unlikely (it may be true if using freearc on a smallish set of data like gaijin did before, but again this is unlikely to scale to bigger sets/images).
In any event, please be more descriptive in your testing. Let me know the os, files used in the test, files present after execution had completed, the text output to screen during execution, etc. In my tests, the resulting size is at worst about the same as the old result. At best the file size is much smaller.