26

(7 replies, posted in General discussion)

It seems as though I'm a mod now.

Thank you.

do_0m wrote:

Was there a third user in the nNASOS thread trying to implement their own version? I can't remember.


nNASOS is a thing.

https://cdn.discordapp.com/attachments/ … S_v1.8.zip

F1ReB4LL wrote:
Jackal wrote:

That's just a technicality. If you create 2 different sets of dump files with different .cue and filenames, and 2 archives for a single disc, this will be a bigger issue than what we have now.

A single set, a single archive, just 2 cues.

Like, Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA).LD.cue with the tracks 1 and 2 and Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA).HD.cue with the tracks 3, 4 and 5. You can mount the LD to some virtual drive and work with it exactly like you would work with a normal GD inserted into a PC drive. Emu devs may support either running the HD cue only or some kind of auto-mounting the LD cue additionally when the HD cue is selected.


So like this?

My concern is that "Track 3" is actually "Track 1" in the HD cue. That'll get confusing fast.

29

(2,747 replies, posted in General discussion)

Test complete. The new dump with that test version of DIC produces a bin file with the exact same checksum as an older version of DIC, and it doesn't reread all those errors. Thank you very much.

30

(2,747 replies, posted in General discussion)

I think I found an issue with SafeDisc Lite discs (or at least with an undumped copy of MS Train Simulator I got recently). DIC recognizes the protection when using the /sf flag, and all the errors that show up are 312 bit, but when the last sector is dumped, DIC decides to try and reread all the sectors that have intentional errors. And when it reaches the maximum number of retries for one of those errored sectors, DIC doesn't cancel the dump like normal, but then proceeds to reread the next intentionally errored sector the same way. When the last sector is done, it just descrambles the .scm like normal.

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.

32

(2,747 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.

33

(2,747 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.

34

(2,747 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.

35

(2,747 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.

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.

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?

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?

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.

40

(2,747 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.

41

(2,747 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.

42

(2,747 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.

43

(2,747 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.

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

45

(2,747 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?

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.

47

(2,747 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.

48

(2,747 replies, posted in General discussion)

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

49

(2,747 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.

50

(2,747 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!