676 Reply by sarami

(3,488 replies, posted in General discussion)

Thanks. Uploaded. http://www.mediafire.com/file/uw3e03kdk … x_test.tar

Go to forum: General discussion

677 Reply by sarami

(3,488 replies, posted in General discussion)

Test version
20190210 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190210 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

sarami wrote:

Perhaps this problem occurs due to reread, so I'll abort the program not to create the bad dump

Added this.

usurper wrote:

My disc is brand new!

It doesn't matter about this problem whether brand new or not.

F1ReB4LL wrote:

edccchk and CDMage show 314 errors, DIC shows 313 errors, error count bug?

Maybe so. Please try redumping by latest test version if possible.

Go to forum: General discussion

678 Reply by sarami

(3,488 replies, posted in General discussion)

nightson wrote:

Tested working.

Thanks tested.

LBA[291610, 0x4731a], MSF[64:50:10], mode 1 Invalid mode: [e1]
[ERROR] Number of sector(s) where bad MSF: 1
    Sector: 291611, 
[ERROR] Number of sector(s) where mode is invalid: 1
    Sector: 291610, 
Total errors: 2
Total warnings: 0

It worked as I intended.



usurper wrote:

I have dumped my brand new copy of this disc and I got a different hash on Track 4 than Maki.
However Maki didn't got a C2 error on his dump. Please check attached logs of Maki and me.

There is a same problem in your track 04. (subQ is all zero)

sarami wrote:
F1ReB4LL wrote:

DIC dumps one of the audio tracks wrong, another cache issue?

I'm not sure but I can only say that 202328 Q-channel is all zero. It's unusual.

LBA[202328, 0x31658]: Track[10]: SubQ[12]:Adr[0] -> [0x01]
LBA[202328, 0x31658]: Track[10]: SubQ[13]:TrackNum[00] L:[781] -> [10], L:[688]
LBA[202328, 0x31658]: Track[10]: SubQ[14]:Idx[00] -> [01], L:[781]
LBA[202328, 0x31658]: Track[10]: SubQ[15-17]:PrevRel[14626, 03:15:01], Rel[0, 00:00:00] -> [14627, 03:15:02], L:[1047]
LBA[202328, 0x31658]: Track[10]: SubQ[19-21]:PrevAbs[202477, 44:59:52], Abs[0, 00:00:00] -> [202478, 44:59:53]
LBA[202328, 0x31658]: Track[10]: SubQ[22]:CrcHigh[0000] -> [0x5e]
LBA[202328, 0x31658]: Track[10]: SubQ[23]:CrcLow[0000] -> [0xcf]
LBA[248743, 0x3cba7]: Track[04]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
LBA[248743, 0x3cba7]: Track[04]: SubQ[12]:Adr[0] -> [0x01]
LBA[248743, 0x3cba7]: Track[04]: SubQ[13]:TrackNum[00] L:[781] -> [04], L:[688]
LBA[248743, 0x3cba7]: Track[04]: SubQ[14]:Idx[00] -> [01], L:[781]
LBA[248743, 0x3cba7]: Track[04]: SubQ[15-17]:PrevRel[1937, 00:25:62], Rel[0, 00:00:00] -> [1938, 00:25:63], L:[1047]
LBA[248743, 0x3cba7]: Track[04]: SubQ[19-21]:PrevAbs[248892, 55:18:42], Abs[0, 00:00:00] -> [248893, 55:18:43]
LBA[248743, 0x3cba7]: Track[04]: SubQ[22]:CrcHigh[0000] -> [0x8d]
LBA[248743, 0x3cba7]: Track[04]: SubQ[23]:CrcLow[0000] -> [0xc2]

Perhaps this problem occurs due to reread, so I'll abort the program not to create the bad dump in next test version if this problem occurs.

Go to forum: General discussion

679 Reply by sarami

(3,488 replies, posted in General discussion)

sarami wrote:

291610 is missing. This is a bug of EccEdc.exe. I'll fix it.
Last sector is correct as ecc/edc, but MSF is incorrect. I'll add this bad MSF as an error.

Test version
20190208 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190208 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

Go to forum: General discussion

