FriiDump 0.5.3 Source Code [Update: Linux build!]

[themabus]

but on Windows it works, right?
i guess this is the part that has to updated for Linux.

[flibitijibibo]

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.

[themabus]

no, no, we tested it on Windows quite a lot, it should be alright
i don't have Wii discs myself though, but it read PC DVDs and GC discs fine
but on Linux nobody did
i thought maybe it's something specific to your system
but still it's strange it crashes
if it was for size difference, drive would just request sectors that can not be read and program would abort
it sound very much like something has to be fixed for Linux

[flibitijibibo]

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.

[themabus]

yes,  type is determined with disc_detect_type by simply requesting some sectors ahead of standard GC disc size
and then, if it pass, ahead of Wii size
i guess maybe your drive just doesn't return expected sense code
there was other method left in source, relying on content of DVD, but it was not used for some reason
so i left it alone

maybe you could check what sense your drive returns
on Windows IsoBuster could do this but i don't know about Linux tools

edit:
oh, right, i guess you could just compile it to print sense it returns

edit:
i've rechecked 0.5.3 (that precompiled version from year back) on my Lite-On with DVD+R and DVD+R DL
and it gets first one as Wii and 2nd as Wii_DL
so, i would say, on Windows generally it's fine

[flibitijibibo]

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!

[themabus]

ok
thank you flibitijibibo
i'll add link to this thread in main topic, for other Linux users

[themabus]

no, it's name, that should have been changed
it's pretty messy like that
this Reed–Solomon unit is there for Lite-On, since those drives erase two bytes from each raw sector
this data has to be regenerated
they would not work at all, would there be something wrong

i made that unit atop of Morelos-Zaragoza & Thirumoorthy code
(3. 'Reed-Solomon errors-and-erasures decoder' @The Error Correcting Codes (ECC) Page)

i don't know, maybe i'll clean it up someday
not anytime soon though,  i'm pretty done with this for now

edit:
ah, right, you mean, it shifts all data out now?
probably can just remove this bracket then

[themabus]

result is correct as it is now, probably just an unnecessary remainder is what it is
there should be quite a lot of commented out code parts and such
i didn't really invest time in aesthetics
but you could test this unit with raw DVD or CD sectors if you want to be certain

[charliee1151]

Hello all, new guy here.

I'm interested in Friidump, which is why I'm in this thread.

I have downloaded the source to Friidump 5.3, and have it running on windows under VS2010.  I'm learning!

But I am unsure of two things, and any help would be appreciated.

1. There is a program called BruteForce3C included with Friidump.  According to the text file, when I run it, it will interrogate the target drive to determine if it has READ BUFFER capabilities.  The text says that "all returned data different from $00 will be logged to files."  Has anyone done this?  When I run it, I don't get any files created, at least not in the same directory from which I launch it.  However, I DO get a set of numbers, like 141.712.  If I run it again, I get 135.985.  What do these numbers mean?  Do they have any significance, or should I only  be concentrating on the fact that there is no file created?

2. The target drive data is
a) H-L Data Storage
b) V/M: HLGDR-816B
c) DVD-ROM Drive
d) Model GDR-8161B
e) Type HDCO
f)  Drive Rev A2
g) FW 0045
h) In the "MFC" section:
    DVD-ROM DRIVE
    (GDR-8161B)
    E-H023-02-2782 (B)
    2003. 05
I have seen some listings of drives that are known to work, but they all list the result of a successful Friidump, displaying something like "HL-DT-ST/DVD-ROM GDR8164B/0L06".  Obviously, that actual text does not appear on the drive itself.  Given that items "a", "c", and "d" match, should I expect the drive to work?  Or do I need to see "0L06" someplace, also?

Note that Friidump shows this drive as not supported.

Also note, I have the target drive connected via a USB to IDE adapter.  Should I try for a direct connect to the IDE cable?

Again, any help here would be appreciated.

Thanks
Charlie