Ah, so it's likely just my drive then. That settles that. It'll be a long while before I have the time to look at it again though, so I'll just -T if I need to.

So as far as multiplatform goes, my work is as done as it can be. Thanks again for the source!

Er, yeah... it was an abort. Guess I should use the same words as the program, hm? It didn't actually explode or anything, the abort just read like one (specifically the part where it stops at a certain sector).

Assuming the fix above works, the two builds should work identically to the way they worked in the source before I fixed it, rather than it only functioning on Windows.

If GC discs work fine, then it must only be an issue between Wii SL and DL discs. This can be fixed with -T, but I guess it wouldn't hurt to figure out what's causing it to read as DL every time. My guess is it's something in disc.c, but I'm kind of skimming the code since I don't know a whole lot about the ins and outs of disc dumping.

Edit: Just to reiterate, the program functions identically to the version already released. It works fine with no problem, the only thing that was changed was an int type. This should be compatible with Windows, so as long as it compiles there is no problem (and basically no change) and the program will function exactly the same as before, since the int type is essentially the same, just under a name GCC recognizes.

I'm just reporting a bug that Wii SL and DL discs both read as DL discs, and this applies to ALL builds of 0.5.3.

Someone else will have to test it on Windows. If someone wants to try building/running it, use that tarball I linked to above. The only concern would be if it compiles or not though, since the only thing I changed was an int type. Even before I updated it functioned the same way (the SL/DL thing that is).

Also, the -T 1 test was successful. There are no inconsistencies, it was just 0.5.3 trying to read SL discs as DL. This leaves us with 2 issues left:

1. Whether or not it compiles/runs on Windows
2. Bug: 0.5.3 (all builds) interprets all Wii discs as Wii_DL (tested on GDR8082N), but this is a bug with 0.5.3, not the Linux update

If #1 works, then the Linux fix I did is complete. #2 is just something to be addressed for FriiDump in general, not the update I did.

*Edited like 300 times to articulate what I'm seeing with these tests*

First, readdressing speed: For some reason this next set of tests I did went at the same speed as 0.4.0 now. Seems the speed of the first test was a fluke.

As for inconsistencies, I'm now pretty sure that it's just where the dumping stops. All versions of 0.5.3 for some reason treat every game as a dual-layer disc. When you use a single-layer disc, 0.5.3 crashes at 55% every time. 0.4.0 will complete the dump as a proper single-layer disc.

Despite the crashing in 0.5.3, the dump size is consistent every time as far as I can tell. My guess is fixing the single-layer/dual-layer thing will fix the size difference between the two (which is likely the only real difference, I'd be shocked if there was any difference in actual data).

Going to try to force -T 1 and see how that compares to 0.4.0's result.

It's slower for sure [EDIT: No it isn't, see below]; I'll give it one more go to check for inconsistency.

Bump to let you guys know that I got it compiling and I'm running it now to make sure nothing explodes.

It's being hosted here if you want to try it: http://www.flibitijibibo.com/files/flib … ump.tar.gz

Changes:
libfriidump/dumper.c:
- #include <inttypes.h>, using int64_t instead of __int64
libfriidump/CMakeLists.txt:
- Include the new files (new as in 0.5.3 anyway)

Let me know if it works on other systems!

Edit: It's functional as far as I can see, but good lord is it slow (400MB/h slower than 0.4.0). I'll test a few more games once this one is done and see what happens, but this first test is going to take like another 5 hours.

Edit 2: Nevermind, forgot the whole crash at 55% for SL thing. The output of the two dumps differ, but they both appear to be functional. As far as I can tell, the Linux build of 0.5.3 now works.

Awesome, thanks!

I did eventually get 0.4.0 working, but 0.5.3 was a lot faster between the two Windows builds anyway, so I'll see if I can figure it out for Linux. I'll let you guys know if I get *NIX up to speed. big_smile

Does it even exist anymore? I've been looking everywhere and it seems every site/search result just points to the 7zip file. I'd like to compile/run it for Linux, as 0.4.0 doesn't seem to work (GDR8082N on Fedora 14 x86_64 by the way) and I'd rather not think about trying to Wine it...

Thanks in advance.