emukidid / cleanrip Goto Github PK

I didn't have a problem, but:

What is the speed compared to SuperDump?  Does it depend on the filesystem 
being ripped to?  What is the difference in speed between USB1.0 and USB2.0?

Thank you for cleanrip and all the work that must be put into these sorts of 
things.

I wondered whether it would be possible to change the text slightly please.. 
just small request I understand if other more important things are priority.
It says "% percent complete" now but I think it would be better to change to 
just "% complete". 

Thank you

ETA and Completed time do not show up in 1.0.3. Bugfix immediately.

What steps will reproduce the problem?
1. Rip a 2-disc game (Metal Gear Two Snakes, GoldenEye Rogue, etc...)
2. Rip another 2-disc game, or any other single disc games
3. check files on harddrive, note added "-disc2" on filename, multiple 
("-disc2-disc2") if more than one 2-disc game was ripped during the same session

What is the expected output? What do you see instead?
Expected: filename.iso (single disc rip that followed rip of 2-disc game during 
same session)

Result: "filename-disc2.iso" or "filename-disc2-disc2.iso" (as well as the 
dumpinfo files and BCA)


What version of the product are you using? On what operating system?
1.0.5 on Wii to rip GC games collection


Please provide any additional information below.
I've this program to complete rips of all my Wii and GC games previously 
without issue. Thanks! However, this was my first attempt of ripping the two 
2-disc games I have in my collection, both during a single ripping session. The 
games (single disc) that I ripped first came out named correctly, but *all* 
titles following the first 2-disc rip ("Metal Gear Solid The Two Snakes") had 
"-disc2" added to the filename, and all titles following the second 2-disc rip 
("GoldenEye Rogue Agent") had "-disc2-disc2" added to the filename.

It would be nice to add a setting for the user in case he wants to shutdown the 
Wii once the rip completes.  I find myself more often than not ripping late at 
night and it would be great if I could just launch the rip and go to bed.

When Backing up GameCube Discs, using system 4.3U CleanRip 1.0.4 will very 
frequently not initialise the disc.  After inserting the disc and hitting A, 
when it works properly it goes to Initialising disc and you hear the disc drive 
click into motion. Often the screen goes to initialising disc, the drive does 
not click into motion and the software is stuck waiting endlessly for the drive 
to respond, thus putting you in a position of having to hard reset your Wii, 
which is unfavorable. Sometimes the Wii has to be hard reset several times 
before it will properly initialise, sometimes you can get up to 3 discs done in 
a row before having to hard reset.

Would it be possible to have an option for cleanrip to automatically check if 
Disc is single or dual layer?

This would be great if its possible.

Thank you.

I often find myself having a corrupt drive for some reason, maybe other 
homebrew not unmounting or closing files properly I don't know.  The point is 
sometimes the dumps are bad, files missing, etc.

In my case the only thing I use the usb drive for is to dump games, and I have 
to format it to FAT32 using my gf's Mac because I have Windows 7 and only exFAT.

It would be awesome if you could ask the user if he wants to format the usb 
drive (if using usb) before dumping, so if the partition was corrupt, a 
formatting would ensure it's clean.  Maybe add NTFS fomatting also for folks 
using that.

Add in an option which will allow the dump to complete on a FAT32 device 
without prompting the user for a new storage device on each chunk split. (i.e. 
a large FAT32 HDD).

Using cleanrip 1.04 under HBC 1.08

Since I had a 8gb usb drive (fat32), I set chunk size to Max. After 6 rips 
(different discs) failing in a row with files of the exact same size, I 
realized the problem is with the max file size under fat32 (shouldn't be a 
problem with ntfs). At just over 4gb the rip would always fail with a write 
error. After setting a file chunk size, I was able to complete the rips 
successfully.

That option should be disabled for a fat32 device for a Wii disc (which would 
go over the max filesize limit).

What steps will reproduce the problem?
1. Unbox Virgin late-model Wii (NTSC-USA, Sports Resort bundle)
2. Use Return of the Uodi hack to boot and install HomeBrew channel only
3. Put CleanRip 1.0.4 on SD card apps directory
4. Launch CleanRip

