Hacking Modify friidump for dual-layer

[Dirtie]

All this SSBB malarky seems rather unnecessary and over-the-top to me, and the guy that apparently was able to dump it seems to be using a very inefficient way to dump ( http://nekokabu.s7.xrea.com/blog/2008/02/post_33.html ).

Namely he is sending commands to a little app called plscsi.exe which sends commands to your drive (read command to get the appropriate data into cache, then the debug command to read that data). I myself wrote a batch script to automate plscsi when dumping Wii discs was being experimented on (before Rawdump arrived), and one or two others did similar. This method is usually extremely slow however, hence the 17 hours figure that was mentioned earlier (theoretically it can be sped up by sending the correct commands but this app doesn't seem to do that). It will also give a CORRUPT IMAGE and run slower if the drive is not locked - ie. if DVDInfo isn't running in the background. That means there could be a lot of people wasting their time with this. The last thing is the fact that unscrambler has a bug that means it will repeat a sector at the end of an iso. This dumper dumps both layers individually - if each layer is unscrambled before they are joined together, and no allowance is made for this bug in the code, it could cause problems (although this may almost be a non-issue depending on how the app works).

Eventually Rawdump arose out of the plscsi experimentation, and therefore superceded it (it does exactly the same thing, except it has a GUI, unscrambles discs automatically, and uses some tricks to speed things up significantly). But obviously rawdump does not work with dual-layer discs as yet.

So did people forget about FriiDump or what? Looking at the source code in disc.c, changing the amount of sectors it reads seems trivial:

#define DISC_WII_SECTORS_NO 0x230480  /* 2294912 */

Assuming the first dumper has the number right, we could replace this with:

#define DISC_WII_SECTORS_NO 0x3F69C0  /* 4155840 */

I see no reason why this shouldn't work, but feel free to correct me.

After that: compile and see what happens? I tried to compile it myself but ended up with a mess because I don't have a decent development environment

 

[Roflcopter_Down]

aren't frii dumps scrambled?

are there any standalone apps that unscramble Wii disc images?

 

[Dirtie]

Yes the unscrambler app was around before any of the dumpers were, it just has the duplicate-sector-at-the-end-bug, but that's trivial to fix provided you know how to use a hex editor or trim a file to a certain size (I think someone even compiled a fixed version on tehskeen or something).

FriiDump unscrambles images by default, or you can tell it to leave them scrambled, etc.
It has a few nice options

 

[Hooya]

Since the Dual Layer dumper was just released, that contains an unscrambler for .wod files. Should work on any dumps regardless of what program they were dumped with, so why not use that or incorporate it in FriiDump. Heck, this new dumper was released with source code, so the two could probably work beautifully in conjunction (especially if they happened to be written in the same language)

 

[Dirtie]

I already showed how they can be used in conjunction - by getting the amount of sectors from the source code

Nothing else is needed - everything the first dumper does, FriiDump does better or faster.

 

[taggart6]

PLScsi supports a number of dvd, cd, and HDD drives. Friidump (unless I'm mistaken) currently only supports the following drives.

- LG GDR-8161B (untested, but should work)
- LG GDR-8162B (ditto)
- LG GDR-8163B (HL-DT-ST/DVD-ROM GDR8163B)
- LG GDR-8164B (HL-DT-ST/DVD-ROM GDR8164B)


If the dumper had a dvd drive unsupported by Fiidump then it makes sense he used something like PLScsi.

I guess it depends on how tight with the scene he is (amature or pro) and what hard ware he had available.

 

[Dirtie]

PLSCSI supports pretty much EVERY drive - it's just that not every drive supports the debug command to read from cache. And this automation is no different, the exact same debug command is used, which means this will still only work with those same drives.

Like I said in my first post, this was all done before a long time ago.

 

[vinikun]

So Dirtie, two nights ago I edited that value in Friidump and recompiled, then sent it off to a guy who had SSBB. He tried ripping SSBB overnight, and then when the program got to the 50%ish mark, it crashed (presumably because it hit the end of L0 and was trying to get to L1). My guess is that in addition to changing that constant, one also needs to implement layerbreak.

Nekokabu released a dual layer dumper that works but very inefficiently as you said, and produces a dump that, while being able to play, cannot play some movies. That said, a guy on IRC is ripping SSBB right now using that dumper, but it'll likely take upwards of 25 hours, since as specified in the README of Nekokabu's dumper, normal Wii games take about 17 hours to dump. Kinda sucky

 

[Dirtie]

So Dirtie, two nights ago I edited that value in Friidump and recompiled, then sent it off to a guy who had SSBB. He tried ripping SSBB overnight, and then when the program got to the 50%ish mark, it crashed (presumably because it hit the end of L0 and was trying to get to L1). My guess is that in addition to changing that constant, one also needs to implement layerbreak.

Nekokabu released a dual layer dumper that works but very inefficiently as you said, and produces a dump that, while being able to play, cannot play some movies. That said, a guy on IRC is ripping SSBB right now using that dumper, but it'll likely take upwards of 25 hours, since as specified in the README of Nekokabu's dumper, normal Wii games take about 17 hours to dump. Kinda sucky

Thanks for that, this is the kind of information we need.

I assumed that when you read past a certain sector it'd automatically switch to the next layer - obviously I was mistaken.

If the Japanese dumper app can read each layer individually though, I don't see why FriiDump can't with some minor modifications? If we start reading at the beginning of the second layer perhaps this issue won't occur.
When you hit the layer jump when reading, maybe it requires a seperate command? (I doubt I'll be going back to check on the MMC docs anytime soon though

)
Or maybe the maximum amount of sectors is hardcoded elsewhere in FriiDump, although I doubt it, because if this was the issue then the Japanese dumper app would have been coded to read through the whole disc from start to finish, rather than doing each layer seperately - meaning that it probably suffers the same layer-jump issue.

The FriiDump source is a bit hard to work with for me though, with all the external files, not to mention my understanding of C is very rudimentary.

A couple of questions: the guy who attempted to dump it, did he use the parameter to output a raw dump rather than an unscrambled one? Did he try and use the resume parameter after it failed?

 

[mark0217]

Now THIS is an useful discussion thread. I just want to congratulate you guys, since I do not have any knowledge other than the most common on these subjects.

 

[BoneMonkey]

17 hours dammmmn

 

[theman69]

Now THIS is an useful discussion thread. I just want to congratulate you guys, since I do not have any knowledge other than the most common on these subjects.

+1

 

[Hellfromabove]

Dirtie PM sent.

 

[Dirtie]

Experimental dual-layer rawdump released: http://gbatemp.net/index.php?showtopic=74016
If it works, it'll be a hell of a lot faster.