26 Topic by ajshell1

(1 replies, posted in General discussion)

So, I know that Redump's URL can be modified to filter discs based on certain criteria.

For example:

http://redump.org/discs/system/pc/ only displays PC dumps

http://redump.org/discs/dumper/ajshell1/ only displays my dumps

But some are a bit more hidden.

http://redump.org/discs/errors/null/ only shows discs without an error count

http://redump.org/discs/media/cd only displays discs on CDs.

http://redump.org/discs/region/U/ only shows US region discs.

http://redump.org/discs/language/ seems as though it can be used to filter languages, but I can't get it to work.

But there are a bunch of other search terms that don't seem to be documented anywhere.

For this reason, I think all sorting and filtering terms should be made publicly available somewhere.

Go to forum: General discussion

27 Reply by ajshell1

(3,516 replies, posted in General discussion)

Hey sarami. Did you ever address my recent post on SafeDisc? nightson has also talked to me recently, stating that he is getting the same issue.

Go to forum: General discussion

28 Reply by ajshell1

(3,516 replies, posted in General discussion)

I'm going to try dumping that disc with all of the other methods I can find, and then see what sarami has to say.

I finished that data dump. It doesn't match a dump that I made with an older version of DIC

EDIT: setting the drive speed to 4x seems to have fixed it. Yay!

And the dump that I made matches a dump with an older version of DIC.

Go to forum: General discussion

29 Reply by ajshell1

(3,516 replies, posted in General discussion)

reentrant wrote:

ajshell1: I have a weird theory. My Plextor on some discs with offset -153 gives me C2 errors with 24 bad bits (I know this is firmware bug). You on the other side have discs with 288 bits. When you add both you get 312 = value valid for SafeDisc. I think you might be experiencing similar bug but with different "pattern"...

Could you rip with non plextor drive and data command and /c2?

I'd be more than happy to. However, I'd like to confirm that I'm using the right command. I'm currently dumping it with this command:

discimagecreator data e "Battlefield 1942 - Complete Collection (USA) (Disc 4) (GCE-8483B)" 16 0 334273 /c2 /sf

The disc appears to have a final LBA of 334273, and the data command is apparently supposed to use the last LBA+1.

I'm asking if this is the right command because it's dumping SUPER SLOW with this command.

Also, I'm using an GCE-8483B drive, which EAC says has C2 support.

EDIT: To save people the effort of downloading my stuff, I use A PX-712A and the disc has a write offset of -12.

Go to forum: General discussion

30 Reply by ajshell1

(3,516 replies, posted in General discussion)

Hey Sarami. You know how I mentioned that problem with Startopia and the 288 bit C2 errors? I found another disc with the same issue.

This one looks like it has a few other C2 errors, so I'm going to try and polish it up a bit and see what happens. Here are the logs.

However, I would like to point out that the 288 bit error appears at sector 002462, which is before any other sectors with C2 errors appear.

Discs 1-3 of the set I'm dumping don't have this issue. I can't yet tell if discs 5-8 have this issue either.

Go to forum: General discussion

31 Reply by ajshell1

(7 replies, posted in General discussion)

WTF. I just managed to get Rogue Spear to dump properly.


I have no idea what caused this, but I won't look a gift horse in the mouth.

Go to forum: General discussion

32 Reply by ajshell1

(7 replies, posted in General discussion)

I was able to properly dump discs with both TS-H162C drives:

http://redump.org/discs/dumper/ajshell1/system/dc

Rippin Riders was dumped with my first drive, and Grandia II, San Francisco Rush 2049, and the almost-correct dump of Rogue Spear was dumped by my second drive.

In fact, I recently got a copy of http://redump.org/disc/5990/ and http://redump.org/disc/47415/ (thanks Sadikyo!) and I managed to dump them and get them to match the database somehow with my second drive.

Since then, I've been attempting to dump Rogue Spear again. We'll see what happens. Would the fact that it has 98 tracks make a difference?