What is the expected output? What do you see instead?

Expect it to work ;)

Instead, it crashes with stack dump or just freezes at random points. I tried 
ripping both a Wii and Gamecube disc (original, factory new, no scratches). It 
never actually gets to the point of reading the disc.

What version of the product are you using? On what operating system?


Please provide any additional information below.

So, on a virgin new system without any CIOS or changes OTHER THAN installation 
of the Homebrew Channel - it just doesn't work.

I tried: 1) To the front SD Card with 2GB FAT32 card that I was booting the 
CleanRip from itself - tried doing a GC disc
  2) USB attached NTFS drive that I know works fine with wii

I tried all this about 10 times, CleanRip would freeze and crash (stack dump) 
randomly.  I finally then did a full wii mod install (all the CIOS hacks, 
Priiboot, etc) - and CleanRip works perfectly with all the same hardware.

It is almost like the standard Wii operating system has a security watchdog 
that is killing the program. As I could not find any pattern to the 
freeze/crash of the program - but it never got as far as actually ripping a 
disc.

Again, after I did all the full softmod hacks, it works fine now.

I don't have a big USB Drive, but I want to use your good and fast program. Can 
you include this feature?

This is more of a feature request, but...

Would it be possible to add something like a "Disk Verify" mode?  That is, a 
mode in which the program only attempts to -read- the entire disk, then display 
when the attempt was successful?

I'd like a way to check a GameCube disk to see if it were in working condition, 
or whether it was scratched beyond reading, and it's difficult to do that 
through normal gameplay at times.  It seems as though CleanRip could be set to 
simply "verify" that the entire disk was accessible.

Any chance of adding that?  It would make my Goozex transactions smoother if I 
knew beyond a shadow of a doubt that any GC or Wii disk I had was 100% 
operational.

What steps will reproduce the problem?
1. Have IOS 4.2
2. Install IOS58
3. Start cleanrip

What is the expected output? What do you see instead?
"IOS58 installed but not in use" message

What version of the product are you using? On what operating system?
Systemmenu 4.2 IOS58

Using 1.04 on 8gb fat32 usb flash drive.

I was trying to rip my dual layer SSBB disc using 3gb parts and yes on new 
media for new part (and yes on dual layer).

Completed part 1, removed drive and copied part to computer then formatted 
flash drive (verified clean drive) and returned to Wii for part 2. Completed 
part 2, but when I connected drive it showed both part 1 and part 2 on disc 
(full size parts!). I copied part 2 only and formatted (Quick format) flash 
drive again (and verified clean). Returned drive to Wii for part 3. Part 3 
completed with a "Copy Completed in 60 mins." message with correct MD5. But, on 
my computer the flash drive now showed all 3 parts (full size which will not 
fit on my 8gb drive) and when I tried to copy part 3 it failed.

It would be great if the program could remember or defaults to the settings we 
choose (except DL and things that change from disc to disc) like partition 
type, usb or sd, etc.

And maybe ask the first time if the user wants to ask those settings again each 
time and hide the prompts if he chooses no.  In this case maybe add a third 
button to press that would bring those settings again.

What steps will reproduce the problem?
1. Rip a variety of games, including at least one dual-disc game.
2. Observe messed-up naming on target device.

What is the expected output? What do you see instead?
e.g., disc 1 of Tales of Symphonia should presumably be named GQSPAF.iso, but 
instead was named GQSPAF-disc2.iso. Now you're wondering what disc 2 was named: 
GQSPAF-disc2-disc2.iso. I dumped about ten discs in a row, three of them being 
/actual/ second discs of games, and the majority of them were left with an 
appended -disc2, e.g. Metroid Prime 2: Echoes: G2MP01-disc2.iso. Observe 
Resident Evil, disc 2: GBIP08-disc2-disc2-disc2.iso. I'm not even kidding. If I 
had to guess, I'd say each time a "disc2" rip is performed in a single session, 
-disc2 is appended to the names of any subsequent rips also.

