101

(2 replies, posted in Guests & account requests)

AKuHAK wrote:

Hi all.

I have collected some bioses (dumped with ps2idetn) from PlayStation 2 that missed in redump database.
So I have SCPH-39008 with dvd rom 2.16R, SCPH-50002 with dvd rom 3.00A, SCPH-79010, SCPH-90008 (v2.30) and DESR-5700 bootrom and dvdrom dumps.
Im collecting info about ps2 so if redump guys have ps2ident reports i can exchange it for my dumps.

Best regards,
AKuHAK

Hi,

we don't have any PS2Ident reports, because most dumps were made before that tool existed. I do corresponded with SP193 every now and then to synchronize our databases and track down any corrupt dumps.

If those dumps that you have originate from your own, unmodified consoles, then we can add them. Otherwise we have no way to verify that the dumps are really correct. Modchips are known to corrupt the BIOS.
SCPH-39008 is not in the PS2Ident database yet. If this is your console, then please dump it with modchip disabled and send info/dumps to SP193.
SCPH-50002 also not in PS2Ident database, but if it doesn't match one of the versions in our datfile, it's probably corrupt. 3.00A DVD ROM also sounds fishy, because 3.00A = Asian and SCPH-50002 = European.
SCPH-79010 BIOS is probably corrupt (the one in the PS2Ident DB has comment "Console is modded").
SCPH-90008 BIOS should match "ps2-0230e-20080220", but the one in PS2Ident DB doesn't, so probably also corrupted.
DESR-5700 also isn't listed in the PS2Ident DB. If you have this model, then please submit your info/dumps to SP193.

Could you write down the ranges and sector count like you did before but after the fixes?

And you should always have /RC switch enabled for DIC when dumping error sectors! so that the user data gets the 0x55 pattern like CDM/CloneCD does. If you forgot this in previous dumps then plz fix them.

I will post my results later this week or early next week, when my copy arrives.

edit: Added my dump.. You should redump your disc with CDM/CloneCD because IsoBuster replaces error sectors with non-error sectors.

sarami wrote:
Jackal wrote:

CodeLock and LaserLock are similar in that you try to get as many readable sectors as possible with one or more non-plextor drives until you get consistent results. CodeLock patterns can vary: http://redump.org/discs/quicksearch/cod … tion/only/

Ripping the CodeLock by plextor with 0xd8, the strange string can be seen.

beware the jabberwock my son the jaws that bite the claws that snatch

CDManipulator and CloneCD recognize the sector including this string as error sector.
Game: Rune http://redump.org/disc/31708/
hex editor of sector 2327 http://www.imagebam.com/image/0b922f533425871
Left is ripped by plextor PX-W5224A with 0xd8, right is ripped by TSSTcorp DVD-ROM TS-H353A.
Do you think this CDM/CloneCD (right) images are correct? If you so, what is the reason?

I don't know which dump is 'correct', but if I had to choose between 2 dumps with different error count, I would pick the one with the least amount of errors.. Especially if only 1 brand (Plextor) gives different results for whatever reason and most other drives give consistent results.

TheRetroPirate wrote:

Why is that?

Anyway I made a small python script to compare my 5 dumps of track 1 so far.
And there are indeed 12 ranges with bad sectors.

Bad blocks found:  732
Bad range:  1 :  (2137, 2194) :  57
Bad range:  2 :  (2509, 2571) :  62
Bad range:  3 :  (2810, 2871) :  61
Bad range:  4 :  (3187, 3244) :  57
Bad range:  5 :  (3559, 3621) :  62
Bad range:  6 :  (3936, 3993) :  57
Bad range:  7 :  (4308, 4370) :  62
Bad range:  8 :  (4687, 4745) :  58
Bad range:  9 :  (4984, 5046) :  62
Bad range:  10 :  (5360, 5422) :  62
Bad range:  11 :  (5735, 5797) :  62
Bad range:  12 :  (6261, 6319) :  58

The error count seems to be 1 more for each range than what you calculated?
If 2137 is the first error and 2194 the last, then the total errors in that range is 58.