Go to forum: General discussion

33 Reply by ajshell1

(7 replies, posted in General discussion)

More info:

I've burned a new trap disc. Now, both drives go past the CD-TEXT screen on Imgburn.

After this, I've noticed that DCDumper appears to make accurate dumps of sections 1-36, or from sector 044990 to sector 394815, or about 784 MB. Comparing the output of my new dump of Rogue Spear with the dump that I submitted to the database also seems to indicate that everything matches up until around the 784MB mark, whereafter the track 98 doesn't match any further.

As tracks 3 to 97 tracks on Rainbow Six: Rogue Spear are 646 MB, and that the audio tracks are identical in the Euro dump and my dump, I've come to the conclusion that my drives apparently dump most of a GD-ROM correctly, and then somehow decides to fuck everything up and read into the low density sector.

Bizarrely, the remaining sections give a consistent hash output. Which indicates that the drive is getting a consistent read somehow from the low density section. I have no idea how this is happening.
Related:

jhmiller says that his Audio Trap Disc shows this in ImgBurn:

Disc Information:
Status: Complete
State of Last Session: Complete
Erasable: No
Sessions: 1
Sectors: 549.151
Size: 1.124.661.248 bytes
Time: 122:04:01 (MM:SS:FF)
Supported Read Speeds: 4x; 8x; 12x; 16x; 24x; 32x

TOC Information:
Session 1... (LBA: 0 / 00:02:00)
-> Track 01  (Audio, 122:02:01, LBA: 0 / 00:02:00)
-> LeadOut  (LBA: 549151 / 122:04:01)

Track Information:
Session 1...
-> Track 01 (LTSA: 0, LTS: 549151, LRA: 0)
I just burned a new Audio Trap Disc, and this is what I get:





Disc Information:
Status: Complete
State of Last Session: Complete
Erasable: No
Sessions: 1
Sectors: 549,151
Size: 1,124,661,248 bytes
Time: 122:04:01 (MM:SS:FF)
Supported Read Speeds: 4x, 8x, 12x, 16x, 24x, 32x

TOC Information:
Session 1... (LBA: 0 / 00:02:00)
-> Track 01  (Audio, 122:02:01, LBA: 0 / 00:02:00)
-> LeadOut  (LBA: 549151 / 122:04:01)

Track Information:
Session 1...
-> Track 01 (LTSA: 0, LTS: 549151, LRA: 10616832)(edited)
Other than some cosmetic differences regarding he proper punctuation to use to mark the decimal point, the only difference is the "LRA" at the end.

olofolleola4 says that "LRA" stands for "Last Recorded Address". Does this make a difference?

Go to forum: General discussion

34 Topic by ajshell1

(7 replies, posted in General discussion)

I have two TS-H352C drives, and they both have gotten into a state where they won't work with the audio trap disc anymore. Regular CDs and DVDs work fine (especially Xbox DVDs, so they aren't completely useless yet). They just start reading into the LD zone after a length of time.

Picture:

https://cdn.discordapp.com/attachments/ … 214806.jpg

If you know anything about where the laser is and how a DC disc is laid out, you would know that this is reading in the low density section of the disc. In other words, a lot of garbage.

If I stick the Audio trap Disc into the drive in it's current state and open ImgBurn, ImgBurn won't even get to the "read" screen properly. It just gets stuck on "reading CD-TEXT".
However, doing the swap process and then trying to dump it with DIC w results in a dump that finishes, but only track 3 matches, the rest is just garbage.

It can still read regular DVDs properly. Since this is a Kreon drive, it can still dump Xbox discs.

Currently, I had managed to get a portion of http://redump.org/disc/54033/ to dump properly, but the data track at the end is messed up. In addition, sadikyo has agreed to send me some undumped DC discs.

With this in mind, I WILL get that previously mentioned disc dumped properly, and I WILL properly dump sadikyo's discs. However, if anyone has any ideas on how to fix one of my my TS-H352C drives, you would be saving me the $20 it would take to buy a TS-H353A.