What version of the product are you using? On what operating system?
HBC 1.0.8 with IOS58.

Please provide any additional information below.
Renaming these things is gonna be confusing as hell.

This is not an issue for using the application, but more of question for 
building it. Thanks.

What steps will reproduce the problem?
1. compiling r18
2. error at main.c: cannot find DI_Read_BCA

What is the expected output? What do you see instead?
compilation to work fine by using standard libogc (with standard DI library)

What version of the product are you using? On what operating system?
r18

Please provide any additional information below.

Verify against the http://redump.org Gamecube & Wii database.

if(!dat files found) {
"Redump.org DAT files not found" "Download them now?" "Yes" "No"
}
else {
"Check for (and download) a new version of the DAT files"? "Yes" "No"
}

on completion of a rip:
"Submit Rip checksums to Redump.org?" "Yes" "No"

CleanRip calculates the ripping speed by dividing the amount of data read by 
the time elapsed. This means that the displayed speed is an average of the 
ripping speed from the start of the rip up to the current point, instead of the 
ripping speed during the last few seconds. The current speed is more useful to 
see, and it's also what I would expect to see, because it's what most file 
copying utilities use.

I've managed to dump 2 discs with apparent success but another 2 discs fail 
with a message "Motor Off". It appears to happen at the same point each time, 
which makes me wonder if it's something unreadable at that point on the disc. 
Both discs are clean and free of all but minor surface marks.

I have a drivekey modchip. I've disabled region free settings as advised and 
even tried CleanRip with drivekey completely disabled, with same results.

I've also tried different SD cards, in case it was a write issue rather than a 
read issue. With a smaller card and selecting a new device for each chunk I got 
a truncated chunk once I hit the "Motor Off" message. With a larger card 
writing all chunks to the same card I found the card was empty after the "Motor 
Off" message, no chunks written at all. Not sure what to make of that.

Any advice would be appreciated.

Directly writing wbfs files on fat32 or ntfs with configurable splitsize would 
be great!

Thx!

1.0.4

Would it be possible to add the option to do error checking?  Since the DVD 
speed is more than half slower than most USB drives this shouldn't affect 
speed.  Anyway this would be an option so users could turn it off.  I had 
problems with a corrupt FAT32 drive, only got the second chunk and the program 
didn't tell me.

So I ripped a few games using CleanRip v2.0.0 on my Gamecube chipped with 
XenoGC.  I used SD Media Launcher to launch cleanrip-gc.dol from a 2gb SD card 
+ adapter.

None of the MD5s matched with the Redump DAT file.  When I copied the ISO to 
the PC and opened it with an ISO Explorer, it seemed OK, as in the files showed 
up and looked normal, but when burning to DVD and then loading with the GC it 
failed every time with an error at start - so clearly the rip was bad.  I even 
tried re-ripping the same disc and it came up with the same incorrect MD5 each 
time.

I also tried ripping the ISOs from my un-modded Gamecube and the MD5 matched 
the DAT file perfectly.  I loaded CleanRip the exact same way as the chipped 
Gamecube using SD Media Launcher and the same SD card + adapter.

I ripped ISOs using my Wii and the Wii boot.dol and the same discs and they 
ripped perfectly and the MD5 matched the DAT file like it's supposed to.

Is it possible XenoGC is causing problems with obtaining correct rips?

First off all thanks for this aazing program.

Second off all sorry for submitting this under issues, but this bugtracker 
doesn't seem to have a feature request setting and I wouldn't know how else to 
each you.

Would it be possible to implement the ripping of datel discs in this program? 
The only program I know of that could do that was softdevs disc ripper and 
sadly that one couldn't rip the later datel discs, since it switched into 
Datel-mode depending on game-ID.
So I still have my latest gamecube Action Replay disc here and have to swap it 
every time I want to use some cheats. If there was a ripper I could just 
extract the .dol and launch it via Gamecube Homebrew Launcher...

So if you could include this feature it would be really awesome.

What steps will reproduce the problem?
1. Select USB
2. NTFS
3. No drive found or can't mount drive

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?
1.04

