226

(13 replies, posted in General discussion)

darksabre76 wrote:

I'm going to do some gravedigging here, so I apologize in advance. I recently came across the issue of trying to detect SafeDisc v3/4 without ProtectionId. There seem to be no public instructions out there on how these protections are actually found. If anyone here has even the slightest conceptual idea, I'd love to hear it. Thanks in advance!

AFAIK the only way is to scan the game .exe

227

(7 replies, posted in General discussion)

iR0b0t wrote:

Would a "Credits" field fulfill your needs, guys? smile

I still think it has no place in a database.. it's not really relevant how the dumper obtained the disc. It would be better to make a wiki page or something to credit contributors.

228

(7 replies, posted in General discussion)

I removed these comments, because we need to be strict about who is the dumper and who gets credited.. some weeks ago, people were being credited as dumper in submissions, because they were the ones lending games to a dumper. This is not allowed, only the person who dumped the disc should be credited as dumper.

It's okay to thank people somewhere who are lending out discs, but let's not fill database fields with this info.

Blau wrote:

I have a few Gamecube games (all already on the db), but I don't have a Wii to dump them. However I have a compatible CD drive that works with Rawdump/Friidump. I already dumped all and every hash matches the database.

The problem is, as the wiki guide says, I can't get the BCA. So my question is, can I post the dumps even without the BCA?

Yes, as long as you include all the other relevant data (ringcodes etc.)

Didnt read all the posts, but when there's multiple versions released of a game, and one of them is undumped, the version can be added to the filename for the one that is dumped. Is that what you mean with New Super Mario Bros. Wii?

Even with the offset detection fixed, it will still produce potentially bad dumps with missing data because there is no overread into lead-out?

@sarami / others

It has come to my attention that some dumpers are using non-Plextor drives with DIC for their CD dumps.
The first issue that I see is the offset detection:
For this dump: http://forum.redump.org/topic/18020/add … 2002-demo/ DIC detects a write offset of -12.
But for this one: http://forum.redump.org/topic/18021/non … piel-demo/ it detects:

========== Offset (Drive offset referes to http://www.accuraterip.com) ==========
     Combined Offset(Byte) -24696000, (Samples) -6174000
    -   Drive Offset(Byte)     24, (Samples)     6
    ----------------------------------------------
           CD Offset(Byte) -24696024, (Samples) -6174006
    Overread sector: -10500

So I wonder if the -12 offset is even correct?

Other risks of course include incorrectly descrambled / cut off data. As soon as a disc has audio tracks or mastering errors, the results can no longer be trusted.

It would probably be better to block CD dumping (or add warnings) on drives without D8 (at least by default, without a special parameter) and also add a check to the DICUI GUI to only allow dumping in D8 mode? If you don't add such checks, then people might think that they can just use any drive to dump, and if these dumps are added without checking, the database might soon be riddled with bad dumps.

233

(17 replies, posted in General discussion)

https://www15.zippyshare.com/v/7gNpDjVg/file.html

234

(17 replies, posted in General discussion)

Hiccup wrote:

On No-Intro, demos are basically split up into (Demo) and (Demo) (Kiosk).
I've never seen any labelled with numbers, but kiosk demos used at trade shows were labelled with the first trade show (e.g. (Demo) (Kiosk) (E3 2005) they were (first) used at, to differentiate with (Demo) (Kiosk) which is used for store kiosk demos.

I think its important to make a distinction between demos that are sold/given to consumers, and kiosk demos.

I've never seen a demo labelled with a number on No-Intro or Redump. @Jackal could post links for some?

You should be able to see this link? http://redump.org/list/miss/Jackal/

Then just search within the page for (Demo  <- with a space

235

(17 replies, posted in General discussion)

It's easy to show all the filenames: http://redump.org/list/miss/Jackal/

235 Taikenban

(Demo Taikenban) ??

It looks like iR0b0t added (Demo 1), (Demo 2) etc to some games.. yuk..

236

(6 replies, posted in News)

Today our project reached a major milestone: There are now 50.000 discs in the database.
Since our last news post around 12 months ago, close to 10.000 new discs have been added to the database:

- Around 900 PSX and 950 PS2 discs, including many Japanese, PAL regional variants and Demo's.
- Close to 800 Sega (DC, MCD, SS) discs.
- Over 400 XBOX discs, bringing the USA set much closer to completion.
- Close to 4.000 IBM PC discs (!).
- Over 3.000 discs for other systems (including modern, as of yet undisclosed ones).

A huge thanks goes out to our contributors and also the Video Game Preservation Collective (VGPC) for all their efforts.

237

(14 replies, posted in General discussion)

Thanks for bringing us closer to a solution. I guess you should try to eject and re-insert the disc after closing XBC (for dumping the DMI/PFI/SS) and before starting FreeCell. If that by any chance fixes the problem, then we need to add a check to FreeCell to make sure that the drive is in the correct mode/state before dumping. Otherwise it might be a firmware bug?

Also, it should be easy to find any other bad dumps if someone creates a tool to scan these sectors.

And it would be worth checking out if this issue also affects Xbox 360 in any way (!)

238

(14 replies, posted in General discussion)

Other dumps are matching: http://redump.org/disc/49180/ so I guess only a couple discs are affected by whatever is causing this.

239

(14 replies, posted in General discussion)

limbo43 is dumping a lot of Xbox USA stuff, but he's getting some different results than existing dumps, which leaves me worried about the different dumping methods that are used: Whether or not Xbox Backup Creator is a safe dumping method, and if FreeCell dumps discs correctly (without the Kreon drive injecting any data that shouldn't be there) regardless of the drive's (unlock) state.

The first one that wasn't matching is Need for Speed: Most Wanted: Black Edition: http://redump.org/disc/50146/
The previous dump by h0lylag was changed to red status because it was supposedly bad.. without a real confirmation or redump by either dumpers. I've sent h0lylag a pm, but I don't know if he'll ever be back to read it.

The second one is Toxic Grind: http://redump.org/disc/50472/ vs. http://redump.org/disc/49392/

We really need to determine which of the dumps is wrong and what's causing the difference (and possibly find a way to detect bad dumps), before we end up with hundreds of potentially bad dumps.

240

(5 replies, posted in General discussion)

Advertisement?

241

(3,536 replies, posted in General discussion)

This disc had the first 2 LibCrypt sectors undetected: http://redump.org/disc/50247/

Logs: https://drive.google.com/open?id=1ClsZ6 … 32TtOFAaxd

Maybe it's better to stop using prefixed ranges, and just not fix any subs in case /ns is used? because it happens a lot that some LibCrypt/SecuROM data goes undetected.

Or set a limit to how much corruption is fixed in each Q-channel sector. Now it fixed 4 bytes total, including 2 in CRC. I doubt that read corruption can occur on so many bytes at once, and also in both CRC bytes?

242

(3,536 replies, posted in General discussion)

@sarami, the last 2 SecuROM sectors here were undetected: http://redump.org/disc/13204/

What's the cdmage error count on those 3 dumps?

No point in adding this dump unless we can get consistent results.

I found this, but no idea if it's the latest version: http://www.mediafire.com/file/0q9u11r7m … master.zip

If it's a different version than the binary, let me know and we might be able to contact the dev (we got the e-mail address belonging to his account)

I suppose it's safe then. Don't remember why that was needed, it probably had to do with our older dumping method (MineSweeper instead of FreeCell).

246

(2 replies, posted in Guests & account requests)

Lol

TossEAC sent me a message about this disc: https://www.amazon.co.uk/GT-Circuit-Bre … B0000902CC

It's a PS2 cheat disc that seems to have some kind of copy protection. The data track has 4361 errors. When replacing them with standard 0x55 error sectors (with mode2 header), I get the following hashes:

<rom name="Image.bin" size="761692848" crc="44bcdd2d" md5="9aaa25ff944ead8777e9d8fa0784b185" sha1="49fa480165425828f10d2348cb89f28239d413a1"/>

I guess TossEAC could try to dump the disc with CDM or CloneCD on a non-Plextor drive. If the resulting dump has the same error count then it's probably correct.

The confusing part however is the cuesheet. 3 different tools produce 3 different cuesheets:

DIC:

FILE "Image.bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 00 00:00:00
    INDEX 01 225:231:225
    INDEX 02 00:00:02

CloneCD:

FILE "Image.bin" BINARY
   TRACK 01 MODE2/2352
   INDEX 01 00:00:00
   INDEX 02 31:25:33

and Sub2cue:

FILE "Image.bin" BINARY
  TRACK 01 MODE2/2352
    INDEX 00 31:25:31
    INDEX 01 00:00:00
    INDEX 02 31:25:33

Can anyone check which of those 3 (if any) is correct? Here's the DIC .sub: http://www119.zippyshare.com/v/LQLgnTQk/file.html .. or possibly a Subdump .sub is needed.

LP57 = mastering sid yeah and the other is mould.

249

(5 replies, posted in General discussion)

Did you really read this post? http://forum.redump.org/topic/6073/xbox … tructions/

XBOX 1 dumping instructions:

- Instructions for Kreon drives
- Instructions for 0800 drives (thx Starshadow)

Couldn't be clearer imho..

Kreon drives (they need to be flashed with custom firmware):
Samsung SH-D162C = TSSTcorp TS-H352C
Samsung SH-D162D = TSSTcorp TS-H352D
Samsung SH-D163A = TSSTcorp TS-H353A
Samsung SH-D163B = TSSTcorp TS-H353B

@iR0b0t, maybe better to close registrations if you just accept anyone without reading their messages? 95% of new registrations never submit a dump anyway.