DISCLAIMER: Sorry for my bad english 
Someone recently asked me: how can I reduce the size of GC dumps while keeping an ISO extension (no rvz)?
I immediately sent him "DMToolbox", a well known tool that I personally use. "Just use 32k align and you'll have no issues!"
But then I got told there was a game that DMToolbox wouldn't optimize, only the RAW setting was available.
A thought couldn't escape my mind - "Why disallow it? What if the rebuilding process fucks something up? Do GC games use direct sector like PS1/PS2?"
Well, I still do not know if there are GC games that ignore FST table. But we have an answer to the other questions: a resounding yep, it can fuck them up.
Here are my findings:
testing method (w/ redump verified source files): Wiimms'wit extract
files test = rebuild "nfs hot pursuit 2" then compare folders (thanks gc-forever user Andross89 for finding that the game gets damaged)
alignment test = rebuild iso, like a demo or animal crossing, that contains .tgc (are they aligned to 32k?) If not, FAIL.
untested means that, after seeing that the files folder was different to an OG dump, I didn't care enough to check wit's align_files.txt
--- By the way, boot.bin edits made by every tool are simple bootfile & fstfile offsets, nothing weird so don't be alarmed ---
alignment = preserved (100% match) or "acceptable" changes
(i.e. an increase, aligned to the next power of 2, in non-audio/tcg files, not a decrease; if an expert wants to chime in and says why *technically* such an increase is bad, feel free to do so... games ran without issues on my side...)
Certain games (F-Zero GX) with little to no spare room for shrinking will be rebuilt as LARGER instead, since the original doesn't use 32k for all files.
TL;DR
Always use discex -c / GameCubeISOCompress for shrinking clean isos as no other tool tries to preserve alignment.
OR
If you need to do a forced align to 32k (a crusty old scene rip on your HDD, perhaps?), DO NOT USE FSTFIX T OR DISCEX -A!
Use GCIT, as it's the only tool that doesn't ruin certain game files.
edit: I wasted a few hours getting to the bottom as to why oversized isos outputted by GCIT would crash Nintendont.
Why nintendont CRASHES instead of showing this read error eludes me, but ok.
Hmm... Let's pipe GCIT's output - F-Zero GX align 32k ISO - into GamecubeISOCompress, and we get an oversize ISO of around the same size of GCIT's (1.42gb)
And guess what?
This one works. I even tested it back w/ Nintendont and it doesn't crash any longer.
Funny that this is the solution, since iirc with Dios Mios you would do a similar thing - fstfix t and then discex (or was it the other way around?)
---
My take? Just keep the output of cleanrip and buy a larger HDD.
"Shrinking" an ISO is "rebuilding it", not "trimming" in the cart scene sense:
(Example) it's more like if you drop a nds-rom into crystaltile/dslazy instead of using ndstokyotrim.
PS. Seems like Nintendont doesn't support oversize ISOs, since PSO + GCIT forced 32k (a file larger than 1.35gb) works on C!Devolution while it crashes Nintendont. (Discex works on both.) | see clarification in main post
Someone recently asked me: how can I reduce the size of GC dumps while keeping an ISO extension (no rvz)?
I immediately sent him "DMToolbox", a well known tool that I personally use. "Just use 32k align and you'll have no issues!"
But then I got told there was a game that DMToolbox wouldn't optimize, only the RAW setting was available.
A thought couldn't escape my mind - "Why disallow it? What if the rebuilding process fucks something up? Do GC games use direct sector like PS1/PS2?"
Well, I still do not know if there are GC games that ignore FST table. But we have an answer to the other questions: a resounding yep, it can fuck them up.
Here are my findings:
testing method (w/ redump verified source files): Wiimms'wit extract
files test = rebuild "nfs hot pursuit 2" then compare folders (thanks gc-forever user Andross89 for finding that the game gets damaged)
alignment test = rebuild iso, like a demo or animal crossing, that contains .tgc (are they aligned to 32k?) If not, FAIL.
untested means that, after seeing that the files folder was different to an OG dump, I didn't care enough to check wit's align_files.txt
--- By the way, boot.bin edits made by every tool are simple bootfile & fstfile offsets, nothing weird so don't be alarmed ---
- Crediar's discex -c = Fix94's GameCubeISOcompress = Crediar's dmtoolbox optimize auto (only fst.bin edited)
alignment = preserved (100% match) or "acceptable" changes
(i.e. an increase, aligned to the next power of 2, in non-audio/tcg files, not a decrease; if an expert wants to chime in and says why *technically* such an increase is bad, feel free to do so... games ran without issues on my side...)
- Crediar's discex -a = Fix94's GameCubeISOcompress -a = Crediar's dmtoolbox optimize 32k (breaks game files!!!)
- Crediar's dmtoolbox optimize 64k (breaks game files!!!)
- Bsv798's GCRebuilder (breaks game files!!!)
- SlideR/LOONYCUBE's fstfix (sometimes trims end of apploader.img, boot.bin & fst.bin edited)
- SlideR/LOONYCUBE's fstfix t (breaks game files!!!)
- Fig2k4's gcit [save iso->trimmed, same md5 as gcit extract->discex] (boot.bin & fst.bin edited)
Certain games (F-Zero GX) with little to no spare room for shrinking will be rebuilt as LARGER instead, since the original doesn't use 32k for all files.
- Ghoom's gcmutility(only fst.bin edited)
- Ackmed's gcshrink (only fst.bin edited)
- Dsbomb's gcm-tool (only fst.bin edited)
TL;DR
Always use discex -c / GameCubeISOCompress for shrinking clean isos as no other tool tries to preserve alignment.
OR
If you need to do a forced align to 32k (a crusty old scene rip on your HDD, perhaps?), DO NOT USE FSTFIX T OR DISCEX -A!
Use GCIT, as it's the only tool that doesn't ruin certain game files.
edit: I wasted a few hours getting to the bottom as to why oversized isos outputted by GCIT would crash Nintendont.
- ISOs shrinked through GamecubeISOCompress would not crash
- ISOs passed through GCIT force align 32k, that have a size of less than 1.35gb, such as "Crash Bandicoot Wrath of Cortex" do not crash.
Why nintendont CRASHES instead of showing this read error eludes me, but ok.
Hmm... Let's pipe GCIT's output - F-Zero GX align 32k ISO - into GamecubeISOCompress, and we get an oversize ISO of around the same size of GCIT's (1.42gb)
And guess what?
This one works. I even tested it back w/ Nintendont and it doesn't crash any longer.
Funny that this is the solution, since iirc with Dios Mios you would do a similar thing - fstfix t and then discex (or was it the other way around?
)---
My take? Just keep the output of cleanrip and buy a larger HDD.
"Shrinking" an ISO is "rebuilding it", not "trimming" in the cart scene sense:
(Example) it's more like if you drop a nds-rom into crystaltile/dslazy instead of using ndstokyotrim.
PS. Seems like
Last edited by Fabax01,
