676

(3,493 replies, posted in General discussion)

iR0b0t wrote:
LoStraniero91 wrote:

I have a DVD IBM PC game with what could be Ring Protech. Any advice how to dump it?

DIC does not support those discs yet, it will abort reading as soon as protected area is reached.

One could use isobuster and replace those sectors by '0x55' bytes but we have not deceided yet if it should be '0x55's or can be '0x00's for example. If we consider '0x55' bytes then sarami could probably code DIC with that.

My talk to sarami about one of those discs:
http://forum.redump.org/post/59799/#p59799
http://forum.redump.org/post/59854/#p59854
http://forum.redump.org/post/60084/#p60084
I never came back to this topic though.

Test version
20190222 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190222 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar
added: /sf flag in dvd command
And updated test branch.

user7 wrote:

Sarami can you give me an example command for dumping Mil-CD?

Same as normal CD. There's nothing special. If you want to get the lead-out of 1st session and the lead-in of 2nd session, you can use /ms flag.

But admin's still have been talking about multi-session cue.

677

(3,493 replies, posted in General discussion)

sarami wrote:

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

I got VideoNow Color, Jr and XP and confirmed these discs also have "81 E3 E3 C7 C7 81 81 E3". That is, latest test version supports all(?) VideoNow discs.

678

(3,493 replies, posted in General discussion)

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

679

(3,493 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.

680

(3,493 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.

681

(3,493 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

682

(3,493 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.

683

(3,493 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.

684

(3,493 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.

685

(3,493 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.

686

(3,493 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?

687

(3,493 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.

688

(3,493 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?

689

(3,493 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.

690

(3,493 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?

691

(3,493 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?

692

(3,493 replies, posted in General discussion)

Thx, it seems good.

693

(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

694

(3,493 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

695

(3,493 replies, posted in General discussion)

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

696

(3,493 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.

697

(3,493 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

698

(3,493 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

699

(3,493 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.

700

(3,493 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)