Please provide any additional information below.
Using HBC 1.08 IOS58 Drive works with CFG USB loader v60 without problems

What steps will reproduce the problem?

Load Cleanrip v2.0.0 with only gc.dat on Gamecube

What is the expected output? What do you see instead?

It should tell you that the Redump DAT files have been found.
Instead, it prompts you that the files have no been found and asks if you want 
to download them.  This is pointless seeing as the Gamecube cannot dump Wii 
games, so the check for wii.dat should not be there.

Workaround:
Download a proper wii.dat
OR
What also worked for me was copying the gc.dat, renaming it wii.dat, and it 
would not prompt me anymore.  I tried using a blank wii.dat but it did not 
work, so it needs to be some kind of valid .dat file.  This was easier than 
looking for a legit wii.dat.

Exception (DSI) occurred!
GPR00 FFFFFC70 GPR08 00000001 GPR16 801B36E8 GPR24 801C25FC
GPR01 8029C4F8 GPR09 00000078 GPR17 00000001 GPR25 FFFFFFFF
GPR02 801C23C8 GPR10 00000000 GPR18 801B3194 GPR26 00000000
GPR03 8027C080 GPR11 801C46F8 GPR19 801C4BFC GPR27 8050D4F0
GPR04 00000400 GPR12 84242042 GPR20 801B3600 GPR28 00000000
GPR05 00000000 GPR13 801C4BC0 GPR21 801B3168 GPR29 8027C080
GPR06 00000005 GPR14 801B3174 GPR22 801B35B0 GPR30 801C44B8
GPR07 00000048 GPR15 8020A600 GPR23 801B3584 GPR31 00000408
LR 80071174 SRR0 80071258 SRR1 0000b032 MSR 00001000
DAR 00000004 DSISR 04000000

STACK DUMP:
80071258 --> 80071174 --> 80043e08 --> 8003e068 -->
800385a0 --> 80023248 --> 80021fd8 --> 8000d16c -->
8006f170 

GODE DUMP:
80071258: 813C0004 5529003A 7C1F4850 2F80000F
80071268: 2F000000 419D01D4 409801D8 839C000C
80071278: 7F8BE000 409EFFDC 38E70001 839E0010

Originally documented here:
http://www.gc-forever.com/forums/viewtopic.php?p=1648

The first 6 bytes of a GC disc will be the same over a multi-disc game. Byte 6 
on the disc will need to be checked and if it's not 0x00, the filename should 
have appended to it the label "-disc2".

What steps will reproduce the problem?
1. try to rip Metroid  the other M and Cleanrip will not write to NTFS partition
2. try to write to FAT and that worked
3.

What is the expected output? What do you see instead?
That Cleanrip will rip the game,instead get message that write to FTFS failed.


What version of the product are you using? On what operating system?

Cleanrip 102 and 103

Please provide any additional information below.

This is a feature request aimed at simplifying creation of new reports to 
redump.org. Information needed from images to be posted to the Wii or GC 
sections are CRC32, MD5, and SHA-1, with the addition of DOL MD5 for GC discs.

My suggestion is that each dumped image gets accompanied by a txt-file with the 
same name containing all said sums, so that one can easily dump an entire 
collection of Wii and GC games and then quickly make proper reports to upload 
without having to run different tools on the images.

�CRC32, MD5, and SHA-1 can easily be calculated simultaneously as the dump, but 
DOL MD5 has to be calculated after the dump is done. DOL MD5 can for example be 
calculated as with this perl script: 
http://pastie.org/private/og7c4iymlkef6tgavdx9eq

This does of course not need to be compulsory, but can be a selectable option 
for power users wanting this additional info.

The capability to update the database, as in fetch + unzip, directly on the Wii 
would be very useful.

What steps will reproduce the problem?
1. I downloaded CleanRip v2.0.0
2. Everything is formatted, so I load the program
3. Says to Insert a USB FAT 32/NTFS formatted device (which I do), then gives 
me the error message.

What is the expected output? What do you see instead?
To begin ripping gc disc.  The error mounting device message

