Hacking wwt+wit: Wiimms WBFS+ISO Tools

[PsyBlade]

did you try to escape the % sign?

 

[Wiimm]

Only some short hints:
If extracting from WBFS the user have to say the objects to extract. "wwt extract" expects a list of ids OR * or + for all discs. The * must be escaped ( \* or '*' ) because it is a shell meta character. Using the plussign is easier.

@KiiNG
Do you working with linux or windows or max? Windows uses the % character to access variables. It is easier to change the wit escape character to $ with -E$ and use something like $T[$I].wbfs.
BTW: "%Y2 is the same as "%T [%I]" and "%X" the same as "%T [%I].%E" where %E is "wbfs" or "iso" or "wdf" or ...

To move (or access) all ISO files of a directory you can just say "/media/F999-3192/". wit+wwt will then search the directory for images. "--recurse dir" will make a recursive search.

If using the --test option wit will tell you what it would do.

 

[Hooya]

I am running linux. I cannot figure out how to use the variable characters with this program! I'm trying simply rename the files. What should the syntax be in Linux to rename using the %Y variable, I want them all in wbfs files (although one got switched to .iso during my attempts to rename these things). I don't know what psyblade means by "escape the % sign"... Do I have to tell the program that % is a variable in some way? I always get things that look like this:

