This topic was archived here:

https://web.archive.org/web/20230000000000fw_/https://www.zenhax.com/viewtopic.php?t=16527

CommanderVideo, posted Sun Feb 13, 2022 6:20 pm (69861)

---

This game that I'm recompressing has a bunch of .ogg files, and when I use QuickBMS to try and compress it again after successfully decompressing it, some of the .ogg files end the compression process and give me the error:

Code:

Error: there is an error with the decompression
       the returned output size is negative (-1)

This seems to be happening because the compressed file's size is larger than the original, decompressed filesize. Is there a way I can bypass this error and have QuickBMS compress the .ogg files regardless of their size?

aluigi, posted Sun Feb 13, 2022 7:34 pm (69862)

---

you can set any desired output size in the following way:
xmath NEW_SIZE "SIZE * 2"
clog NAME OFFSET SIZE NEW_SIZE

What compression algorithm are you using?
All the *_compress algorithms in quickbms automatically set a slightly bigger output size but it's possible that it's not enough with some algorithms in some conditions.

CommanderVideo, posted Sun Feb 13, 2022 10:59 pm (69864)

---

aluigi wrote:

you can set any desired output size in the following way:
xmath NEW_SIZE "SIZE * 2"
clog NAME OFFSET SIZE NEW_SIZE

What compression algorithm are you using?
All the *_compress algorithms in quickbms automatically set a slightly bigger output size but it's possible that it's not enough with some algorithms in some conditions.

I'm using the lz77wii_compress 0x10 algorithm. It usually compresses things just fine, and it only seems to have these issues when compressing .ogg files. Also, if possible, I would prefer to have QuickBMS automatically determine the compressed filesize as usual and just ignore whether it's larger or smaller than the original file, rather than setting a specific size for the compressed files to be. Sorry if I'm asking for too much ;P

aluigi, posted Mon Feb 14, 2022 9:30 pm (69889)

---

Almost all the algorithms in quickbms directly decompress the data into the output buffer, lz77wii is one of the very few in which the output buffer is dynamically enlarged to fit the decompressed data.

Usually the algorithms for recompressing data have enough space for the newly compressed data but sometimes, like in your case, that may not be enough.

CommanderVideo, posted Tue Feb 15, 2022 5:12 am (69893)

---

aluigi wrote:

Almost all the algorithms in quickbms directly decompress the data into the output buffer, lz77wii is one of the very few in which the output buffer is dynamically enlarged to fit the decompressed data.

Usually the algorithms for recompressing data have enough space for the newly compressed data but sometimes, like in your case, that may not be enough.

I see... is there a way to edit the algorithm/script so that there's enough space in that case?

aluigi, posted Tue Feb 15, 2022 9:18 am (69895)

---

I already gave you the code in my first answer.

CommanderVideo, posted Sun Feb 20, 2022 6:22 am (70027)

---

aluigi wrote:

I already gave you the code in my first answer.

Oh, my bad

Anyways, I plugged the code into my script, but the output file was 0 KB.
I had my go at figuring out the problem, but whatever it is is beyond me.
The script i used is:

Code:

get name FILENAME
get zsize asize
comtype lz77wii_compress 0x10
xmath NEW_SIZE "SIZE * 2"
clog name OFFSET SIZE NEW_SIZE

Is there anything wrong with this script?

aluigi, posted Mon Feb 21, 2022 11:26 am (70048)

---

get zsize asize
->
get size asize

CommanderVideo, posted Mon Feb 21, 2022 7:35 pm (70059)

---

aluigi wrote:

get zsize asize
->
get size asize

Thanks!