680 Reply by sarami

(3,488 replies, posted in General discussion)

Thanks.

LBA[291609, 0x47319], MSF[64:50:09], mode 1
LBA[291461, 0x47285], MSF[64:48:11], mode 1

291610 is missing. This is a bug of EccEdc.exe. I'll fix it.
Last sector is correct as ecc/edc, but MSF is incorrect. I'll add this bad MSF as an error.

Go to forum: General discussion

681 Reply by sarami

(3,488 replies, posted in General discussion)

nightson wrote:

The test version didn't output the  (Subs indexes) files but the bin file has the same hash as before.

Logs and bin of last 2 sectors and scm of last 2 sectors, please.

Go to forum: General discussion

682 Reply by sarami

(3,488 replies, posted in General discussion)

nightson wrote:

Any idea what caused the problem?

Try the latest test version and re-report.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file

nightson wrote:

DIC found no C2 errors but CDmage reports 2 errors at the very end.

Perhaps, last 2 sectors are mastering error.

nightson wrote:

I tried to dump it with two drives (PX-760 and PX-755) at both 4X and 8X but got the same result.

Try 12x, 16x, 20x, 24x, 28x, 32x, 40x and 48x. Low-speed is not always good.

Go to forum: General discussion

683 Reply by sarami

(3,488 replies, posted in General discussion)

It seems Monsters, Inc. Scream Team Training is SecuROM. Is Monsters, Inc: Scare Island SecuROM? I saw this pattern for the first time.

Go to forum: General discussion

684 Reply by sarami

(3,488 replies, posted in General discussion)

claunia wrote:

VideoNow is a completely different format. I shall receive 3 discs soon.
VideoNow Color and VideoNow Jr. are the same format, only difference is the materials that make the disc. Jr is flexible, for little children security.

Thanks info. I ordered Color, Jr, and XP by amazon.

F1ReB4LL wrote:

DIC dumps one of the audio tracks wrong, another cache issue?

I'm not sure but I can only say that 202328 Q-channel is all zero. It's unusual.

LBA[202328, 0x31658]: Track[10]: SubQ[12]:Adr[0] -> [0x01]
LBA[202328, 0x31658]: Track[10]: SubQ[13]:TrackNum[00] L:[781] -> [10], L:[688]
LBA[202328, 0x31658]: Track[10]: SubQ[14]:Idx[00] -> [01], L:[781]
LBA[202328, 0x31658]: Track[10]: SubQ[15-17]:PrevRel[14626, 03:15:01], Rel[0, 00:00:00] -> [14627, 03:15:02], L:[1047]
LBA[202328, 0x31658]: Track[10]: SubQ[19-21]:PrevAbs[202477, 44:59:52], Abs[0, 00:00:00] -> [202478, 44:59:53]
LBA[202328, 0x31658]: Track[10]: SubQ[22]:CrcHigh[0000] -> [0x5e]
LBA[202328, 0x31658]: Track[10]: SubQ[23]:CrcLow[0000] -> [0xcf]

Also I ordered this by amazon to test. Btw, can subdump dump this sector correctly without fixing?

Go to forum: General discussion

685 Reply by sarami

(3,488 replies, posted in General discussion)

As you say, it seems my VideoNow disc has the logo of 891 sectors.
And my app searches "81 E3 E3 C7 C7 81 81 E3".
https://imgur.com/bG2k7T1
Perhaps, each track of my disc starts from these bytes order.
I don't know if all VideoNow discs (VideoNow, VideoNow Color, VideoNow Jr., VideoNow XP) start from these bytes.

Go to forum: General discussion

686 Reply by sarami

(3,488 replies, posted in General discussion)

F1ReB4LL wrote:

So, there's a common bug in C2 errors detection? Some of the other cases were mentioned here: http://forum.redump.org/topic/18736/jac … re-adding/

same.
http://forum.redump.org/post/65033/#p65033
http://forum.redump.org/post/65045/#p65045

Btw, wrong offset of VideoNow disc was solved?

Go to forum: General discussion

687 Reply by sarami

(3,488 replies, posted in General discussion)

F1ReB4LL wrote:

