Hacking WIT (Wiimms ISO Tools) GameCube disc support

[Wiimm]

WIT (Wiimms ISO Tools) GameCube disc support

In the thread WIA = Wii ISO Archive WiiPower ask me to support GameCube disc and we have a little discussion. Today I have released the first WIT with GameCube support. And because GameCube support is offtopic in the WIA thread, I startet a new one (this).

The important posts:

Do your tools allow to defrag the files? I know it's a complicated task, but it could improve the reading speeds on some setups.

Also i'm asking because i have a new .iso tool for GC games in mind, and that would require defrag code. Would you be interested in writing tools for GC games?

...
So now, here's what i think makes sense(yes fstfix is very close to that already...):
- Align all files by 32KB within the .iso. This is a requirement for audio streams, if an audio stream is not aligned at 32KB, then the game will most likely crash when trying to play the stream. .adp files should always be audio streams, but .trk and .snd can be audio streams too. Just to be sure align all files by 32KB and everything will work. For disc loading with NeoGamma aligning all files at least at 2KB results in a better read speed as it's only able to read sectors directly, so 32KB for everything is good for this too.
- Shrink .isos. GC .isos can have any size, so it should be possible to move all data to the beginning and just cut the .iso.(that's what i think all other shrinkers do)
- Expand .iso size for optimised reads for disc loading. There you some different options would be nice, optimised for 1/2/3 games on disc. If a single game would have a .iso with 4.37 GB and all the data is at the end, the reads are faster than a 1:1 copy.
- Optional: Check if the file is fragmented. SD-Boot requires that .isos are in one fragment.

Well extract/replace files is also nice, but the above is what i think most people will need. Well that is if you want to write this at all, i don't want to push you or something.

Loading a GC multiboot disc doesn't always work with softmods, right?

QUOTE(WiiPower @ Aug 31 2010, 11:53 AM)

PS: You don't have any relocation tool yet? Hmm, it would be nice if you could do something like this:
join game.iso foldername
And this overwrites all files in game.iso with files it finds in foldername. If there's no matching file the folder, it takes the file from the .iso. And since the sizes can be different, it relocates all files of course. I don't know if wii games have any specific requirements for alignment, so 2KB* as default and 32KB as optional alignment would sound good to me. Maybe that's why file replacment doesn't always work with current tools?

*Backup loaders that use discs use the dvd video read command, which should only be able to read sectors, so the aligment should be at least 2KB
PPS: When relocating files in wii .isos then of couse make sure the "hole" is at the beginning of the disc. And yes, i will try to think first, and then write next time.

State of the art:

• The internal ISO interface is now able to work with GameCube discs. GameCube discs are supported as a decrypted Wii image with exact one DATA partition. Because of this simulation all commands support GameCube discs without special code.
  .
• GameCube discs can be stored as PLAIN ISO and within all supported containers (WDF, WIA, CISO, WBFS).
  .
• Scrubbing support is also available but must be tested.
  .
• Extracting files from a GameCube disc works, but not composing a GameCube disc.
  .
• Please consider: The GameCube support is experimental!
  .

 

[W hat]

Multiboot, scrubbed, and multiboot discs of scrubbed ISOs don't always work on Wii softmods, to my knowledge. Can anyone confirm?

Of course, some GC games don't work at all on softmodded Wiis.

 

[WiiPower]

Multiboot, scrubbed, and multiboot discs of scrubbed ISOs don't always work on Wii softmods, to my knowledge. Can anyone confirm?

Of course, some GC games don't work at all on softmodded Wiis.

To NeoGamma's GC loader it doesn't matter if the game is a single game disc or if it's on a multi game disc(worst thing is slower reads on a multi game disc, but that would require the games to be not aligned at least at 2KB). What matters is if the .iso was shrunken. If that's not done properly(i guess most tools don't do it properly), then audio streams are not correctly aligned and the game gets an error when it's supposed to play that stream. But this only affects games that acutally have audio streams, about 90% have the audio streaming bit set, but only 10-30% really have audio streams.

 

[giantpune]

so if i have a GC iso that is shrunken using the older tools that didnt align all the stuff properly, what command would i use in wit that would cause it to copy the iso and fix the offsets?

 

[WiiPower]

so if i have a GC iso that is shrunken using the older tools that didnt align all the stuff properly, what command would i use in wit that would cause it to copy the iso and fix the offsets?

I think that's exactly the function that's not implemented yet. If you would use the old fstfix with the option t on the .iso it should be fine. I wonder why there are still tools around that do crap when there are working tools for years now. Anyways, when Wiimm finishes his stuff, it will hopefully be superior to everything and you won't need any other tool again.

 

[Wiimm]

I'm still working on that ... options and data structures already defined

 

[Wiimm]

What's about multiboot?
How the partitions are linked together?
Is there a special header?


And here are my trimming plans:

First I plan the option "--trim keylist" with three trimming types for both Wii and GC discs:[*] Move partitions within discs. Fake signing is not neccessary (Wii).
GC igore it (or not if I know how multiboot is working).
.
[*] Move sector groups (Wii) or sectors (GC) within partitions.
The aligning of files keeps stable.
Wii: Only hashes H3 and H4 are modified but neither sector hash values nor encryption.
.
[*] Move files within sectors+partitions. The option --align defines aligning values.
Wii: Decryption and encryption will slow down the trimming.
.All three trimming method can be combined. The additional keyword ALL selects all methods and the additional keyword FAST selects only the fast methods (all but files).

And now I have a question to the english native speakers: How should I call the keywords for the three methods?[*] Built the name from the containers: --trim disc,partition,sector[*] Built the name from objects to move: --trim partition,sector,fileIf all of this is implemented I will add the 2 new options --add-files and --repl-files. The options --rm-files and --zero-files are already implemented.

 

[WiiPower]

If a disc has the gamecube magic word in its disc ID and one of the following disc IDs:
COBRAM, GGCOSD, GCOPDV or RGCOSD, then NeoGamma reads the offsettable at offset 64 on the disc. Well then comes the part which i don't believe is like that:
If at offset 4 of the disc, the string "DVD9" is found then the offsets in the table are already >> 2, if not not. And the number of games is defined indirectly with the offsets, if an offset is 0, the entry before that is the last one. Oh and the offsettable has max 64 entries.

Before you write somehting in that direction, i should ask emu_kidid if i left something out or whatever, he knows a lot about gamecube modding. And i think if it's possible to make this modchip and NeoGamma compatible, then you want to do that.

I don't understand your different file move operations. Does this mean you will allow to fast expand GC discs to 4.37 GB by moving all data about 3GB(something with 32KB alignment) without changing its structure? That sounds very good to me.

 

[Wiimm]

Option 1 (move whole partitions)
This option allows to move whole partitions to the beginning or end of the disc. Partition data is not changed, fake signing not necessary. Option --disc-size overwrites the default disc size (4.7GB, needed for "--trim disc,end").

Option 2 (move whole sectors/sector groups within partitions)
GC: It moves only whole sectors (32KiB) to close holes. The advantage is that the original aligning will not changed.
Wii: It moves only whole sector groups (Wii, 2MiB) to close holes. The advantage is that the there is no need do de+encrypt the data.
GC+Wii: copying is fast because reading+writing continuous block from the hard drive.

Option 3 (complete reorganization of files)
The file are sorted and placed at new offsets. File aligning is controlled by --align.
This is slow because reading and writing is done on file level.
Wii: de+encryption and calculating of hash values is needed. This is much slower.


EDIT: MULTIBOOT:
I have loaded neogamma sources and found the multiboot source. I think thats enough info for me. If not I will bother you.

 

[giantpune]

im doing "wit COPY gamecubegame.iso newfile.wbfs" and it looks like it is working like it should, it outputs a new file that is the correct size. but it spits out an error
the filename is "BMX XXX_2.iso" it contains a space. even if i wrap my filename in single quotes, i still get this error after it has done its thing

./wit CP '/media/1TB_3GbS_2/GC games/BMX XXX_2.iso' /home/jenna/c/gcmtest.wbfs --id=GB3E51 '--name=BMX XXX' --modify=DISC -v -v -v -v -L -L --overwrite --progress

wit: Wiimms ISO Tool v1.16a r1645 x86_64 - Dirk Clemens - 2010-09-01

PROGRAM_NAMEÂÂ = wit
SEARCH_PATH[0] = /home/jenna/c/wiimms_tools/1645/bin/
SEARCH_PATH[1] = /usr/local/share/wit/
SEARCH_PATH[2] = ./

! wit: Title file not found: titles.txt
! wit: Title file not found: titles.local.txt
* wit SCRUB 1/1 ISO:/media/1TB_3GbS_2/GC games/BMX XXX_2.iso -> WBFS:/home/jenna/c/gcmtest.wbfs
!! wit: ERROR #27 [READ FILE FAILED] in ReadISO() @ src/lib-sf.c#1239
!!ÂÂÂÂÂÂRead failed [F=3,4d050000+8000]: /media/1TB_3GbS_2/GC games/BMX XXX_2.iso
!!ÂÂÂÂÂÂ-> No such file or directory
ÂÂÂÂ 1232 MiB copied in 0:02.410, 511.3 MiB/sec

DUMP and ILIST are working fine for this game. i only see the error using COPY.

 

[Wiimm]

I can't reproduce this:

# wit cp 'pool/te st/w ch.wdf' pool/a.wbfs --id=GB3E51 '--name=BMX XXX' --modify=DISC -v -v -v -v -L -L --overwrite --progress

wit: Wiimms ISO Tool v1.16a r1656M i386 - Dirk Clemens - 2010-09-03

PROGRAM_NAMEÂÂ = wit
SEARCH_PATH[0] = /usr/local/bin/
SEARCH_PATH[1] = /usr/local/share/wit/
SEARCH_PATH[2] = ./


Patching table of the disc:

ÂÂÂÂÂÂÂÂoffset .. offset endÂÂÂÂ sizeÂÂcomment
ÂÂ --------------------------------------------------------------
ÂÂÂÂÂÂÂÂÂÂÂÂ 0 ..ÂÂÂÂÂÂÂÂ 6ÂÂÂÂÂÂÂÂ 6ÂÂdisc id: RTYP01 -> GB3E51
ÂÂÂÂÂÂÂÂÂÂÂÂ20 ..ÂÂÂÂÂÂÂÂ60ÂÂÂÂÂÂÂÂ40ÂÂdisc name: BMX XXX
ÂÂÂÂÂÂÂÂ 4e000 ..ÂÂÂÂ 4e020ÂÂÂÂÂÂÂÂ20ÂÂregion: 1

Patching table of the disc:

ÂÂÂÂÂÂÂÂoffset .. offset endÂÂÂÂ sizeÂÂcomment
ÂÂ --------------------------------------------------------------
ÂÂÂÂÂÂÂÂÂÂÂÂ 0 ..ÂÂÂÂÂÂÂÂ 6ÂÂÂÂÂÂÂÂ 6ÂÂdisc id: RTYP01 -> GB3E51
ÂÂÂÂÂÂÂÂÂÂÂÂ20 ..ÂÂÂÂÂÂÂÂ60ÂÂÂÂÂÂÂÂ40ÂÂdisc name: BMX XXX
ÂÂÂÂÂÂÂÂ 4e000 ..ÂÂÂÂ 4e020ÂÂÂÂÂÂÂÂ20ÂÂregion: 1
SCAN TITLE FILE /usr/local/share/wit/titles.txt
SCAN TITLE FILE /usr/local/share/wit/titles.local.txt
* wit SCRUB 1/1 WDF:pool/te st/w ch.wdf -> WBFS:pool/a.wbfs
ÂÂÂÂÂÂ 24 MiB copied in 0:00.788, 30.7 MiB/sec

BTW: You can write "-v -v -v -v -L -L" as -vvvvLL


EDIT:
If you "make debug all" each program call creates a file named "_trace-wit.tmp". Please mail it to me if the error happens again.

 

[Wiimm]

Multiboot GC discs are recognized:

Spoiler

 # wit dump pool/gc/multiboot/mkdd+mm.iso --show intro,part,usage,dmap

Dump of file pool/gc/multiboot/mkdd+mm.iso

ÂÂReal path:ÂÂÂÂÂÂ /disk/ide1/m740av/work/pool/gc/multiboot/mkdd+mm.iso
ÂÂFile size:ÂÂÂÂÂÂÂÂae120000/hex = 2920415232 = 2785 MiB
ÂÂDisc type:ÂÂÂÂÂÂ GameCube
ÂÂID & file type:ÂÂGGCOSD, GC-ISO
ÂÂDisc name:ÂÂÂÂÂÂ GCOS MultiGame DVD (C) GCOS TEAM
ÂÂPartitions:ÂÂÂÂÂÂÂÂÂÂ 3
ÂÂDirectories:ÂÂÂÂÂÂÂÂ117
ÂÂFiles:ÂÂÂÂÂÂÂÂÂÂÂÂ 1942
ÂÂUsed ISO blocks:ÂÂ30959 * 32 KiB = 967 MiB

ÂÂGameCube partition #0, offset 0x0, size 32 KiB:
ÂÂÂÂPartition type:ÂÂ0x4f434747 ["GGCO"]
ÂÂÂÂboot.bin, id:ÂÂÂÂGGCOSD
ÂÂÂÂboot.bin, title: GCOS MultiGame DVD (C) GCOS TEAM
ÂÂÂÂRegion:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ2 [Europe]
ÂÂÂÂDirectories:ÂÂÂÂÂÂÂÂ 3
ÂÂÂÂFiles:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ 5

ÂÂGameCube partition #1, offset 0x40000, size 1389 MiB:
ÂÂÂÂPartition type:ÂÂ0x50344d47 ["GM4P"]
ÂÂÂÂboot.bin, id:ÂÂÂÂGM4P01
ÂÂÂÂboot.bin, title: Mario Kart Double Dash!
ÂÂÂÂTitle DB:ÂÂÂÂÂÂÂÂMario Kart: Double Dash!!
ÂÂÂÂRegion:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ2 [Europe]
ÂÂÂÂDirectories:ÂÂÂÂÂÂÂÂ34
ÂÂÂÂFiles:ÂÂÂÂÂÂÂÂÂÂÂÂ 328

ÂÂGameCube partition #2, offset 0x570c0000, size 388 MiB:
ÂÂÂÂPartition type:ÂÂ0x504d4447 ["GDMP"]
ÂÂÂÂboot.bin, id:ÂÂÂÂGDMP01
ÂÂÂÂboot.bin, title: Disney's Magical Mirror starring Mickey Mouse
ÂÂÂÂTitle DB:ÂÂÂÂÂÂÂÂMagical Mirror Starring Mickey Mouse
ÂÂÂÂRegion:ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ2 [Europe]
ÂÂÂÂDirectories:ÂÂÂÂÂÂÂÂ80
ÂÂÂÂFiles:ÂÂÂÂÂÂÂÂÂÂÂÂ1609


ÂÂISO Usage Map:

ÂÂÂÂÂÂÂÂÂÂÂÂ0: AAAAA...BBBBBBBB BBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBB
ÂÂÂÂÂÂ 200000: BBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBB BBBBBBBBBBBB....
ÂÂÂÂÂÂ 400000: ................ ................ ................ ................ *ÂÂ406
ÂÂÂÂ 33000000: ................ .........BBBBBBB BBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBB
ÂÂÂÂ 33200000: BBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBB BBBBBBBBBBBBBBBB *ÂÂ287
ÂÂÂÂ 57000000: BBBBBBBBBBBBBBBB BBB.....CCCCCCCC CCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCC
ÂÂÂÂ 57200000: CCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCC CCCCCCCCCCCCCCCC *ÂÂ193
ÂÂÂÂ 6f400000: CCCCCCCCCCCCCCCC CCCC


ÂÂISO Memory Map:

ÂÂÂÂÂÂÂÂÂÂunused :ÂÂ off(beg) ..ÂÂ off(end) :ÂÂÂÂÂÂsize : info
ÂÂÂÂ--------------------------------------------------------------------------------------------------
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂÂÂÂÂÂÂ0 ..ÂÂÂÂÂÂÂÂÂÂ0 :ÂÂÂÂÂÂÂÂ 0 :ÂÂP.0: main.dol
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂÂÂÂÂÂÂ0 ..ÂÂÂÂÂÂÂÂ440 :ÂÂÂÂÂÂ 440 :ÂÂP.0: boot.bin, magic=c2-33-9f-3d, id=GGCOSD
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂÂÂÂÂ440 ..ÂÂÂÂÂÂ 2440 :ÂÂÂÂÂÂ2000 :ÂÂP.0: bi2.bin
ÂÂÂÂ.!ÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂÂÂ 2440 ..ÂÂÂÂÂÂ24540 :ÂÂÂÂ 22100 :ÂÂP.0: apploader.img
ÂÂÂÂ!.ÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂÂÂ 4540 ..ÂÂÂÂÂÂ 4564 :ÂÂÂÂÂÂÂÂ24 :ÂÂP.0: fst.bin
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂÂÂ 4580 ..ÂÂÂÂÂÂ 5ee0 :ÂÂÂÂÂÂ1960 :ÂÂP.0: files, N(fst)=2
ÂÂÂÂÂÂÂÂÂÂ 1bac0 :ÂÂÂÂÂÂ40000 ..ÂÂÂÂÂÂ40440 :ÂÂÂÂÂÂ 440 : P.1: boot.bin, magic=c2-33-9f-3d, id=GM4P01
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂÂÂ40440 ..ÂÂÂÂÂÂ42440 :ÂÂÂÂÂÂ2000 : P.1: bi2.bin
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂÂÂ42440 ..ÂÂÂÂÂÂ5f664 :ÂÂÂÂ 1d224 : P.1: apploader.img
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ9c :ÂÂÂÂÂÂ5f700 ..ÂÂÂÂ 3d1900 :ÂÂÂÂ372200 : P.1: main.dol
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂÂÂ 3d1900 ..ÂÂÂÂ 3d3d83 :ÂÂÂÂÂÂ2483 : P.1: fst.bin
ÂÂÂÂÂÂÂÂ32cfbab1 :ÂÂ 330cf834 ..ÂÂ 57098000 :ÂÂ23fc87cc : P.1: files, N(fst)=355
ÂÂÂÂÂÂÂÂÂÂ 28000 :ÂÂ 570c0000 ..ÂÂ 570c0440 :ÂÂÂÂÂÂ 440 :ÂÂP.2: boot.bin, magic=c2-33-9f-3d, id=GDMP01
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂ 570c0440 ..ÂÂ 570c2440 :ÂÂÂÂÂÂ2000 :ÂÂP.2: bi2.bin
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ :ÂÂ 570c2440 ..ÂÂ 570ddfa4 :ÂÂÂÂ 1bb64 :ÂÂP.2: apploader.img
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ5c :ÂÂ 570de000 ..ÂÂ 572017e0 :ÂÂÂÂ1237e0 :ÂÂP.2: main.dol
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ20 :ÂÂ 57201800 ..ÂÂ 5720b283 :ÂÂÂÂÂÂ9a83 :ÂÂP.2: fst.bin
ÂÂÂÂÂÂÂÂÂÂÂÂ4d7d :ÂÂ 57210000 ..ÂÂ 6f49f6b8 :ÂÂ1828f6b8 :ÂÂP.2: files, N(fst)=1682
ÂÂÂÂÂÂÂÂ3ec80948 :ÂÂ ae120000 ..ÂÂ ae120000 :ÂÂÂÂÂÂÂÂ 0 : -- End of disc and file --

@WiiPower
In the GCOS readme I have found:

Since Cobra MultiGame DVD's rely on games being on 32kb aligned, some are not playable as this changed now to 128kb.

Does this mean: 32 KiB align is not enough for large files?

The GCOS tool stores a little start partition in a multiboot image. Is this necessary for loaders like NeoGamma?
Is there a free one available?

 

[WiiPower]

Well GCOS adds his loader to the 1st partition, and that is supposed to show you a menu where you select which game to run. Since that's completely incompatible with NeoGamma, NeoGamma skips that. You could create a multi game image with just the partition offsets on the beginning, and at 32K the 1st game. It would still work in NeoGamma, but i can't say what good it does to other loading methods.

Maybe you want to ask emukidid about this:
http://www.gc-forever.com/forums/viewforum.php?f=4

He knows all this stuff. Also your tools should be at least compatible to NeoGamma + the loader he is working on, his yet unnamed loader with sd gecko, and disc(on an actual gamecube) support.

 

[giantpune]

i have checked out r1661 and built make debug all. it still gives a similar error so what i posted before.

jenna@pc:~/c/wiimms_tools/1661$ '/home/jenna/c/wiimms_tools/1661/bin/debug/wit' CP '/media/1TB_3GbS_2/GC games/GC_NTSC/BMX XXX_2.iso' /home/jenna/c/gui_fork/gcmtest.wbfs --id=GB3E51 '--name=BMX XXX' --modify=DISC -vvvvLL --overwrite --progress

wit: Wiimms ISO Tool v1.16a r1661 x86_64 - Dirk Clemens - 2010-09-03

PROGRAM_NAMEÂÂ = wit
SEARCH_PATH[0] = /home/jenna/c/wiimms_tools/1661/bin/debug/
SEARCH_PATH[1] = /usr/local/share/wit/
SEARCH_PATH[2] = ./

! wit: Title file not found: titles.txt
! wit: Title file not found: titles.local.txt
* wit SCRUB 1/1 ISO:/media/1TB_3GbS_2/GC games/GC_NTSC/BMX XXX_2.iso -> WBFS:/home/jenna/c/gui_fork/gcmtest.wbfs
WBFS size = 230800000 = 9403629568
WBFS WRITE HEADER: 0 + 100
!! wit: ERROR #27 [READ FILE FAILED] in ReadISO() @ src/lib-sf.c#1239
!!ÂÂÂÂÂÂRead failed [F=4,4d050000+8000]: /media/1TB_3GbS_2/GC games/GC_NTSC/BMX XXX_2.iso
!!ÂÂÂÂÂÂ-> No such file or directory
!! wit: ERROR #39 [FATAL ERROR] in ReadISO() @ src/lib-sf.c#1242
!!ÂÂÂÂÂÂffffffffffffffff : 4d058000

here is the trace file http://www.multiupload.com/LR0O524R7Q

 

[Wiimm]

@gaintpune:
1) I don't understand you error, perhaps it is the wrong errno message.
Is your source file .../BMX XXX_2.iso smaller than 1 292 206 080 bytes?

2.) The repos contained the 1.16a release. In this minute I have committed the current state to the beta repos (untested on 64 bit, hope that all printf formats are correct)

 

[giantpune]

my game is 1 292 199 600 bytes, it was shrunken with some other tool. im not sure which one i used.

 

[Wiimm]

my game is 1 292 199 600 bytes, it was shrunken with some other tool. im not sure which one i used.

I always read whole sectors (multiple of 0x8000). Your disc size 39434.802 sectors and the program miss 0.198 sectors = 6480 bytes. hmmmm....

EDIT:
For future interpretation:

"[F=4,4d050000+8000]" means:

- "F": File based on open(), S: Stream based on fopen()
- "=4": file descriptor 4
- "4d050000" : read offset in hex
- "+8000" : read size in hex

 

[giantpune]

so if i have a whole shitload of games that are like this, i should just write a program that will go through all my games and pad them out with 0s and they will be fine in wit?

 

[Wiimm]

Or I add an option with ignore such errors.

Or calculate the end of a gc partition on file level instead on sector level.

Ignoring such errors completely is perhaps possible for gamecube discs, but never for Wii discs because decryption+hash

 

[Wiimm]

@giantpune:
I have committed a special release for your special prob in the beta repos.

It reads only until the end of image file if the data behind that point is not needed.
Say me, if it help.