$ wit move -E$ /media/F999-3192/*.wbfs $Y2.wbfs
*****ÂÂwit: Wiimms ISO Tool v1.16a r1645 x86_64 - Dirk Clemens - 2010-09-01ÂÂ*****
!! wit: ERROR #24 [CAN'T CREATE FILE] in exec_move() @ src/wit.c#1723
!!ÂÂÂÂÂÂFile already exists: .wbfs

$ wit move /media/F999-3192/*.wbfs "%Y".wbfs --progress
*****ÂÂwit: Wiimms ISO Tool v1.16a r1645 x86_64 - Dirk Clemens - 2010-09-01ÂÂ*****
!! wit: ERROR #24 [CAN'T CREATE FILE] in exec_move() @ src/wit.c#1723
!!ÂÂÂÂÂÂFile already exists: [].wbfs

What am I not doing right? I could have renamed them manually by now.

 

[Hooya]

Is there another tool I can use? This is too frustrating. Typing in the commands as you guys are putting them the program doesn't work. Sometimes the output is simply this:

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

Then back to $. No other output at all.

Nothing I've tried using things like %T, %X, '%T', \%T, or whatever work at all, it always tries to name the files "[].wbfs".

Is there something that I should be doing or something that I need to install? Is there an issue with 64 bit? Is there a problem with my syntax?

$ wit move -r /media/F999-3192/*.wbfs -D '%X' -v --test

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

- WOULD MoveÂÂ 1/116 ISO:/media/F999-3192/R5WEA4.wbfs -> [].iso
!! wit: ERROR #24 [CAN'T CREATE FILE] in exec_move() @ src/wit.c#1725
!!ÂÂÂÂÂÂFile already created: [].iso

$ wit move /media/F999-3192/*.wbfs --titles /documents/Downloads/Wii/Disk\ Tools/wit-v1.16a-r1645-x86_64/lib/titles.txt -d /media/F999-3192/\%Y.wbfs --progress --test
*****ÂÂwit: Wiimms ISO Tool v1.16a r1645 x86_64 - Dirk Clemens - 2010-09-01ÂÂ*****
- WOULD MoveÂÂ 1/116 ISO:/media/F999-3192/R5WEA4.wbfs -> /media/F999-3192/[].wbfs
!! wit: ERROR #24 [CAN'T CREATE FILE] in exec_move() @ src/wit.c#1725
!!ÂÂÂÂÂÂFile already created: /media/F999-3192/[].wbfs

I can post more examples. It's all the same output no matter what I try.

 

[Wiimm]

Don't use the dollar sign under linux because it is similar to % in windows: It is a variable access sign. I can not test this before to tomorrow in the evening. But If you use --test move will show what it plan to do.

EDIT
One question about the source files:
Are the source files WBFS files which contains exactly 1 disc?

What is the output of:

wwt ll /media/F999-3192/*.wbfs

It's only an idea that there are Multi-disc containers.

 

[Hooya]

Don't use the dollar sign under linux because it is similar to % in windows: It is a variable access sign. I can not test this before to tomorrow in the evening. But If you use --test move will show what it plan to do.

EDIT
One question about the source files:
Are the source files WBFS files which contains exactly 1 disc?

What is the output of:

wwt ll /media/F999-3192/*.wbfs

ID6ÂÂÂÂ MiB Reg. 0/215 discs (0 GiB)
-----------------------------------------------------------
-----------------------------------------------------------
Total: 0/215 discs, 0 MiB ~ 0 GiB used, 0 MiB ~ 0 GiB free.

Grand total: 116 WBFS, 0/24940 discs, 0 GiB used, 0 GiB free.

with that first part repeating a LOT of times. These files came from your extract tool.



You can see above what it's trying to do. If I just make it this:

CODE$ wit move /media/F999-3192/*.wbfs --title /documents/Downloads/Wii/Disk\ Tools/wit-v1.16a-r1645-x86_64/lib/titles.txt /media/F999-3192/Y.wbfs --test
*****ÂÂwit: Wiimms ISO Tool v1.16a r1645 x86_64 - Dirk Clemens - 2010-09-01ÂÂ*****
!! wit: ERROR #24 [CAN'T CREATE FILE] in exec_move() @ src/wit.c#1723
!!ÂÂÂÂÂÂFile already exists: /media/F999-3192/Y.wbfs
!! wit: ERROR #24 [CAN'T CREATE FILE] in exec_move() @ src/wit.c#1723
!!ÂÂÂÂÂÂFile already exists: /media/F999-3192/Y.wbfs

And so on for every other file. If I'm not supposed to use %Y or $Y what am I supposed to use!? 'Y' offers the same thing. '%Y' as well.

There are really just two commands I want to run:
1. I want to rename all the wbfs files in one directory (already on my FAT32 partition) to their Title and ID6. What is the Exact command for that under Linux?
2. I want to rename using the same convention and split into 3G chunks all the wbfs files currently on my mule drive (EXT3 filesystem), and have the destination the FAT32 partition.

A third and final step I'd also like to be able to do is:
Take the USB loader incompatible games (like MP:Trilogy) and extract them for use under UNEEK+DI on the same FAT32 partition. I would obviously do this one at a time, but that's not a big deal since there are only four or five of them.

 

[KiiNG]

@KiiNG
Do you working with linux or windows or max? Windows uses the % character to access variables. It is easier to change the wit escape character to $ with -E$ and use something like $T[$I].wbfs.
BTW: "%Y2 is the same as "%T [%I]" and "%X" the same as "%T [%I].%E" where %E is "wbfs" or "iso" or "wdf" or ...

I triple boot, but mainly run OSX for wit+wwt. I'm just a bit orderly with files so was hoping for a simple way of renaming the .wbf1 files accordingly with %X. Nothing direly pressing.

 

[Hooya]

I think the extract killed all my games. They show up in the list on USB loaders (the ones that I have that aren't over 4G, since I can't split any of the larger ones yet) but none of them play. Is there a way to fix them? Am I just not using them correctly in the USB loader? Tried with WiiFlow, Configurable and USB Loader GX, using different game load CIOS, and tested several games I know worked.

Not a happy camper right now....

 

[myron0815]

Hi,
have some weird issue i've never seen before.
I use WIT to rename & scrub (ntfs sparse) my isos.
Therefore, i copy them to a /tmp dir.

If i execute these 2 commands in the windows console (within the /tmp dir), everything works fine.

\wit\wit.exe move *.iso -d ./%X -T titles-de.txt
\wit\wit.exe scrub *.iso

So i tried to make a .bat file out of them. (/me lazy
Unfortunately, this does not work?!?
The first iso gets renamed to X, and the second one complaints then, that X is already existing.

Any hint/glue, why this does not work with WIT?!
calling the .bat from the console does not work either?!

 

[Hooya]

Well, those files extracted from the WBFS partition were all junk. I'm starting over. Luckily I don't have a bandwidth cap and I have plenty of burned disks and am starting to rebuild my collection. The program seems to be working fine for copying directly from the DVD drive to .wbfs files in the right naming scheme.

One question, when I download some images, they come in rar packs, rar, r00, r01, etc. I notice you say, in your list of features:
"and can read from pipes (indirect RAR/ZIP/7Z support)"
Does that mean I can have the program extract the iso image to a .wbfs file directly? Or do I need to extract all the items first and then have the program convert and scrub?

 

[Wiimm]

Sorry, I have a bad cold and can't support

 

[PsyBlade]

Does that mean I can have the program extract the iso image to a .wbfs file directly? Or do I need to extract all the items first and then have the program convert and scrub?

you still need to use two programs (eg zip & wit) but zips output is direktly written to wit (not HDD)
see http://en.wikipedia.org/wiki/Pipeline_%28Unix%29

 

[Hooya]

OK, constructing that in my head is too complicated. Easier to just extract all the rar files, then run the wit command. Takes longer, but I can just let it run while I do other things.

 

[Wiimm]

Yesterday I have tried to post a similar text. But then GBAtemp crashes and my post is lost. Next try .....

There are really just two commands I want to run:
1. I want to rename all the wbfs files in one directory (already on my FAT32 partition) to their Title and ID6. What is the Exact command for that under Linux?Use the following command, but it have problems with splitted files. Also wbfs files with null or two or more discs are renamed wrong. I'm trying to fix both it today:

# unix:
wit move *.wbfs %X --test

# windows:
wit move --esc $ *.wbfs $X --test

# confirm the output and remove --test for action

2. I want to rename using the same convention and split into 3G chunks all the wbfs files currently on my mule drive (EXT3 filesystem), and have the destination the FAT32 partition.For this you must copying it

# unix:
wit copy *.wbfs --dest /path/to/%X --split-size=3G --test

# windows:
wit move --esc $ *.wbfs G:/path/to/%X --split-size=3G --test

# confirm the output and remove --test for action

# split size 3G means 3*1024*1024*1024
# split size 3g means 3*1004*1000*1000
# I split always at 4g = 4000000000 = nice round number

A third and final step I'd also like to be able to do is:
Take the USB loader incompatible games (like MP:Trilogy) and extract them for use under UNEEK+DI on the same FAT32 partition. I would obviously do this one at a time, but that's not a big deal since there are only four or five of them.

# unix:
wit extract *.wbfs --dest /path/to/%X/ --sneek --test

# windows:
wit extract --esc $ *.wbfs --dest /path/to/$X/ --sneek --test

# confirm the output and remove --test for action

I think the extract killed all my games.Really? Have you checked your WBFS partition before? Does WIT it? If yes, please tell me the used release and the exact commands for tests.e

Hi,
have some weird issue i've never seen before.
I use WIT to rename & scrub (ntfs sparse) my isos.
Therefore, i copy them to a /tmp dir.

If i execute these 2 commands in the windows console (within the /tmp dir), everything works fine.
CODE

\wit\wit.exe move *.iso -d ./%X -T titles-de.txt
\wit\wit.exe scrub *.iso

So i tried to make a .bat file out of them. (/me lazy

Unfortunately, this does not work?!?

The problem is the % sign. Under windows it is a meta character to access variables like %1 or %var%. For windows try: --esc=$ (or short form -E$) and replace all % signs by $:
CODE

\wit\wit.exe move *.iso -E$ -d ./$X -T titles-de.txt

Have I forgotten important questions?

 

[EtherealX]

I'm tired of using Windows VM to transfer games to my drive, but can't for the life of me get WWT to work for me. Sorry if this has been explained before. I have a fat32 drive with its wbfs folder in place. What's the proper command for simply (and properly) adding games to my wbfs folder? I'm on OSX running the latest binaries.

Here's basically what I've tried to do..

null:~ null$ wwt analyze
ScanDevForPartitions(sd)
- part found: /dev/sdt
ScanDevForPartitions(rdisk)
- part found: /dev/rdisk0
- part found: /dev/rdisk0s1
- part found: /dev/rdisk0s4
- part found: /dev/rdisk0s2
- part found: /dev/rdisk0s5
- part found: /dev/rdisk0s3
- part found: /dev/rdisk1
- part found: /dev/rdisk1s1

ANALYZE /dev/sdt

ANALYZE /dev/rdisk0

ANALYZE /dev/rdisk0s1

ANALYZE /dev/rdisk0s4

ANALYZE /dev/rdisk0s2

ANALYZE /dev/rdisk0s5

ANALYZE /dev/rdisk0s3

ANALYZE /dev/rdisk1

ANALYZE /dev/rdisk1s1

null:~ null$

..is it suppose to show me something here? Anyways, /dev/rdisk1 is the drive in question. Skimming through the thread I saw this command mentioned.. so..

null:~ null$ wwt check --auto
ScanDevForPartitions(sd)
- part found: /dev/sdt
ScanDevForPartitions(rdisk)
- part found: /dev/rdisk0
- part found: /dev/rdisk0s1
- part found: /dev/rdisk0s4
- part found: /dev/rdisk0s2
- part found: /dev/rdisk0s5
- part found: /dev/rdisk0s3
- part found: /dev/rdisk1
- part found: /dev/rdisk1s1
*****ÂÂwwt: Wiimms WBFS Tool v1.16a r1645 mac - Dirk Clemens - 2010-09-01ÂÂ*****

!! wwt: ERROR #15 [NO WBFS FOUND] in AnalyzePartitions() @ src/wbfs-interface.c#381
!!ÂÂÂÂÂÂno WBFS partitions found -> abort
null:~ null$

Now if I try to do anything (copy, check, verify, move, etc, etc..) I basically get the same error of "no WBFS partitions found."

What am I missing? It just seems as if WWT can't associate my drive's wbfs folder properly. I'm hoping to add .wbfs containers and .iso files.

-TIA

edit: Using..
wit copy /path/to/*.wbfs --dest /Volumes/WII/wbfs/%I.wbfs --test
..seems to show it would move it. Is this the proper convention for moving games over?

edit 2:
I seem to have answered my own question in using wit over wwt. My question stands for the above command being a proper convention for moving files? I'd rather not end up with invalid sector heads and lose some split games.

 

[Wiimm]

EtherealX

1.) wwt didn't found a WBFS partition because
a) the partition is corrupted
b) wwt has no access to it (no admin mode)

2.) As I told "wit move" had problems with splitted files. The latest beta (see history log) should fix the problems. Because of my cold I have made only some few tests.

 

[Hooya]

I think the extract killed all my games.

Really? Have you checked your WBFS partition before? Does WIT it? If yes, please tell me the used release and the exact commands for tests.e

The commands you were posting were not manipulating the files correctly. None of the files came with the proper name. I had checked the WBFS partition with WWT, and the files extracted with the ID6 as the name. They would not play with backup loaders and would not manipulate properly with WIT. I had already deleted the WBFS partition, so all the original files were lost. I spent the last few days ripping disks using wit [wit copy /dev/scd0 /wii_external_drive_path/%X --wbfs] and those all came out great. The program worked just perfectly for that purpose, but when I used WWT to extract those images they came out as junk. Every one of them. So I now have all my games back, formatted with the %X file name, with greater than 4GB images split in 2GB chunks. I also extracted some for use with SNEEK and they work great.

So, WIT: great program. Wonderful.

WWT: killed all my games! Took me several days to get them all back, many of which I had to re-download because I didn't have optical media versions of them!

Ultimately your commands work great, but only if the original files aren't corrupted.

 

[EtherealX]

EtherealX

1.) wwt didn't found a WBFS partition because
a) the partition is corrupted
b) wwt has no access to it (no admin mode)

2.) As I told "wit move" had problems with splitted files. The latest beta (see history log) should fix the problems. Because of my cold I have made only some few tests.

Well, I tried it over 4 different OSs, and the results for me are the same. No matter what OS (Win/OSX/Linux), running "wwt analyze" as root or sudo, returns the same error. Actually, if I run it without root privs, I get permission denied on my internals, and the same result for the external - where it analyzes, and seemingly finds no wbfs "partition." So I'm lead to believe that my drive is somehow corrupted? Here, in case, lies the catch.. I don't have any problems with my drive (it's a single partition, so no issues there.) All games work great, the drive is completely readable with Wii Backup Manager (Win7.) Would that be normal if the drive was corrupted? (Any tools that I can run a check on the drive without breaking games?)

My question still stands, is using "wit copy" a proper convention for transferring games over? If I could just use "wit copy *.iso --dest /path/to/wbfs/newgame.wbfs" would that move the game properly to avoid the invalid sector error?

Hopefully this isn't a dumb question, but wwt does work with fat32 formatted drives, correct? ..as in its not just for wbfs-format drives?

Sorry for being a thorn, TIA.

 

[Wiimm]

"wit copy" is the general copy and converting command. "converting" means: joining, splitting, changing file format. On the fly you can patch ID, title and some other stuff.

My question still stands, is using "wit copy" a proper convention for transferring games over? If I could just use "wit copy *.iso --dest /path/to/wbfs/newgame.wbfs" would that move the game properly to avoid the invalid sector error?

Is "newgame.wbfs" a directory? if not, all files should copied into the same destination file. wit has a security layer to prohibit this.

"wit copy *.iso --dest /path/to/wbfs/ --wbfs" copies all *.iso into the directory "/path/to/wbfs/". The new format and the new extension is "wbfs". If yo want fine control over the destination filenames then use % escapes like: ... --dest /path/to/wbfs/%T/%I.wbfs

For windows user: replace the % sign by $ and add the option -E$

For all: Use always the option --test to see what the tools would do.

 

[Wiimm]

WIT: Wiimms ISO Tools v1.17a - 2010-10-05
A command line ISO+WBFS tool set for various os.

WIT (Wiimms ISO Tools) is a set of command line tools to manipulate Wii ISO images and WBFS containers. The two main tools are called wit (Wiimms ISO Tool) and wwt (Wiimms WBFS Tool, the WBFS manager).

Feature overview:

• WIT (Wiimms ISO Toolset) is a set of command line tools.
• wit (Wiimms ISO tool) is the main Wii and GameCube ISO manipulation tool.
• wwt (Wiimms WBFS tool) is a complete WBFS manager including FS checking and repairing, time stamps and multi WBFS support.
• wdf-cat and wdf-dump are WDF and CISO support tools.
• WIT supports 6 Wii disc file types (ISO, CISO, WDF, WIA, WBFS and FST) and can read from pipes (indirect RAR/ZIP/7Z support).
• wit can verify and compare (diff) Wii and GameCube ISO images.
• wit can extract and compose Wii ISO images.
• wit can patch Wii and GameCube ISO images while copying.
• wit can mix partitions from different sources into a new Wii ISO images.
• wit and wwt support many diagnostic commands.
• Advanced shell support.

Visit http://wit.wiimm.de/features.html for more details.

Download of the current version:

• wit-v1.17a-r1834-i386.tar.gz : Linux/i386 version
• wit-v1.17a-r1834-x86_64.tar.gz : Linux/x86_64 version
• wit-v1.17a-r1834-mac.tar.gz : Mac OS universal binaries (ppc, i386 and x86-64)
• wit-v1.17a-r1834-cygwin.zip : Cygwin (Windows) version
• Other releases are available from http://wit.wiimm.de/download.html.

There are also some GUI available:

• QtWitGui, manipulate and convert single ISO images.
  This QT based GUI focuses on manipulating single ISO images.
  .
• WiiJManager Multiplatform, a WBFS manager GUI
  A java GUI that acts like a WBFS manager. Converting of ISO images is also possible. (The project seems to be dead)

Highlights of this release:

• WIA = Wii ISO Archive
  WIA is a special archive format to reduce the needed disc space (usually 15%-50%, Animal Crossing saves 82%). The data is stored in chunks to enable a kind of random access. Every chunk is compressed with BZIP2 or LZMA. USB loaders can't use WIA.
  
  Read "WIA (Wii ISO Archive)" on the WIT site for details and some statistics and please use the GBAtemp thread "WIA = Wii ISO Archive" for WIA discussions.
  .

Change log:

wit v1.17a r1834 - 2010-10-05

- The WIA file format was completely redesigned. WIA supports now 5
ÂÂ compression methods: NONE, PURGE, BZIP2, LZMA and LZMA2.
- New extended syntax of option --compression: method.level@factor
ÂÂ 'method' is the name (NONE, LZMA, ...) or index of the method. '.level' is
ÂÂ a point followed by one digit. It defines the compression level. The
ÂÂ special value '0' means: Use default compression level. '@factor' is a
ÂÂ factor for the chunk size. With the default factor '1' the chunk size is
ÂÂ 2 MiB (size of 1 Wii sector group). All three fields are optional.
- I declare the WIA file format stable and hope that converting to and from
ÂÂ WIA is free of bugs. The best for users is to convert to WIA and back and
ÂÂ compare the result with the original source.
- New command: WIT COMPR: Prints a list with supported compression methods.
ÂÂ With parameters the normalized names of that parameters are printed.
ÂÂ WIT COMPR accepts the options --long (twice) --no-header and --sections.
- The new tool 'wdf' should replace the tools wdf-cat, wdf-dump and should
ÂÂ compensate the old tools wdf2iso and iso2wdf as general wdf converters.
ÂÂ See built in help for details. The tool 'wdf' is EXPERIMENTAL!
- Support of GameCube multiboot discs. (EXPERIMENTAL!)
- New options --align-part: Align partitions while moving or creating them.
- New options --disc-size: Define a minimal disc size.
- Command "wit SCRUB" renamed to "wit CONVERT". "wit SCRUB" is still allowed.
- From now the first 0x50000 bytes of Wii discs will be scanned for non zero
ÂÂ data. Such data is included into the copy operations. The old and standard
ÂÂ scrubbing algorithm ignore such sectors in the range 0x08000..0x3ffff.
- WBFS files with more than 1 disc are not longer detected as ISO images.
- CYGWIN: Improved support of windows style pathes ('X:\path\file').
- Bug fix: While composing the FST size (var 'max_fst_size4' in 'boot.bin')
ÂÂ wasn't updated. If you compose an ISO and the resulting FST is bigger than
ÂÂ the original, the Wii apploader failed.
- Bug fix: Creation of a WIA file failed if option --psel is set and at least
ÂÂ one partition was removed (scrubbed). The result was an invalid disc image.
- Bug fix: "wit MOVE" didn't create the directory path even if --DEST is set.
- Bug fix for "wit move": wit move have forgotten to move the continuation
ÂÂ files of splitted images.
- Bug fix: Non Wii ISO images are not listed any more if the source is a
ÂÂ directory. This old behavior of wit was lost some releases ago.


Known bugs:

- wit COPY --raw: Copying an image in raw mode to a WBFS file is buggy.
- There are new problems while reading from non seekable sources (e.g. pipes).
ÂÂ The reason is the complete new and more intelligent wiidisc lib which makes
ÂÂ more lookups. I have to insert some code especially for pipes. My plans
ÂÂ that copying multiple partition discs works too.
ÂÂ ==> The best is to use a version 1.01c for pipes.
- No bzip2 (WIA) support for MAC/x86_64. (bug in the bzip2 library)


Missing docu:

- wit commands FILES + EXTRACT + EDIT => see built in help
- Option --show => see built in help
- Tool wdf => see built in help

The source is published under the license of GPL2. Checkout the sources directly from the SVN repository or browse the source. Visit http://wit.wiimm.de/ for more information.