You are not logged in. Please login or register.
Redump Forum → Posts by chungy
Pages 1
You could also dump GameCube discs from a Wii, no modchips or extra hardware necessary, just as long as you have a wireless router.
You pretty just just need cIOS and the cIOS DVD Dumper: http://wii.waninkoko.info/ (yeah, I know that Waninkoko doesn't make the safest programs, but these ones can't do any real damage).
Same as any other DVD. use IsoBuster
It should be the same, but why don't you get them and test? 
Guess, Kega's internal CUE parser is wrong, not a dumping method issue.
This does not explain why Kega is unable to see the data track in one instance. The cue sheet for the data track is identical. Daemon tools is definitely doing something odd in that instance.
Do all the files actually exist on the filesystem? Look at the cue-sheet, and the Cue sheet syntax, there don't seem to be any errors in them on the article in question. I would have to bet that Kega is wrong (emulators tend to get it wrong more often--DOSBox, for example, doesn't skip the pregap if you've mounted a virtual CD using its native method, though a real CD or CD-emulators will not have these problems), there doesn't seem to be any compelling reason to believe otherwise.
You've never had to re-insert a cartridge before a game system recognised it? I'd find that hard to believe 
(this message was to Snake...)
The dumps Themabus and I verified together had no such problems at all, and they're full raw dumps. Our dumps matched perfectly
Yes, but what he's saying is that there is a higher chance of errors, and this is absolutely correct. By reading the data as 2048 bytes/sector it allows your drive to use the extra data to actually verify that the user data is correct and/or fix it on the fly. So if the drive reads it and does not report an error, you can guarantee that your data track is correct. By reading as 2352 bytes/sector this is not the case. Running the resulting image through CDmage will inform you of such errors and allow you to attempt to fix them, but why not let your drive do that for you? Your drive can also attempt to re-read the sector if needed - CDmage can't do that.
Does IsoBuster not already re-read problem sectors? I haven't used it on discs with problem sectors yet, but I know that cdrdao in raw-reading mode (btw it can read the subchannel data, if it's of any interest) *will* re-read problem sectors multiple times until it gets a good copy (or correctable, either way...).
You could alternatively use a CD with a "hidden track" and see how EAC behaves in both modes yourself, and you'll see why its default option is wrong.
By "hidden track", I mean a song or other sound bit that was encoded into the pregap (usually before Track 1), so most CD-players will skip over it by default and you need to hold the rewind button to get to the hidden track. You could also make a test CD which behaves in this manner, if you don't know of any albums like this.
'm just curious though; which systems have MODE1 data tracks where the game actually makes use of the additional EDC/ECC data in that MODE1 track?
PlayStation, for one Some PC games also have falsified EDC/ECC data for rudimentary copy protection (granted this does protect against the ripping-only-user-data method as was common for bypassing copy protections).
Oh, it does make sense. It is very simple when you look at the different layers of error correction.
- for audio tracks as well as MODE2 data tracks (user data = 2352 bytes), there is the CD drive's internal C1/C2 correction mechanisms.
- for MODE1 data tracks (user data = 2048 bytes), there is the drive's internal C1/C2 correction mechanisms PLUS the 304 bytes of EDC/ECC data contained in each RAW sector of 2352 bytes.So, the more error correction you have available for your chunk of user data, the less chance there is that the user data is wrong.
I think our problem is a language problem tbh... earlier you were saying it increased the chance of the data being wrong, and now you're saying it decreases it? Other than that, I see no issues with this quote
Of course, the discussion is a bit theoretical:
- If you have a good condition CD, you get reliable RAW data.
- If a drive's internal C1/C2 error correction cannot compensate for read errors in the RAW data, the resulting dump would not be usable for the redump database anyway.
Which is why redump.org encourages people to dump CDs of their own even if it's already in the database. You might verify a previous dump, you might find it to be wrong, maybe both are wrong (though if two different CDs produce identical data, it's extremely unlikely both of them are wrong). You might even find out that you have a CD from a completely different manufacture!
Daemon Tools' cue-sheet parser is correct then
gigadeath wrote:-to achieve consistency between systems
You consistently dump RAW data tracks for every system, but you do not consistently dump just the user data for every system.
redump.org doesn't "just dump the user data" for any system, so it's a null point. If they did, it will have to be looked on a case-by-case basis on weather a system and/or game needs the extra data. Dumping the raw sectors for anything and everything is simple; the rules don't change for different systems or games.
gigadeath wrote:-because if you really hate raw dumps you can convert them later but you can't do the other way around with 100% reliability
I don't "really hate" them, I just question their usefulness for systems which do not require the EDC/ECC data as user data. For these systems, it just produces data overhead and increases the chance for getting bad dumps as explained in my previous post.
I have no idea where you got the idea that it increases the chance of bad dumps, this doesn't make sense. Either the CD drive is just giving you the raw data (redump.org) for you to store, or it's just sending back the user data, but it's still reading it all to do internal checking/correction.
gigadeath wrote:-because dumping raw takes only 10 seconds more and not 10 hours
See above, usefulness and data overhead.
The increased time is purely a limitation of your hard disc. The CD drive spins the disc at exactly the same speed (as said above, it's reading the same amount of data) weather you're dumping just user data or all data.
Some discs don't actually require purposely-altered EDC/ECC data, and just use normally constructed ones. In such cases (PC games usually), you can generate a 2352 byte/sector "dump" from a standard 2048 byte/sector image (I don't know of much that can do this... besides using a CD drive emulator like Daemon Tools or CDemu then using the dumping apps) that is identical to the normally-dumped method. In certain cases, this will never be possible (eg, PSX).
And the creators of the ISO 9660 standard had no concern in this matter. It's a filesystem and it wasn't their duty to dictate how CDs store information in the low-level manner, that was Philips' job (see ECMA 130 for details on the physical layout of CDs and the low-level 2352-byte sectors). You can also store ext2, FAT, UDF, any other filesystem on a CD, and it's of no concern to those filesystem authors what the low level CD format is.
(Technically speaking, redump.org DVD images are all wrong since they don't include raw DVD sectors, which is far more difficult to access and not all DVD drives do it in the same manner (essentially every vendor has their own proprietary commands); who's to say that non-chipped PS2s actually check data that's not in the 2048-byte user data area of a DVD sector?)
Realistically, the ".iso" extension should have never been. It's a direct reference to the ISO-9660 filesystem. It's alright I suppose if it were strictly for such filesystem images, but alas, files with the ".iso" extension often are images that contain filesystems OTHER than ISO-9660 (be it UDF, HFS, whatever) or non-standard deviations from the ISO-9660 standard (Joilet and/or Rock Ridge, or relaxations on filesystem limits).
I admit that I don't know much about GameCube discs, but I'd be surprised if they use good old ISO-9660.
Game stores usually have a machine to resurface CDs. Try that.
Yes, easily. It just involves a little math.
For example, take All Star Racing. A cue sheet for a single file might start off like this:
FILE "All Star Racing (E).bin" BINARY
TRACK 01 MODE2/2352
INDEX 01 00:00:00
TRACK 02 AUDIO
INDEX 00 05:07:01
INDEX 01 05:09:01
on a similar note, does anyone know of a good laptop DVD drive? A USB2 drive would also work...
I'd also prefer if I can hack the firmware to be RPC1, but it's not a requirement.
Pages 1
Redump Forum → Posts by chungy
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.