Using EB script, I unpacked a .BIG archive(file0.big) that contains a file(file1.const) which i want to edit.
I edited a string with a Hex Editor, and the edited file(file1edited.const) is now the Exact size as the original one(file1.const).
But when i try to repack it inside the file0.big it says that size has changed(see picture)!
Any help would be appreciated!
This is crazy!!!!
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: This is crazy!!!!
Why did you decide to open a new topic with a similar *** title when there is already this one open?
That error is perfectly normal because what you have there is a compressed file so things like a different entropy ("aaa" against "axz") or a different implementation of the algorithm (usual problem with zlib/deflate) create a compressed file which is bigger than the space available in the archive, and so quickbms can't reinject the new data in the space of the original data.
That error is perfectly normal because what you have there is a compressed file so things like a different entropy ("aaa" against "axz") or a different implementation of the algorithm (usual problem with zlib/deflate) create a compressed file which is bigger than the space available in the archive, and so quickbms can't reinject the new data in the space of the original data.
-
- Posts: 49
- Joined: Mon Nov 07, 2016 5:49 am
Re: This is crazy!!!!
1st,sry ,i thought this was a problem that should have its own thread.
Then ,what i actually edit was a string of 19 letters that i changed with different 19 letters.
Do u think if i change-lets say 10 letters- and replace the other 9 ones with SPACES,do u think that it will decrease the file size?
Then ,what i actually edit was a string of 19 letters that i changed with different 19 letters.
Do u think if i change-lets say 10 letters- and replace the other 9 ones with SPACES,do u think that it will decrease the file size?
-
- Site Admin
- Posts: 12984
- Joined: Wed Jul 30, 2014 9:32 pm
Re: This is crazy!!!!
I have seen situations in which even doing that may not work, that's caused by the different implementation and compression level (yeah in some situations an higher level gives worst results).
Unfortunately there is no solution except "playing" with the characters/bytes till you find something that becomes smaller when compressed.
quickbms already uses the best implementations of the available compression algorithms and the highest compression settings and levels (that's why it's so slow).
Unfortunately there is no solution except "playing" with the characters/bytes till you find something that becomes smaller when compressed.
quickbms already uses the best implementations of the available compression algorithms and the highest compression settings and levels (that's why it's so slow).