http://forum.redump.org/topic/20666/seg … -shock-us/ -- disc 1 is dumped wrong.

subchannel of 1st sector is wrong.
_subError.txt

LBA[000000, 0000000]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
LBA[000000, 0000000]: Track[01]: SubQ[19-21]:PrevAbs[149, 00:01:74], Abs[149, 00:01:74] -> [150, 00:02:00]
LBA[000000, 0000000]: Track[01]: SubQ[22]:CrcHigh[0x04] -> [0x6f]
LBA[000000, 0000000]: Track[01]: SubQ[23]:CrcLow[0xa1] -> [0xe1]

_disc.txt

========== LBA[000000, 0000000]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P FF FF FF FF FF FF FF FF FF FF FF FF
    Q 41 01 01 00 00 00 00 00 03 00 28 32
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 01 00 00 00
    T 00 00 00 00 00 00 00 00 01 00 00 00
    U 00 00 00 00 00 00 00 00 01 00 00 00
    V 00 00 00 00 00 00 00 00 01 00 00 00
    W 00 00 00 00 00 00 00 00 01 00 00 00

Please try to redump it with different drive speed.

Go to forum: General discussion

688 Reply by sarami

(3,488 replies, posted in General discussion)

Jackal wrote:

Previously, this game was affected: http://redump.org/disc/46022/

http://forum.redump.org/topic/20845/ibm … fy-6x-new/
Fallout 4 : https://mega.nz/#F!wc4wnYSa!kpLgUsLXoEPv0BVO9pGUSw

It seems his Fallout 4 is no problem.

Jackal wrote:

There seem to be no errors, it just forgets to dump layer2.

Does it always occur?

Go to forum: General discussion

689 Reply by sarami

(3,488 replies, posted in General discussion)

Jackal wrote:

There's a problem where DIC is only dumping the first layer for double layer games.

Previously, this game was affected: http://redump.org/disc/46022/

And now another disc from Kludge. Attached some logs.

I really hope there aren't any other bad dumps in the db because of this bug hmm

What error occurs?

Go to forum: General discussion

690 Reply by sarami

(3,488 replies, posted in General discussion)

Thx, it seems good.

Go to forum: General discussion

691 Reply by sarami

(3 replies, posted in General discussion)

wiggy2k wrote:

Am I to assume this is bad?

Perhaps dumping is good. DIC tries to reread at 5 times when reads DVD and reading error occurs. 1st reading was bad but 2nd reading was good.

added: rereading message on cmd-line screen. http://www.mediafire.com/file/eq80y20l9 … st.7z/file

Go to forum: General discussion

692 Reply by sarami

(3,488 replies, posted in General discussion)

Thanks test but problems still exist.

LBA[124763, 0x1e75b]: Track[48]: Subchannel & TOC doesn't sync. LBA on TOC[111288, 0x1b2b8], prevIndex[00]
LBA[124763, 0x1e75b]: Track[48]: Index is changed from [00] to [01] [L:966]

LBA[199341, 0x30aad]: Track[55]: Subchannel & TOC doesn't sync. LBA on TOC[189939, 0x2e5f3], prevIndex[00]
LBA[199341, 0x30aad]: Track[55]: Index is changed from [00] to [01] [L:966]

Reuploaded.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file

Go to forum: General discussion

693 Reply by sarami

(3,488 replies, posted in General discussion)

2018-05-22 is no problem. 2018-05-23 - 2019-01-03 is bad.

Go to forum: General discussion

694 Reply by sarami

(3,488 replies, posted in General discussion)

F1ReB4LL wrote:
sarami wrote:

fixed: subs indexes if sub vs. toc is desync http://forum.redump.org/topic/20625/tur … r-lair-us/

What was wrong with it and what exactly was fixed?

INDEX of (Subs indexes).cue and (Subs indexes)_img.cue was incorrect.

Go to forum: General discussion

695 Reply by sarami

(3,488 replies, posted in General discussion)

Test version
20190115 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190115 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

fixed: subs indexes if sub vs. toc is desync http://forum.redump.org/topic/20625/tur … r-lair-us/
fixed: /74 is only used by swap command

Go to forum: General discussion