What version of the product are you using? On what operating system?
v2.0.0 on Wii 4.3U

Please provide any additional information below.
I can't seem to find anything I am doing differently from everyone else.  
Please help.

First, thank you very much for this awesome dumper.  I've been waiting for a 
long time to get rid of cIOS for good, the only homebrew I use are dumpers.

Since I don't rip games that often it's not urgent.  And it's only a feature 
request.

I would like the program to detect on its own what disc is in the drive (GC / 
Wii / Wii DL) and also where to dump (if there's a USB drive just assume it'll 
be there, or make a config file so the user can change this setting one time 
and not each time we have to dump.  Then detect what type of FS, etc that drive 
uses, FAT32, NTFS, etc.

It would be awesome if we could just start the program via HBC, insert a disc, 
press A to dump, and then A again to dump another game when it's finished, and 
then A again, etc.

Would be really awesome.

Thanks!

At the moment, the application will only try to read the DAT files from 
Redump.org from the selected storage device, which will be also used for the 
dumping process.

I think it would be good if the app prompts a message asking whether the DAT 
files will be read from the dumping device or from the other one. Quite simple, 
but helpful.

Since nearly all my USB-Harddrives formated with ext4, support for that 
filesystem would be great. There is already a useable port: 
http://code.google.com/p/libext2fs-wii/

What steps will reproduce the problem?
1. Load the program using an 8GB SDHC card as target medium.
2. Dump a double-layer disk in parts of 2GB with "new device for each part" 
activated.
3. When new media is requested, move the finished part from the SDHC card to a 
different storage medium.
4. Reinsert the emptied SDHC card for the next part.
5. The previously removed parts will reappear and mildly corrupt the filesystem.

What is the expected output? What do you see instead?
The expected output would be only the recently dumped part, but what I get is 
the dumped part PLUS all the previously dumped parts.

What version of the product are you using? On what operating system?
1.0.4

Please provide any additional information below.

Everything is all right, since the Wii and Gamecube can't read DVD-R and 
DVD+R/DL on the new drive, can it read DVD backups by adding External DVD Drive 
by plug on Wii USB port 1 or 2. And by the way, I didn't mean put Defect, it 
suppose to be Enhancement because i couldn't find the template.

when i try to use my usb thumb drive(4gb) i get that error after using 1.0.3 
and the new 1.0.4 iv formatted it to ntfs, fat32, exfat, fat, wbfs, and no luck 
:(

What steps will reproduce the problem?
1. Starting program
2.
3.

What is the expected output? What do you see instead?

I expect the program to start up and give me options to rip the disk. Instead 
it's telling me that "AHBPROT check failed", and then tells me to press "A" to 
return to the loader.

What version of the product are you using? On what operating system?

I've got the latest HBC (with the dark screen and bubbles!), I'm on 4.1E, and I 
upgraded to IOS 58 using an offline install by downloading IOS 58 using NUS 
Downloader, saving it as a WAD, and installing it with a WAD installer.

Please provide any additional information below.

That's all. Thanks.

next version should fix this.

What steps will reproduce the problem?
1. Error Mount Device [00000000] -Fat32
2. No device found -NTFS
3.

What is the expected output? What do you see instead?
I expect it to see the drive and rip my games. Nothing. *Sniff sniff*

What version of the product are you using? On what operating system?
v1.0.5 on IOS58 HBC 1.1.0

Please provide any additional information below.
I've been using Gparted to format my SEAGATE 500GB Portable hard drive. When 
it's formated in Fat32 I get the error above, and when it's formatted as NTFS I 
get a no device found. I can atest that the Wii sees the drive as i've used 
Wiixplorer to make my USB ports are not bad.

Hello emukidid @

 Do I have a problem with the USB data carrier to be with the version 1.0 and the new 1:01 not detected.

There is always an error message Mounting Device (000000)


Have 80gb hard drive and 500 gb usb there are several formats have been tried

only at 32 was not fat then ntfs was not even on exFAT. these hard drives are 
on wiiflow or usb loader detected gx.

My 2gb sd card in the front range of the wii is going to put fat but with which 
I may not have to dump wii games because not enough space free.

I use the HBC 1:08 and my wii is 4.1E have iso 58 on wii

See SysCheck v2.0 by Double_A

SysCheck v2.0 by Double_A
... Running on the IOS58 (rev 6175).

Region: PAL
System Menu 4.1 (V450)
Hollywood v0x11
Console ID: 67877753
Boot2 v2

We found 126 titles.
We found 42 IOS, of which 8 are ignored (stub).

IOS4 (rev 65 280): ignored (stub)
IOS5 (rev 514): Trucha bug, ES Identify, access Flash, NAND access
IOS9 (rev 521): No patches
IOS10 (rev 768): ignored (stub)
IOS11 (rev 7): Trucha bug, ES Identify, access Flash, NAND access
IOS12 (rev 12): No patches
IOS13 (rev 16): No patches
IOS14 (rev 263): No patches
IOS15 (rev 523): No patches
IOS16 (rev 512): ignored (stub)
IOS17 (rev 518): No patches
IOS20 (rev 256): ignored (stub)
IOS21 (rev 525): No patches
IOS22 (rev 780): No patches
IOS28 (rev 1293): No patches
IOS30 (rev 2816): ignored (stub)
IOS31 (rev 3092): No patches
IOS33 (rev 2834): No patches
IOS34 (rev 3091): No patches
IOS35 (rev 3349): Trucha bug, ES Identify, access NAND
IOS36 (rev 3351): Trucha bug, ES Identify, access NAND
IOS37 (rev 3869): No patches
IOS38 (rev 3867): No patches
IOS40 (rev 3072): ignored (stub)
IOS50 (rev 5120): ignored (stub)
IOS51 (rev 4864): ignored (stub)
IOS53 (rev 5406): Trucha Bug
IOS55 (rev 5406): Trucha bug, NAND access
IOS56 (rev 5405): Trucha bug, NAND access
IOS57 (rev 5661): Trucha bug, NAND access
IOS58 (rev 6175): No patches
IOS60 (rev 6174): No patches
IOS202 (rev 65535): Trucha bug, NAND access, USB 2.0
IOS222 (rev 4): Trucha bug, ES Identify, access NAND, USB 2.0
IOS223 (rev 4): Trucha bug, ES Identify, access NAND, USB 2.0
IOS242 (rev 3): Trucha bug, ES Identify, access Flash, NAND access
IOS247 (rev 4): Trucha bug, ES Identify, access Flash, NAND access
IOS248 (rev 7): ES Identify
IOS249 (rev 17): Trucha bug, ES Identify, access NAND, USB 2.0
IOS250 (rev 65535): Trucha bug, NAND access, USB 2.0
IOS251 (rev 20): Trucha bug, NAND access, USB 2.0
IOS254 (rev 65 281): BootMii
BC v6
MIOS v8

Report was generated on 08/23/2010.


Maybe I can because of a lack of what may be there ?????

What steps will reproduce the problem?
1. install HBC on vwii using smash stack (need a wii u)
2. add cleanrip to SD card and insert game disc into disk drive
3. load up cleanrip and follow the on-screen prompts

What is the expected output? What do you see instead?
It should detect the disc a wii disc and start the dump after the config 
screen, instead it does not detect disc type, asks you for it and says it could 
not create ****disk18.iso (**** is a series of gibberish characters) and then 
quits

What version of the product are you using? On what operating system?
using CleanRip 1.0.5 on wii u vwii system menu 4.3 (i think, whatever the vwii 
system menu version is, assuming 4.3)

Please provide any additional information below.

What steps will reproduce the problem?
1. wii 4.3 US system menu hack mii 0.8 HBC installed
2. atempt to rip SSBB to NTFS drive 
3. error cant create nfts:0/chunk0.bin occurs

What is the expected output? What do you see instead?
should work, does in version 1.01, 1.02 and 1.03 cause the same error

What version of the product are you using? On what operating system?


Please provide any additional information below.
hit me up at [email protected] if you need any more feedback and testing.