(9 replies, posted in General discussion)

F1ReB4LL wrote:

I think it's better to report the number of errors from CDMage, because edcchhk treats many cases as "warnings", that's confusing.

I agree.. but I think the 1337 and 46113 are the sectors with modified subheaders. They do show as errors in CDMage?

spiney wrote:

What's the difference between Playstation disc versions (1.0, 1.1, 1.2, etc)?
Is it a disc protection version or is it a version of the game?

We use this naming scheme to differentiate between different game versions / builds. There's no version number stored on the disc that we know of, so a higher version number, say v1.1, is assigned purely to indicate that the EXE date or disc creation date is newer than the dump with the lower version number.

Got the same hashes after fixing all 3 errors (for the last sector I imported the user data from the Germany dump and rebuilt ECC/EDC). I think we can conclude then that DIC/plextor is messing up here. Hopefully wiggy2k can get the same hashes with a non-plextor drive.

RetroGamer wrote:

Here are my hashes of the data track of T-15913H-50, dumped with a non Plaxtor drive with IsoBuster

rom ( name dbtrack1.iso size 322113456 crc a41d7727 md5 18419a0a9ace416e8f0ef384fc70f7f0 sha1 0eef922b201a1a639854a55af97b5c45cab2e8c6 )

cdmage error count?

The first thing to check is how a non-plextor drive deals with these sectors. Can they be read at all?

The first error sector probably yes, because ECC/EDC is intact. It's possible that normal reading of the sector will give the correct(ed) output. Repairing the current dumps will will yield the correct sector with the same user data as the (Germany) region dump.

The second error sector has the user data intact, but ECC/EDC area has modified bytes in the last last 144 bytes. This maybe the result of the way that DIC reads the discs. Anyway, with only the last 144 bytes corrupt, cdmage still manages to repair this sector correctly, and different drives might also be able to read this sector correctly.

The last error sector (29669) is the real problem. DIC doesn't seem to produce any correct data and the sector is fully scrambled. We need to compare outputs of non-plextor drives to a plextor 'ECC off' read from cdtool and look for consistent bytes.

You can't trust DIC output if there are C2 errors. The output that it creates is unique to plextor drives and should not be included in the final dump. Repairing the first 2 errors is the most sensible approach, because this should be consistent with the output of other drives, and also better than replacing the entire sector contents with a dummy (0x55) pattern (this is how we deal with intentional C2 errors that are part of copy protections), because here it would mean losing valid data.
As for the last error sector, if no drive produces a valid data sector, then the only sensible approach would be to replace it with dummy contents.


(4 replies, posted in Guests & account requests)

Thanks.. I hope one of the admins will approve your account. In the meantime I've added your dump here: http://redump.org/disc/38187/

And the game has been removed from the undumped list: http://wiki.redump.org/index.php?title= … sing_Dumps


(17 replies, posted in General discussion)

MigaMan wrote:

Here is one way to make it easier on every body.

Add a recent changes history like you have for the recent dumps. Make it easy to quickly identify whats changed. Make it visible to everyone (or at least reg users) and put it on the homepage along with the recent dumps.

Now you have easy oversight and more transparency to the changes made. Therefore you can afford to add more mods. Maybe do temporary stints so people with a lot of crap decaying in the forums can take care of it themselves. It becomes easy to monitor one or two new/temporary mods with the above changes.

If someone makes a mistake or oversteps their bounds PM them.

If someone makes a questionable change then make a forum post and discuss it. The current system is backwards.

(Yea yea iRobot is too busy to do web coding right now I know. But it's a good idea for future I think)

http://redump.org/feeds/recentchanges/rss/ ? and also mods can see a history log with changes


(1,162 replies, posted in General discussion)

haynor666 wrote:

I've noticed that if I dump using DiscImageCreator cd W: gamedir\game 4 then dat file is empty but if I use DiscImageCreator cd W: game 4 then dat file is fine. Anyone noticed this?

The slash is causing the issue.. someone else mentioned the same problem in a chatroom yesterday


(17 replies, posted in General discussion)

It's not just your dumps, take a look here: http://forum.redump.org/forum/11/dumps/


(17 replies, posted in General discussion)

I can only speak for myself and I have no time for digging through huge forum topics with dozens/hundreds of verifications.. It's a manual and very tedious process. There are still a bunch of them, dating back to 2014 or so.. They won't go anywhere, but it could still take some time before someone adds them.

Apparently Enker, F1ReB4LL, iR0b0t, Nexy, ack2121, gorelord4e, usurper don't have any time for this either.


(29 replies, posted in General discussion)

LedZeppelin68 wrote:

I have processed with it ~800 GC isos and ongoing.

the statistic is: 3 isos cannot be decoded properly

Sega Soccer Slam (Japan) - has error in file system
Doshin the Giant and Kyojin no Doshin have errors in garbage, unknown reason

Maybe the first one is a bad dump? Is there a scene release to compare with?


(1 replies, posted in Fixes & additions)

Yep it's correct.. You can see here also: http://www.amazon.co.uk/X-Change-Bishou … B008131FIE ASIN decodes to 0652823206321.

http://redump.org/disc/34295/ and http://redump.org/disc/37284/ are also confirmed to have identical barcodes


(29 replies, posted in General discussion)

LedZeppelin68 wrote:

about XBOX and XBOX360 images, there is also tools in their sdks, but they produces "standard" fatx isos, like those in original xbox scene releases. My thoughts, this iso-container then transfered to MS for final mastering (security sectors, "garbage" padding).

There is also a tool in the SDK for creating a double layer disc layout (it also shows the position of the security placeholders) and iirc it can also generate output images with padding? Although I'm not sure if this is the final padding.

Enker wrote:

It was probably hidden by someone, I don't see it in the deleted feed. An admin can check if it was.

Btw, can you double check this write offset? http://redump.org/disc/37221/

+31 was clearly wrong.. I think he's using a PX-716 so it's most likely combined offset that he posted and +1 is write offset


(10 replies, posted in General discussion)

Nice to hear that you also have SAT stuff.. DIC should be fine, try and verify some games.


(11 replies, posted in General discussion)

It gives the same output as clonecd.. But I think DIC does safedisc sector filling now too.

Which system are you talking about specifically? because IIRC OneUp group just repackaged a lot of redump dumps and released them as scene.

lol.. just make a forum thread


(6 replies, posted in General discussion)

This may be worth a shot? http://www.ebay.com/itm/Generic-2-Port- … Swu4BV1lVM


(6 replies, posted in General discussion)

Promise Ultra 100/133 should be okay: http://www.ebay.com/sch/i.html?_odkw=id … p;_sacat=0

or do you need PCI express?


(6 replies, posted in General discussion)

I'm using one of these http://www.ebay.com/itm/USB-2-0-to-IDE- … 2052856507 (I just connect the drive when I need it and plug in power from psu).

Getting closer and closer to a complete set now, with the help of Starshadow.

Updated wiki: http://wiki.redump.org/index.php?title= … sing_Dumps

Still some expensive ones missing. We're also on the hunt for missing versions. A notable example that I just found out about is GTA San Andreas 2.0*. Most likely it's this disc (the label shows 'Second Edition'). It's fairly cheap on eBay.


Also, please supply the CRC-32 hashes!

I don't know who added these dumps, but they will be removed if you don't complete the missing info.

Thanks, but how do we know that those EXE dates are reliable and not influenced by the filesystem?

Could you compare the EXE date of one of your verified dumps to what's in the database?

Don't know what is the purpose of this post, but we're only accepting verifications that include ringcodes.