Problem dumping a disc with Swiss and some suggestions

Discuss one of the most feature filled GameCube applications here :)
Post Reply
mark_k
Posts: 8
Joined: Sun Sep 02, 2012 9:56 am

Problem dumping a disc with Swiss and some suggestions

Post by mark_k » Tue Sep 25, 2012 3:27 pm

Hi,

I'm using a GameCube and have been using Swiss to dump my GC discs. I've thought of some suggestions for future improvements...

One disc is quite scratched (Medal of Honor Rising Sun disc 1 if it matters). I dumped it five times using Swiss and each time the MD5 checksum differed. None of the checksums matched that shown at redump.org, so they were all bad dumps. Swiss didn't give any indication that there were read errors. I later tried using CleanRip 1.0.4 which dumped that disc correctly first-time. Not sure if that was just good luck, or whether Swiss is unable to detect read errors when dumping? [Is GC CleanRip supposed to be able to dump BCA data? Because it didn't for me.]

It would be good if the user could manually set/adjust the disc image filename. For example with the two Medal of Honor discs, Swiss gives disc 2 the same filename as disc 1. So when you start dumping disc 2, the disc 1 image gets overwritten with no warning. The user might not notice that, because when the file already exists Swiss doesn't delete/truncate the existing file. (So the disc 1 image file looks full-size even though the first part of it is corrupted if the user aborted shortly after starting to dump disc 2.)

On a related note, if the file already exists maybe Swiss should ask the user whether to delete, overwrite or rename the new image.


Swiss can think it's been run from DVD when actually loaded via AR code/SDLOAD
When loading Swiss via AR code/SDLOAD, if the AR disc is in the drive when you run Swiss from SDLOAD, Swiss thinks it has been run from DVD. So it fails to load the saved config from SD. (A workaround for that is to open the lid when SDLOAD runs, before running Swiss.)


Make it possible to abort before pre-patching
When running some images, Swiss says "This game requires irreversible pre-patching / Press A to continue". Make it possible to abort without patching e.g. by pressing B. Also an "Are you sure?" type prompt would be useful there too. (If the user just dumped that disc, Swiss corrupts the image before the user has off-loaded it to their PC.)


Use filename extension by default
When saving disc images, use a filename extension by default, rather than no extension. So instead of "Super Mario Sunshine", create a file "Super Mario Sunshine.gcm". (IMHO .gcm makes more sense than .iso, since GC/Wii discs don't use the ISO 9660 filesystem.)


Show SD card free space remaining
Show the amount of free space (e.g. in the top right corner of the screen) when browsing/selecting files on an SD card. That would save the user wasting time by backing up a game disc only to have the process fail due to lack of space.


Show current path at top of screen
When in a subdirectory, show the current path at top of screen. Currently there doesn't seem to be any indication which directory the user is in.


Check free space before backing up disc
Check the amount of free space on the SD card before beginning to write the disc image. Currently Swiss seems to write until the card is full then aborts, which wastes time. The apparent size of the partly-written file showed as 0 bytes when I connected the card to my PC. If Swiss is going to abort when the disk is full, it would be good if the file could be properly closed so the size shows as the correct amount written so far. (Maybe Swiss could offer an option to resume dumping the disc if it finds a partial image file?)


Dump BCA, DMI and PFI data
When dumping original game discs, also dump (assuming this is possible):
  • BCA (burst cutting area) data
  • Disk Manufacturer Information data (2048 bytes)
  • Physical Format Information data (2048 bytes)

Add basic file management support
The ability to create directories, rename files & dirs, move files (to different name/path on same media, i.e. no need to read/write file data) would be useful.


FAT32 filesystem errors
After using Swiss to dump some discs (or otherwise write files to SD card), I'm seeing various FAT-related errors after moving the card to my PC and checking the filesystem. Could this be due to Swiss (or libfat or whatever) not flushing/updating the FATs correctly? Also it doesn't seem to be updating the second FAT at all. (See output when I tell dosfsck to use the second FAT below.) This test was done after I had dumped several game discs to my FAT32-formatted 64GB SDXC card.

Code: Select all

# fsck.vfat /dev/sdd1
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
FATs differ but appear to be intact. Use which FAT ?
1) Use first FAT
2) Use second FAT
? 1
Free cluster summary wrong (1970555 vs. really 1435894)
1) Correct
2) Don't correct
? 2
Leaving file system unchanged.
/dev/sdd1: 14 files, 534663/1970557 clusters