696 Reply by sarami

(3,488 replies, posted in General discussion)

Test version
20190103 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190103 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

fixed: detecting smartE

Go to forum: General discussion

697 Reply by sarami

(3,488 replies, posted in General discussion)

ajshell1 wrote:

I'd just like to point out that the most recent versions of DIC I tested (The stable one and test version 20181116 95206) still don't detect the SmartE protection on http://redump.org/disc/38957/.

All logs of your smartE discs, please.

Jackal wrote:

Does your Colin McRae Rally 2 disc also have -59 in one mode?

According to disc.txt, Colin McRae Rally 2.0 and Diablo II: Lord of Destruction have incorrect main-channel(all zero) on LBA 0 if OpCode[0xd8]: SubCode[0] is used.
SubCode[2] and SubCode[8] are no problem. I think this is a bug of plextor and perhaps this occurs on 99 modified SecuROM discs only.

Also I tried 'cdtoimg d8 hacked' for Colin McRae Rally 2.0. 2 files are uploaded. http://www.mediafire.com/file/763drz13a … mr.7z/file

Btw, old plextors have similar issue about drive offsets. These issues occur on all discs.

  PLEXTOR PX-W820T  : +354(subch is 0x02), +355(subch is 0x00)
  PLEXTOR PX-W8220T : +354(subch is 0x02), +355(subch is 0x00)
  PLEXTOR PX-W124S  : +942(subch is 0x02), +943(subch is 0x00)
  PLEXTOR PX-W1210S : +686(subch is 0x08), +98(subch is 0x00)
  PLEXTOR PX-W1610TA: +686(subch is 0x02), +98(subch is 0x00)
  PLEXTOR PX-W2410TA: +686(subch is 0x02), +98(subch is 0x00)
  PLEXTOR PX-320A   : +686(subch is 0x02), +98(subch is 0x00)
Jackal wrote:

I dont know if this also affects discs with +588 offset which should be 0? Many discs have +588.

Sega Saturn discs of +588 offset have a duplicated sector in lead-in. Due to this sector, the offset is shifted by 1 sector. If you worry about it, you can check the lead-in sectors.

Go to forum: General discussion

698 Reply by sarami

(3,488 replies, posted in General discussion)

Jackal wrote:

So is it safe to assume that all discs in the database with -59 offset are actually -647, and +576 are actually -12?
Is it possible that other offsets are also affected?

I'm not sure about it, but many sony dadc discs have -647. At least, I hope all 99 modified SecuROM discs are dumped again to get _disc.txt.

Jackal wrote:

And securom data remains the same? (the test version produces the same data)

SubCode[0] dumps only main-channel. dic only uses this to output offsets in _disc.txt. No problem about sub-channel.
Or does this question mean that SecuROM sector 157 haven't fixed yet?


Jackal wrote:

And what about audio tracks that are dumped with -59 offset? (I'm not sure if there are any)

Perhaps main-channel is shifted for 1 sector if discs are dumped by old method (isobuster+eac, perfectrip+eac)

Go to forum: General discussion

699 Reply by sarami

(3,488 replies, posted in General discussion)

sarami wrote:
FatArnold wrote:

Seems to be a bug with the Linux DIC. No dat is created.

Windows build uses xmllite, but this library doesn't support other OS, so linux build hasn't supported to output the xml doc yet, not bug.

20181229 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar
added: output dat (tinyxml2 is used.)

Go to forum: General discussion

700 Reply by sarami

(3,488 replies, posted in General discussion)

Uploaded. http://www.mediafire.com/file/eq80y20l9 … st.7z/file But I haven't tested yet because I don't have same type of SecuROM.

Jackal wrote:

- Could the write offset of +576 be wrong? it's -12 plus 588 samples (1 sector). I've never seen this offset before.

Colin McRae Rally 2.0 http://redump.org/disc/31587/
This disc has also same issue.
1. OpCode[0xd8]: SubCode[0] shows -59.
2. OpCode[0xd8]: SubCode[2] shows -647.
3. OpCode[0xd8]: SubCode[8] shows -647.

I think -647 is correct.

Go to forum: General discussion