The problem is that the last lz4 block before the new chunk isn't complete, the 2 byte offset is missing (offset for copying from the output buffer). In my own implementation the 2 byte offset was necessary even though the token is 0, so it caused problems. I haven't checked how you implemented lz4 in quickbms, but maybe quickbms also needs it?
I had to change my implementation, so that for the last block only the literals are copied from the block, copying from output buffer (with offset and token) is ignored. I am not sure how this can be achieved in quickbms. Closest I can get to correct output was with inserting 0 as 2 byte short (like dummy offset). It will run on test.mdl without error, but still the output is not exactly correct :
get CHUNK_SIZE long
get SIZE long
get ZSIZE long
get NAME basename
set DYN_SIZE ZSIZE
log MEMORY_FILE 0 0
for MEM_SIZE = 0 != ZSIZE
get CHUNK_ZSIZE long
log MEMORY_FILE OFFSET CHUNK_ZSIZE
put 0 short MEMORY_FILE
math DYN_SIZE + 2
math OFFSET + CHUNK_ZSIZE
next MEM_SIZE + CHUNK_ZSIZE
clog NAME 0 DYN_SIZE 20000000 MEMORY_FILE
Anyway I got this working with custom lz4 code, but just wanted to help with the bms script. I am not sure if this can be done without changing the actual lz4 code though.
if i use the -e option and just read the whole file starting at 0x90 as the zsize it extracts the large files.
Is the unpacked data correct? It might seem fine at the beginning of the file but I suspect it might become nonsense as you go further.