Redump Forum

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!

xTMODx wrote: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.

usurper wrote:could you please verify that the ISRC

Weird ISRC, but it's correct.

jhmiller wrote: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.

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

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

Jackal wrote:the last 2 SecuROM sectors

- fixed: the range of SeruROM sectors.

F1ReB4LL wrote: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

F1ReB4LL wrote: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.

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?

sarami wrote: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.

jhmiller wrote: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.

jhmiller wrote: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.

jhmiller wrote:Puzzle Bobble 4

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

jhmiller wrote: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.

jhmiller wrote:Death Crimson OX

I haven't bought it yet.

F1ReB4LL wrote: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.

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

I'll code it in the future.

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

Added in test version.

sarami wrote: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.

sarami wrote: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".

sarami wrote: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.