# fsck.vfat /dev/sdd1
dosfsck 3.0.9, 31 Jan 2010, FAT32, LFN
FATs differ but appear to be intact. Use which FAT ?
1) Use first FAT
2) Use second FAT
? 2
/NHL 2003
  Contains a free cluster (3). Assuming EOF.
/NHL 2003
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/The Hulk
  Contains a free cluster (44558). Assuming EOF.
/The Hulk
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/TY the Tasmanian Tiger
  Contains a free cluster (89113). Assuming EOF.
/TY the Tasmanian Tiger
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/swiss.ini
  Contains a free cluster (133668). Assuming EOF.
/swiss.ini
  File size is 317 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/Star Fox Adventures
  Contains a free cluster (133669). Assuming EOF.
/Star Fox Adventures
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/007_ Everything or Nothing
  Contains a free cluster (178224). Assuming EOF.
/007_ Everything or Nothing
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/Metroid Prime
  Contains a free cluster (222779). Assuming EOF.
/Metroid Prime
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/Metroid Prime 2 Echoes
  Contains a free cluster (267334). Assuming EOF.
/Metroid Prime 2 Echoes
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/The Lord of the Rings; The Return of the King
  Contains a free cluster (311889). Assuming EOF.
/The Lord of the Rings; The Return of the King
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/SUPER MONKEY BALL 2
  Contains a free cluster (356444). Assuming EOF.
/SUPER MONKEY BALL 2
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/Red Faction II
  Contains a free cluster (400999). Assuming EOF.
/Red Faction II
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/Medal of Honor Rising Sun
  Contains a free cluster (445554). Assuming EOF.
/Medal of Honor Rising Sun
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
/disc2/Medal of Honor Rising Sun
  Contains a free cluster (490110). Assuming EOF.
/disc2/Medal of Honor Rising Sun
  File size is 1459978240 bytes, cluster chain length is 0 bytes.
  Truncating file to 0 bytes.
Reclaimed 63 unused clusters (2064384 bytes).
Leaving file system unchanged.
/dev/sdd1: 14 files, 2/1970557 clusters
User avatar
emu_kidid
Site Admin
Posts: 4927
Joined: Mon Mar 29, 2010 10:06 am
Location: Australia
Contact:

Re: Problem dumping a disc with Swiss and some suggestions

Post by emu_kidid » Tue Sep 25, 2012 11:05 pm

thanks for the list, could you log them on the bug tracker instead as I'm more likely to look at them there? http://code.google.com/p/swiss-gc/issues/list
mark_k wrote: I later tried using CleanRip 1.0.4 which dumped that disc correctly first-time. Not sure if that was just good luck, or whether Swiss is unable to detect read errors when dumping? [Is GC CleanRip supposed to be able to dump BCA data? Because it didn't for me.]
Swiss treats disc dumping just like another file copy operation - nothing special with reading sizes or error detection, use CleanRip if you're dumping discs a lot.
CleanRip for GC doesn't dump BCA data as the drive doesn't have a function to return this data. I can read it out of the drive memory though which is something I've wanted to add to GC for a while, maybe next time.
mark_k wrote: It would be good if the user could manually set/adjust the disc image filename. For example with the two Medal of Honor discs, Swiss gives disc 2 the same filename as disc 1. So when you start dumping disc 2, the disc 1 image gets overwritten with no warning. The user might not notice that, because when the file already exists Swiss doesn't delete/truncate the existing file. (So the disc 1 image file looks full-size even though the first part of it is corrupted if the user aborted shortly after starting to dump disc 2.)
On a related note, if the file already exists maybe Swiss should ask the user whether to delete, overwrite or rename the new image.
Yeah I can fix that too by having the disc named <whatever> - disc <num> in the file browser.
mark_k wrote: Add basic file management support
The ability to create directories, rename files & dirs, move files (to different name/path on same media, i.e. no need to read/write file data) would be useful.
When you click on a file, you can Move/Delete/Copy, rename is another story.
[/quote]
mark_k wrote: FAT32 filesystem errors
After using Swiss to dump some discs (or otherwise write files to SD card), I'm seeing various FAT-related errors after moving the card to my PC and checking the filesystem. Could this be due to Swiss (or libfat or whatever) not flushing/updating the FATs correctly? Also it doesn't seem to be updating the second FAT at all. (See output when I tell dosfsck to use the second FAT below.) This test was done after I had dumped several game discs to my FAT32-formatted 64GB SDXC card.
That's libfat not updating the second FAT - other errors are possibly libfat too.
Image
Post Reply