i remember 'fixing' this locally a while back, if i remember correctly it is due to
only needing one compressed block. i'll try to find my patch, but i believe it was
hacky.

this is not a common scenarios as it requires the garbage data to be removed with
gcm-tool (or a similar program) and only applies to three games that i am aware of,
the two that you mentioned and action replay

I was having the same issue, nº2543. The problem is compressing ISO's not *.gcz files.
That's what I think.

strange, I have compressed very small images fine...is this an issue that appeared kinda recently? (whenever
someone messed with that code last)
for instance, I have GB Player and Action Replay discs compressed...

nice that you already know the reason behind the issue though, lpfaint :)

my memory wasnt the best but i was close :p

caused by i%0, code has been there since at least r566
line 222 (compressing) and line 321 (decompressing) cause this issue
my patch was to simply comment out these lines, but a better fix would be to check
for num_blocks < 1000

here's a crappy quickfix with a drawback of no progress bar for the games that it affects

Index: Source/Core/DiscIO/Src/CompressedBlob.cpp¶

--- Source/Core/DiscIO/Src/CompressedBlob.cpp (revision 5384)
+++ Source/Core/DiscIO/Src/CompressedBlob.cpp (working copy)
@@ -216,10 +216,11 @@
u64 position = 0;
int num_compressed = 0;
int num_stored = 0;

• int progress_monitor = max(1, header.num_blocks / 1000);

  for (u32 i = 0; i < header.num_blocks; i++)
  {

•   if (i % (header.num_blocks / 1000) == 0)
  

•   if (i % progress_monitor == 0)
    {
    	u64 inpos = ftell(inf);
    	int ratio = 0;
  

@@ -315,10 +316,11 @@
FILE* f = fopen(outfile, "wb");
const CompressedBlobHeader &header = reader->GetHeader();
u8* buffer = new u8[header.block_size];

• int progress_monitor = max(1, header.num_blocks / 100);

  for (u64 i = 0; i < header.num_blocks; i++)
  {

•   if (i % (header.num_blocks / 100) == 0)
  

•   if (i % progress_monitor == 0)
    {
    	callback("Unpacking", (float)i / (float)header.num_blocks, arg);
    }
  

Issue 2543 has been merged into this issue.

i just realized that this only happens when you're using a modified image (read:
[poorly] pirated)
that makes me unenthusiastic.

for most instances i'm sure that you're right about this happening (poorly pirated
games), i spend (waste?) the time to throw out garbage data with gcmtool and than
compress with dolphin. when I ripped action replay the original gcm was 31Mb (ar
1.06 ntsc)

well, i honestly cannot think of a better way than checking num_blocks before the loop is entered, can you? (it is
actually an interesting logic problem, to me :) )
also, why are we using 100 as the interval for decompressing, and 1000 for compressing? the number of blocks
will be the same in each case.