hey guys, i made the iso file of my FFXII dvd successfully with ImgBurn (Thanks ShadowLady),

and now i'll try to compress it with Linuz plugin,

the default size is 3.78 GB, i chose the 'compress better' option, what do you guys think the size will be?

(kinda junk question, sorry)

Who knows. It depends on what kind of compression the data of the game already had and if the data of the game is easily compressed. For example video files can get almost 0 compression. Just do it and see.

Ok, the result is 3.78 GB >> 3.49 GB

---

uhh, what's the FFXII.ISO.BZ2.table file?

(10-28-2009 01:50 PM)Clouddd Wrote:  Ok, the result is 3.78 GB >> 3.49 GB

---

uhh, what's the FFXII.ISO.BZ2.table file?

Most games are already compressed to squeeze as much as they can onto the DVD, and attempting to compress a compressed file generally results in something like that

And I have absolutely no idea that that .table file is.

(10-28-2009 02:16 PM)echosierra Wrote:  

(10-28-2009 01:50 PM)Clouddd Wrote:  Ok, the result is 3.78 GB >> 3.49 GB

---

uhh, what's the FFXII.ISO.BZ2.table file?

Most games are already compressed to squeeze as much as they can onto the DVD, and attempting to compress a compressed file generally results in something like that

And I have absolutely no idea that that .table file is.

A little history first.

Today's public compression programs (with exceptions in video media) treat the whole file as 1 piece of sequential media. That means to get a few bytes in the middle of a 2GB file, you have to decompress 1GB of data, *and throw it away*. Time waster.

PCSX2 Compression routines don't try to swallow that much. We put compressed blocks of 65536 bytes to 1 megabyte (original size) back-to-back in our files.
Note I said "original size". We prefer smaller sizes come out after compression. But we can't predict what the size of each compressed block is.

Enter the .table file. It's simply a pointer to the start of each of those compressed blocks. A positional read of the .table file, followed by a positional read of the compressed file, and we have our block.

As for .BZ2, that's a compression routine. Found in use in Linux. Used by us.

Sorry, no pop quiz.

Hmmm I understand the public compression programs meeding to decompress the data making it slower, but what do you think about NTFS compression against the PCSX2 one? doesnt seem like either has much of an overhead when reading the files.

(10-28-2009 03:08 PM)efp Wrote:  

(10-28-2009 02:16 PM)echosierra Wrote:  

(10-28-2009 01:50 PM)Clouddd Wrote:  Ok, the result is 3.78 GB >> 3.49 GB

---

uhh, what's the FFXII.ISO.BZ2.table file?

Most games are already compressed to squeeze as much as they can onto the DVD, and attempting to compress a compressed file generally results in something like that

And I have absolutely no idea that that .table file is.

A little history first.

Today's public compression programs (with exceptions in video media) treat the whole file as 1 piece of sequential media. That means to get a few bytes in the middle of a 2GB file, you have to decompress 1GB of data, *and throw it away*. Time waster.

PCSX2 Compression routines don't try to swallow that much. We put compressed blocks of 65536 bytes to 1 megabyte (original size) back-to-back in our files.
Note I said "original size". We prefer smaller sizes come out after compression. But we can't predict what the size of each compressed block is.

Enter the .table file. It's simply a pointer to the start of each of those compressed blocks. A positional read of the .table file, followed by a positional read of the compressed file, and we have our block.

As for .BZ2, that's a compression routine. Found in use in Linux. Used by us.

Sorry, no pop quiz.

Do you discard compressed chunks that come out about the same size as the original and keep the uncompressed data intact? Not sure if the BZ2 format supports something like this, or if you're even following the standard that closely.

Just curious.

Some games have big dummy files (sometimes even called Dummy.dat) which get compressed to a tiny size (because they only have repetitive information). I don't remember exactly which games have them, but I sometimes have managed to compress games and save 1 Gb or more.

(10-29-2009 12:55 AM)echosierra Wrote:  Do you discard compressed chunks that come out about the same size as the original and keep the uncompressed data intact? Not sure if the BZ2 format supports something like this, or if you're even following the standard that closely.

Just curious.

Both GZIP and BZ2 support that idea (both have 'Magic' test headers just to confirm they're compressed streams instead of plain data), but EFPCDVD didn't use the idea to avoid cases where data looks just like a compressed stream... but isn't.
It's something to consider... just as soon as I get a computer that can run PCSX2 again.

wow, it's kinda hard to understand the explanation here guys, but i appreciate your help.

Quote:It's something to consider... just as soon as I get a computer that can run PCSX2 again.