Go to forum: General discussion

35 Reply by ajshell1

(3,516 replies, posted in General discussion)

sarami wrote:

http://forum.redump.org/post/58182/#p58182
"312" sectors are intentional c2 errors, but I don't know all intentional errors are 312.
At least please check rereading at 10000 times.

discimagecreator cd f Startopia (USA) 32 /c2 10000 /d8 /sf

No. I won't do that. I've seen another disc with SafeDisc Lite that did the same thing. I won't wear out my Plextor's laser any more.

Go to forum: General discussion

36 Reply by ajshell1

(3,516 replies, posted in General discussion)

Okay sarami, here are some logs:

This disc has some additional damage to it, but I don't think that's what is causing the attempted rereads on sectors with SafeDisc. I've seen that 288 bit error thing occur in other discs, but I don't remember which discs.

Go to forum: General discussion

37 Reply by ajshell1

(3,516 replies, posted in General discussion)

Hey Sarami. I've had a problem with some PC games with SafeDisc. Occaisonally, DIC will report an error count of 288 in a SafeDisc sector, and will attempt to reread it over and over again, never succeeding.

Let me know if you want some specific examples.

Go to forum: General discussion

38 Reply by ajshell1

(3,516 replies, posted in General discussion)

Hey sarami, what happened to the /r command? Using the latest test version you posted, it says "Unknown Option: [/r]"

I'm trying to dump a disc with Tages.

Go to forum: General discussion

39 Reply by ajshell1

(14 replies, posted in General discussion)

I agree with user7/dizzzy's suggestions.

Also, I want a (USA, Australia) region added. There are NUMEROUS Maxis PC games that were dumped in the USA and Australia that are incorrectly listed as "World". This is completely unacceptable. I have a USA copy of Marble Drop that matches, http://redump.org/disc/6064/, and I deliberately haven't posted a verification for it because you guys would change it to "World".

Go to forum: General discussion

40 Reply by ajshell1

(3,516 replies, posted in General discussion)

sarami wrote:

http://forum.redump.org/post/62037/#p62037

I built it on WSL (Windows Subsystem for Linux) using ubuntu 18.04 LTS x64.

No makefile. If you want it, please make it yourself.

How did you build it without a makefile?

Go to forum: General discussion

41 Topic by ajshell1

(1 replies, posted in General discussion)

I recently just got done dumping the US version of this: http://redump.org/disc/47741/

This is a game with 98 tracks.

After using ICE.exe on a dump created by DCDumper, I've found that a cuesheet is produced for the dump, but no .gdi file.

I don't own a Dreamcast console, so I need a .gdi file to test the image in an emulator to check for languages (and to make sure that my dump is actually good), because I suspect that my dump is wrong.

I figured out how to make a .gdi file for my dump of Grandia II, but that one has only 5 tracks. I ABSOLUTELY refuse to manually create a 98 track .gdi file by hand. Does anyone have a tool that can create it for me?

Also, I'm not using DIC because it isn't currently working with my DC dumping disc drive.

Go to forum: General discussion

42 Reply by ajshell1

(3,516 replies, posted in General discussion)

sarami wrote:
ajshell1 wrote:

I've dumped the game disc four times so far

Perhaps, your disc has c2 errors.


Possibly, but I just managed to get DCDumper and CDTool to produce output tracks with identical checksums. I'd be willing to bet that this is a result of my TS-H352C not having C2 support, while DIC seems to depend heavily on C2 support.

Go to forum: General discussion

43 Reply by ajshell1

(3,516 replies, posted in General discussion)

So, how exactly do I find that value out? I already dumped it as a CD earlier.

Go to forum: General discussion

44 Reply by ajshell1

(3,516 replies, posted in General discussion)

What's up with the Dreamcast dumping command in Discimagecreator?

I've dumped the game disc four times so far, and this is what I found in the _EdcEcc.txt file:

