DiscImageCreator

[usurper]

Sarami, could you please verify that the ISRC from Suffering, The (USA) (Disc 1) and Suffering, The (USA) (Disc 2) is correct? Subs and logs have been uploaded here and here.

Thanks!

[sarami]

can you please check this errors

I've known this issue. It needs css authentication, I think.
Method 1:
1:play DVD for a few seconds with windows media player or vlc media player etc.
2:run DIC
Method 2:
run isobuster or imgburn etc.

could you please verify that the ISRC

Weird ISRC, but it's correct.

I try uncont times and always get the error in the section 35.
And with the other disc, the same. I get the error in the same section 35.

I'll get it in the near future.

[Jackal]

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

[F1ReB4LL]

/viewtopic.php?p=42084#p42084 -- any chance to add this disc type for offset autodetection? Somewhat similar to Jaguar CD.

[sarami]

the last 2 SecuROM sectors

- fixed: the range of SeruROM sectors.

any chance to add this disc type for offset autodetection? Somewhat similar to Jaguar CD.

I'll buy "Karat PS-you Action Replay Higi Code" to test.

EDIT

As far as I understand, all our 'PSX-CDDA' dumps belong to the same family and the first track should start with "G.THORNTON". So far:

I bought "Karat PS-you Action Replay Higi Code CD Vol. 3" today and confirmed "G.THORNTON" in 1st track.
----
1st non-zero byte ("G.THORNTON") of 1st track: +1059
1st non-zero byte of 2nd track: +1049
1st non-zero byte of 3nd track: +1045
:
:
If "G.THORNTON" is based as the offset, some byte of 2nd track belong to 1st track and some byte of 3rd track belong to 2nd track. In short, dic needs to search the 1st non-zero byte of all track and adopt the smallest value, I think.

[jhmiller]

I bought a reader TS-H352C (DELH, FW=DE02, Ver C, December 2005) to dump Dreamcast games.
This unit don't support C2, is OK dump DC games without c2 option ?

The command used: DiscImageCreator gd unit name.bin 8 /q

Death Crimson OX (T-23202M) - (I have 2 copies of this game):
Both of them fail at sector 534094.
Logs of the dump from disc 1: https://mega.nz/#!VEkRyabQ!Cy1M8Z01E6sL … ggFoNri46s
Logs of the dump from disc 2: https://mega.nz/#!kZdjSDbT!FAvOQVd54b1G … dtvDOAjPMY


Puzzle Bobble 4 (T-42301M) - (I have 2 copies of this game):
The dump seems correct from the "disc 1".
Logs of the dump from disc 1: https://mega.nz/#!8YtWSDgQ!9YHwWSCzUzTL … fAQe2j_H6E

Can you confirm this?

[F1ReB4LL]

If "G.THORNTON" is based as the offset, some byte of 2nd track belong to 1st track and some byte of 3rd track belong to 2nd track. In short, dic needs to search the 1st non-zero byte of all track and adopt the smallest value, I think.

Disagree. For Saturn overlapping tracks are common, so we can't assume it doesn't happen here.

[F1ReB4LL]

Logs of the dump from disc 1: https://mega.nz/#!VEkRyabQ!Cy1M8Z01E6sL … ggFoNri46s
Logs of the dump from disc 2: https://mega.nz/#!kZdjSDbT!FAvOQVd54b1G … dtvDOAjPMY
Logs of the dump from disc 1: https://mega.nz/#!8YtWSDgQ!9YHwWSCzUzTL … fAQe2j_H6E

So, you can provide subs now?

Sarami: I think it's better to generate the .cue variant as well. All the redump gdis are incorrect, anyway.
Also, scrambled image checksum isn't supported for GDs? T-42301M_disc.txt => only the descrambled image checksum there.

[sarami]

This unit don't support C2, is OK dump DC games without c2 option ?

I also have same drive and same firmware, and it seems this drive doesn't support c2.
So, it's important to dump by the two supported drive. This is same for dcdumper. Because it also doesn't read c2.

Puzzle Bobble 4

I bought this. It takes 3-6 days to get it.

Can you confirm this?

As far as seeing the log, data sector is ok, but I can't verify the audio sectors because there isn't ecc/edc in these sectors.

Death Crimson OX

I haven't bought it yet.

For Saturn overlapping tracks are common

I fixed my comment.
If "G.THORNTON" is based as the offset, some byte of 2nd track belong to the pregap of the 2nd track.

Maybe It's common for saturn, but I think it isn't common for other discs. The pregap area typically have all zero except for intentional data. e.g some CD-I discs or hidden track of some audio discs.
I don't think the program data of these discs exists in the pregap area. For saturn, I think it's unintentional that the program data exists in the pregap area.

To begin with, is it true that "G.THORNTON" is based as the offset? What are the reasons? Nobody can know how many offsets audio disc has originally.
If the data is shifted in the pregap area (or former/latter track) by the offset, it should be shifted out of this area like myst(demo) of atari jaguar cd.

I think it's better to generate the .cue variant as well.

I'll code it in the future.

Also, scrambled image checksum isn't supported for GDs?

Added in test version.

[F1ReB4LL]

Maybe It's common for saturn, but I think it isn't common for other discs.

Common for PC, Mega CD, FM-Towns, PC-98.

To begin with, is it true that "G.THORNTON" is based as the offset? What are the reasons? Nobody can know how many offsets audio disc has originally.

But it's not an audio CD, it's a program CD mastered/burned as audio. I see no reason to intentionally include empty data before "G.THORNTON".

I don't think the program data of these discs exists in the pregap area. For saturn, I think it's unintentional that the program data exists in the pregap area.

Let's wait for more dumps, then.