And please check with your Plextor drive if the start of each error range is the same everywhere as those combined results? It's possible that one of the non-Plextor drives starts 1 sector earlier on some ranges. I don't know why this happens, but I've seen this happen on some drives (my Plextor drives and the Optiarc one always give the same start sector for each range).
As for the end sectors, you can't say for sure if the current results are final, unless you do a manual check. It's possible that some sectors are readable but only after multiple retries. It's really tricky.
It would probably be a good idea if I purchase this game as well, so that we can verify these results. Is this the disc that you're trying to dump? http://ogdb.eu/imageview.php?image_id=1 … mp;limit=0 (with the same ringcode?)
Or maybe you have one of the other LaserLock titles that is already dumped, and you could try to verify it. Then we'll know for sure that your method is reliable.

edit: I just bought Outcast, so we should be able to compare results by the end of the week.

TheRetroPirate wrote:

So basically read the data track as many times as possible with different drives and do a sector compare?
I could use a python script to compare the single sectors, the sectors which never match must be the bad ones.

It won't work unless you browse back manually after each error range.

CodeLock and LaserLock are similar in that you try to get as many readable sectors as possible with one or more non-plextor drives until you get consistent results. CodeLock patterns can vary: http://redump.org/discs/quicksearch/cod … tion/only/
LaserLock usually has around 12 unreadable areas of 78-82 errors. See the comments for some examples: http://redump.org/discs/quicksearch/las … tion/only/
For such discs I use CDTool to browse back manually from the end of each error area and recover as many readable sectors as possible (going back and forth between sectors and rereading sectors multiple times until the drive is able to read them) and inject them into the non-plextor CDM/clonecd data track dump image with a hex editor. For LaserLock discs this means several hours of manual work for each disc and you would need a drive with a powerful laser to grab all readable sectors (Sony Optiarc 7280 gives me the best results, but surely other Optiarc and other brands could work fine too.. it's a process of trial and error).

You cant dump such discs reliably with DIC.. I'll write some instructions later

108

(7 replies, posted in News)

Last November 17, the server HDD failed and our hoster apparently provided zero effort in recovering any data. Daily backups were still on the same HDD, so the last backup that was in possession of the admins was from November 3.
After some weeks of radio silence, our admin iR0b0t finally informed us of the situation. It then took him another 2 months to finally bring back the site again on February 5. It still remains unclear why it took him so long to bring back the site, but what matters now is that the site is back up and that steps have been taken to prevent this from happening again: We are on a better server now with RAID1 and daily backups. On behalf of iR0b0t, Jesus, God, Satan, the Deutsche Post and everybody else involved in this calamity, we wish to apologize for the sudden downtime and thank you for your patience.

We want to ensure you guys that redump.org is here to stay. It's now been 10 years since we started our journey (nostalgia trip) and a lot has happened in those 10 years: Many people have come and gone and a lot of new systems and information have been added over the years. Many thousands of hours have been put into creating a database with information on many thousands of video game-related optical discs. Cataloging and preserving this history seemed like an impossible task when whe initially started out, and even though the project always remained somewhat small and obscure, we can still conclude that a lot of things have been accomplished in those 10 years and that many of the games that we love and cherish are now preserved in our database. Many systems can now be considered "reference sets" and have regions now that are probably over 95% complete, including PlayStation, PlayStation 2, Gamecube (Europe and USA) and Xbox (Europe). The (Japan) region continues to catch up, thanks to a small group of dedicated dumpers who continue to add new dumps each week. Then there's also IBM PC, our largest and most convoluted system, which also continues to have a steady stream of rare and not-so-rare discs added to the db each week.

A huge thanks goes out to all the people who contributed to our database over the past 10 years, and we look forward all the new contributions from new and existing members in the years to come.

Can you check the error count with cdmage and look for a copy protection (by scanning the game exe with protection ID)?

Offset is not an issue when DIC is used

110

(3 replies, posted in General discussion)

http://forum.redump.org/topic/2468/offs … d-command/

This will give you the combined offset, so you'll have to subtract the read offset

Yeah, about time that you get a plextor like everyone else

If one of the 2 images has fewer cdmage errors then the one with more errors must be wrong

It's not PC Gamer.. a lot of PC Gamer discs are already in the db.

"CD Gamer Issue 65: January 1999"

or what iR0b0t said

113

(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.

118

(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

119

(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

120

(1,229 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

121

(17 replies, posted in General discussion)

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

122

(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.

123

(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?

124

(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

125

(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.