Dump 1:
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 2
    Sector: 59634, 59652,
[ERROR] Number of sector(s) where sync(0x00 - 0x0c) is invalid: 1
    Sector: 59635,
Total errors: 3
Total warnings: 0

Dump 2:
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 2
    Sector: 124301, 124321,
[ERROR] Number of sector(s) where sync(0x00 - 0x0c) is invalid: 1
    Sector: 124302,
Total errors: 3
Total warnings: 0

Dump 3:
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 1
    Sector: 59615,
[ERROR] Number of sector(s) where sync(0x00 - 0x0c) is invalid: 1
    Sector: 59616,
Total errors: 2
Total warnings: 0

Dump 4:
[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 1
    Sector: 59616,
[ERROR] Number of sector(s) where sync(0x00 - 0x0c) is invalid: 1
    Sector: 59617,
Total errors: 2
Total warnings: 0


Also, this is what my GDI output file looks like:
5
1     0 4 2352 "Grandia II (USA) (Dump 3) (Track 1).bin" 0
2 [fix] 0 2352 "Grandia II (USA) (Dump 3) (Track 2).bin" 0
3 45000 4 2352 "Grandia II (USA) (Dump 3) (Track 3).bin" 0
4 49871 0 2352 "Grandia II (USA) (Dump 3) (Track 4).bin" 0
5 50397 4 2352 "Grandia II (USA) (Dump 3) (Track 5).bin" 0

I don't think that "[fix]" is supposed to be there.

What's going on?

EDIT: I'm using a TS-H352C, which AFAIK doesn't have C2 support. (using the most up-to-date non-Kreon firmware.

Go to forum: General discussion

45 Reply by ajshell1

(3,516 replies, posted in General discussion)

sarami, I'm concerned about the speed at which DIC calculates the hash values after dumping.

I ran the windows version of rhash to calculate the crc32, md5, and sha1 value of a .bin file as soon as I saw that DIC had finished calculating the hash of the .img file. (using the command "rhash -C -M -H filename.bin"

On my super-low end CPU of my dumping machine, rhash took 36 seconds to calculate the hash values.

DIC took 3 minutes and 16 seconds.

Granted, this won't be an issue any more once DIC for Linux is mature enough, because my Linux PC is pretty beefy. However, this still might be something work on in the future.

Thanks again for working on the Linux port by the way, you have my eternal gratitude for that!

Go to forum: General discussion

46 Reply by ajshell1

(53 replies, posted in General discussion)

Results:

https://cdn.discordapp.com/attachments/ … 062411.jpg

Also, the game itself has English, Spanish, and French language support.

Go to forum: General discussion

47 Reply by ajshell1

(53 replies, posted in General discussion)

I'll test it out. I'll try to give you the results tomorrow.

Go to forum: General discussion

48 Reply by ajshell1

(53 replies, posted in General discussion)

I just finished dumping my (formerly user7/dizzzy's) copy of Stealth + Wipeout Pure.

Here are the output hashes:

ULUS-10058.iso  5ef803ca  386bfb26919a8f95d7300227b5b3d215  ea642afa63a3c36b7f55c407484ef4dc030cd5f2

Now what?

Also, sarami, you need to make this thing dump faster. It's too slow currently. It took several hours for my copy to dump.

(I'm attaching all output files except the 0B _mainError.txt file (because I don't want to upload an empty file tongue).

Go to forum: General discussion

49 Reply by ajshell1

(53 replies, posted in General discussion)

It's not working on my hacked PSP3000 with 660 PRO-C.

Pressing the Note button does nothing, and the eboot version cannot be started because the data is corrupt.

Go to forum: General discussion

50 Reply by ajshell1

(3,516 replies, posted in General discussion)

By the way sarami, could you make the _disc.txt file specifically mention the layerbreak at some point?

Please make it say something like "Layerbreak: 1336160" somewhere in the output files.

This is a required field for DVD-9 submissions, so this should be "idiot proof".

Go to forum: General discussion