W8. I have found where the problem is. The drive returns the data that is sometimes shifted by 1 sector.

Look at those 2 dumps:
lgcache_all_0_378251_OK - cache dump starting with sector 378251. It's good cache.
lgcache_all_0_378251_BAD - cache dump starting with sector 378251. It's bad cache.

The data in bad one is shifted by 0xB00 bytes = 1 cache sector.

So the real solution has to analyze cache dump and find proper starting offset of data. Right now it assumes the offset is 0. In case of audio tracks MSF is not available so subchannel data has to be taken into account.

Post's attachments

lgcache_all_0_378251_BAD.bin 27.5 kb, 14 downloads since 2021-05-18 

lgcache_all_0_378251_OK.bin 27.5 kb, 14 downloads since 2021-05-18 

You don't have the permssions to download the attachments of this post.

2,877

We should really add to the guides to always dump CDs with audio tracks twice, preferably with separate drives. This would solve most issues.

But yeah, the cache reading is not ideal, and I really hope a better solution to reading the lead-out appears (through firmware modification perhaps).

PX-4824TA (offset +98), PX-755SA (offset +30), ASUS BW-16D1HT (offset +6)

2,878 (edited by NovaAurora 2021-05-23 19:19:50)

LoStraniero pointed me here.

Latest DIC included with MPF, only one sector being detected for SecuROM 4.84.76. Apparently it's supposed to have more than that. Here's the logs, I was told to attach those.

https://cdn.discordapp.com/attachments/ … T_logs.zip

Mastodon Page | YouTube Page
☆ ☆ ☆ PX-W4012TA ☆ PX-716A ☆ GGC-H20L ☆ BW-16D1HT ☆ ☆ ☆
Wii ☆ Wii U ☆ PSP 3K ☆ SOHD-167T ☆ Pioneer 209DBK ☆ TS-H352C

2,879 (edited by DopefishJustin 2021-05-24 01:02:48)

Jackal wrote:

DopefishJustin submitted a verification for this disc: http://redump.org/disc/65563/

The audio tracks all seem to the data starting 4 bytes later than Nexy's Plextor dump. So the offset difference is 1 sample.

It was dumped with ASUS BW-16D1HT . Logs: http://interbutt.com/misc/WARCRAFT2_X_logs.zip

We need to know if this is a problem with the ASUS drives. I've warned before that we can't really trust them because it's all just experimental and never fully tested, yet DIC keeps supporting them and now perhaps the DB is being filled with bad dumps that are done with these drives.

For the record I am using an LG WH16NS40 cross-flashed to ASUS firmware as described at http://wiki.redump.org/index.php?title= … 2_firmware

I dumped the disc twice before submitting and have now dumped it a third time, with matching results each time. The other two discs in the set also have audio tracks and matched existing dumps when read with the same drive: http://forum.redump.org/topic/36304/pc- … t-2-discs/

I have ordered a PX-W5224TA and will compare when that arrives.

2,880

NovaAurora wrote:

Latest DIC included with MPF, only one sector being detected for SecuROM 4.84.76. Apparently it's supposed to have more than that. Here's the logs, I was told to attach those.

Do you have other SecuROM discs? I hope you dump them.

sarami wrote:
NovaAurora wrote:

Latest DIC included with MPF, only one sector being detected for SecuROM 4.84.76. Apparently it's supposed to have more than that. Here's the logs, I was told to attach those.

Do you have other SecuROM discs? I hope you dump them.

In regards to this issue, Nova had dumped another SecuROM disc recently: http://forum.redump.org/topic/36287/ibm … world-usa/

Plextor: PX-W4012TU, PX-W5224TA, Premium, PX-716SA, PX-716A || LG GDR-8164B || Lite-On SOHD-167D
HP (Toshiba/Samsung): TS-H353A - Kreon FW || HP (Hitachi/LG): BH40N - crossflashed with LG BH16NS40 FW || Sony Optiarc AD-7280S

2,882 (edited by RevQuixo 2021-05-26 12:57:29)

Getting this error on a JagCD homebrew title:

LBA[1166880, 0x11ce20]: [F:ExecSearchingOffset][L:463]
    Opcode: 0xd8
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: d8, 00, 00, 11, ce, 20, 00, 00, 00, 01, 02, 00
dwBufSize: 2448

The disc is a CDR.  Using the latest DIC packed with MPF

2,883

Hey Sarami.

I ran into some issue when trying to capture the console output of DIC into a log file using the >.

Descrambling data sector of img:  10276/ 10297
Descrambling data sector of img:  10277/ 10297
Descrambling data sector of img:  10278/ 10297
Descrambling data sector of img:  10279/ 10297
Descrambling data sector of img:  10280/ 10297
Descrambling data sector of img:  10281/ 10297
Descrambling data sector of img:  10282/ 10297
DescrFILE: D:\Program\Media\Dumping\DiscImageCreator\20210401\1.img

Checking sectors:      0/ 10297
Checking sectors:      1/ 10297
Checking sectors:      2/ 10297
Checking sectors:      3/ 10297

.....


Checking sectors:  10293/ 10297
Checking sectors:  10294/ 10297
Checking sectors:  10295/ 10297
Checking sectors:  10296/ 10297
Checking sectors:  10297/ 10297
[NO ERROR] User data vs. ecc/edc match all
ambling data sector of img:  10283/ 10297

Descrambling data sector of img:  10284/ 10297
Descrambling data sector of img:  10285/ 10297
Descrambling data sector of img:  10286/ 10297
Descrambling data sector of img:  10287/ 10297
Descrambling data sector of img:  10288/ 10297
Descrambling data sector of img:  10289/ 10297
Descrambling data sector of img:  10290/ 10297
Descrambling data sector of img:  10291/ 10297
Descrambling data sector of img:  10292/ 10297
Descrambling data sector of img:  10293/ 10297
Descrambling data sector of img:  10294/ 10297
Descrambling data sector of img:  10295/ 10297


As you can see in the marked sections, some lines seem to be out of place. Is this a bug of DIC or the > redirect command?

Could you add the option to automatically saves the final console output to a log file when dumping is completed?

Like this:

N@N-PC D:\Program\Media\Dumping\DiscImageCreator\20210401
# DiscImageCreator.exe cd j HIOCTANE.bin 8 /c2 /log

HIOCTANE.log:

AppVersion
        x86, AnsiBuild, 20210401T101950
/c2 val1 was omitted. set [4000]
/c2 val2 was omitted. set [0]
CurrentDirectory
        D:\Program\Media\Dumping\DiscImageCreator\20210401
WorkingPath
         Argument: HIOCTANE.bin
         FullPath: D:\Program\Media\Dumping\DiscImageCreator\20210401\HIOCTANE.bin
            Drive: D:
        Directory: \Program\Media\Dumping\DiscImageCreator\20210401\
         Filename: HIOCTANE
        Extension: .bin
StartTime: 2021-05-30T18:19:58+0800
Set the drive speed: 1411KB/sec
This drive supports [OpCode: 0xd8, SubCode: 0]
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking reading lead-out -> OK
Checking SubQ adr (Track)  1/ 1
Checking SubRtoW (Track)  1/ 1
Checking Pregap sync, msf, mode (LBA)  -1497
Reading DirectoryRecord    7/   7
Set OpCode: 0xd8, SubCode: 8(Raw)
Checking SubQ ctl (Track)  1/ 1
Creating .scm (LBA)  10298/ 10298
No C2 errors
Copying .scm to .img
Descrambling data sector of img:  10297/ 10297
Exec ""D:\Program\Media\Dumping\DiscImageCreator\20210401\EccEdc.exe" check "D:\Program\Media\Dumping\DiscImageCreator\20210401\HIOCTANE.img""
FILE: D:\Program\Media\Dumping\DiscImageCreator\20210401\HIOCTANE.img
Checking sectors:  10297/ 10297
[NO ERROR] User data vs. ecc/edc match all
Creating cue and ccd (Track)  1/ 1
Creating bin (Track)  1/ 1
Hashing: HIOCTANE.scm
Hashing: HIOCTANE.img
Hashing: HIOCTANE.bin
EndTime: 2021-05-30T18:20:50+0800

2,884 (edited by user7 2021-05-30 21:56:59)

http://redump.org/disc/59247/

Arrington redumped mine, but different hashes. can you have a look at his logs? https://drive.google.com/file/d/1UcoQAu … sp=sharing

Same ring codes

All my posts and submission data are released into Public Domain / CC0.

2,885

NovaAurora wrote:

LoStraniero pointed me here.

Latest DIC included with MPF, only one sector being detected for SecuROM 4.84.76. Apparently it's supposed to have more than that. Here's the logs, I was told to attach those.

https://cdn.discordapp.com/attachments/ … T_logs.zip

Subchannel is shifted throughout all sectors.

LBA[005000, 0x01388]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[005000, 0x01388]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 41 01 01 01 06 49 00 01 08 49 A5 B0
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 00 00 00 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 00
LBA[005000, 0x01388]: Track[01]: SubQ[19-21]:PrevAbs[5149, 01:08:49], Abs[5149, 01:08:49] -> [5150, 01:08:50] But this sector may be the intentional error of AMSF. see _subinfo.txt
LBA[005001, 0x01389]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
========== LBA[005001, 0x01389]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 41 01 01 21 06 50 00 05 08 50 0A 8F
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 00 00 00 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 00
LBA[005001, 0x01389]: Track[01]: SubQ[15-17]:PrevRel[4999, 01:06:49], Rel[95000, 21:06:50] -> [5000, 01:06:50], [L:1256] But this sector may be the intentional error of RMSF. see _subinfo.txt
LBA[005001, 0x01389]: Track[01]: SubQ[19-21]:PrevAbs[5150, 01:08:50], Abs[23150, 05:08:50] -> [5151, 01:08:51] But this sector may be the intentional error of AMSF. see _subinfo.txt

Disc problem?



RevQuixo wrote:

Getting this error on a JagCD homebrew title:

Logs, please.

nightson wrote:

As you can see in the marked sections, some lines seem to be out of place. Is this a bug of DIC or the > redirect command?

I also comfirmed it. I tried to add sleep function, but it was in vain.

nightson wrote:

Could you add the option to automatically saves the final console output to a log file when dumping is completed?

It's difficult. Use copy & paste to a text file manually, or press Alt + PrtSc and then save as .png or .jpg

user7 wrote:

Arrington redumped mine, but different hashes. can you have a look at his logs? https://drive.google.com/file/d/1UcoQAu … sp=sharing

Same ring codes

Total errors are different.

2,886 (edited by user7 2021-05-31 06:24:21)

sarami wrote:
user7 wrote:

Arrington redumped mine, but different hashes. can you have a look at his logs? https://drive.google.com/file/d/1UcoQAu … sp=sharing

Same ring codes

Total errors are different.

Arrington had repeatable dump results. This means one of the dic builds gives different results from another?

I will ask him to dump with an older build.

All my posts and submission data are released into Public Domain / CC0.

2,887

https://github.com/saramibreak/DiscImag … g/20210601
*2021-06-01
- added: output IMAGE_EXPORT_DIRECTORY
- added: output IMAGE_RESOURCE_DIRECTORY
- changed: output IMAGE_IMPORT_DIRECTORY
- changed: 0x83 ... 0x8f do not affect the cue sheet if crc is bad, so CD-TEXT output is permitted.
- fixed: check c2 error "00 f0 f0 f0 00 00 00 0f 0f 0f 00"
- fixed: SubQ adr6
- improved: multi sector reading of the 0xf1 drive

2,888 (edited by RevQuixo 2021-06-01 19:12:56)

Here are the logs for Frog Feast (Jag CD homebrew on CDR).  It fails pretty early on.

Post's attachments

frog-feast.rar 5 kb, 15 downloads since 2021-06-01 

You don't have the permssions to download the attachments of this post.

2,889 (edited by sarami 2021-06-02 14:34:39)

RevQuixo wrote:

Here are the logs for Frog Feast (Jag CD homebrew on CDR).  It fails pretty early on.

https://www.mediafire.com/file/eq80y20l … st.7z/file
- added: output FULLTOC (Binary) to _maininfo.txt for debug
like this

========== FULL TOC (Binary) ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 4F 01 01 01 14 00 A0  00 00 00 00 01 20 00 01   .O........... ..
0010 : 14 00 A1 00 00 00 00 01  00 00 01 14 00 A2 00 00   ................
0020 : 00 00 02 06 44 01 14 00  01 00 00 00 00 00 02 00   ....D...........
0030 : 01 54 00 B0 04 24 44 03  4F 3B 4A 01 54 00 C0 46   .T...$D.O;J.T..F
0040 : 00 9E 00 61 22 17 01 54  00 C1 48 58 B8 00 00 00   ...a"..T..HX....
0050 : 00 00 00 00 

Please re-upload logs.

2,890

- fixed: check c2 error "00 f0 f0 f0 00 00 00 0f 0f 0f 00"
I feel like this regression / error was based on stuff i was doing at the time.  re: FMT / PC98 discs and a clash with some sort of IBM-PC protection.  I need to revisit some discs i think.

2,891

sarami wrote:
RevQuixo wrote:

Here are the logs for Frog Feast (Jag CD homebrew on CDR).  It fails pretty early on.

https://www.mediafire.com/file/eq80y20l … st.7z/file
- added: output FULLTOC (Binary) to _maininfo.txt for debug
like this

========== FULL TOC (Binary) ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 4F 01 01 01 14 00 A0  00 00 00 00 01 20 00 01   .O........... ..
0010 : 14 00 A1 00 00 00 00 01  00 00 01 14 00 A2 00 00   ................
0020 : 00 00 02 06 44 01 14 00  01 00 00 00 00 00 02 00   ....D...........
0030 : 01 54 00 B0 04 24 44 03  4F 3B 4A 01 54 00 C0 46   .T...$D.O;J.T..F
0040 : 00 9E 00 61 22 17 01 54  00 C1 48 58 B8 00 00 00   ...a"..T..HX....
0050 : 00 00 00 00 

Please re-upload logs.


Here you go.

Post's attachments

frog-feast-test.rar 5.28 kb, 14 downloads since 2021-06-03 

You don't have the permssions to download the attachments of this post.

2,892

Why does C2 rereading give different results every time?

Post's attachments

Hyper Oku no Hosomichi (Japan).7z 3.42 mb, 16 downloads since 2021-06-03 

You don't have the permssions to download the attachments of this post.

2,893

RevQuixo wrote:

Here you go.

Uploaded.
https://www.mediafire.com/file/eq80y20l … st.7z/file
Your disc has two 0xb0.

========== FULL TOC (Binary) ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 9C 01 02 01 10 00 A0  00 00 00 00 01 00 00 01   ................
0010 : 10 00 A1 00 00 00 00 02  00 00 01 10 00 A2 00 00   ................
0020 : 00 00 02 20 48 01 10 00  01 00 00 00 00 00 02 00   ... H...........
0030 : 01 10 00 02 00 00 00 00  02 14 23 01 50 00 B0 05   ..........#.P...
0040 : 02 48 02 4F 3B 47 01 50  00 C0 A0 00 30 00 61 1A   .H.O;G.P....0.a.
0050 : 42 02 10 00 A0 00 00 00  00 03 00 00 02 10 00 A1   B...............
0060 : 00 00 00 00 05 00 00 02  10 00 A2 00 00 00 00 05   ................
0070 : 1F 0B 02 10 00 03 00 00  00 00 05 04 48 02 10 00   ............H...
0080 : 04 00 00 00 00 05 0F 35  02 10 00 05 00 00 00 00   .......5........
0090 : 05 19 0D 02 50 00 B0 FF  FF FF 01 4F 3B 47 00 00   ....P......O;G..

MSF of the 1st 0xb0 had been overwritten by the MSF of 2nd 0xb0. I fixed it.

F1ReB4LL wrote:

Why does C2 rereading give different results every time?

I answered about it in the past.
http://forum.redump.org/post/57771/#p57771
http://forum.redump.org/post/70466/#p70466

2,894

sarami wrote:
RevQuixo wrote:

Here you go.

Uploaded.
https://www.mediafire.com/file/eq80y20l … st.7z/file
Your disc has two 0xb0.

========== FULL TOC (Binary) ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 9C 01 02 01 10 00 A0  00 00 00 00 01 00 00 01   ................
0010 : 10 00 A1 00 00 00 00 02  00 00 01 10 00 A2 00 00   ................
0020 : 00 00 02 20 48 01 10 00  01 00 00 00 00 00 02 00   ... H...........
0030 : 01 10 00 02 00 00 00 00  02 14 23 01 50 00 B0 05   ..........#.P...
0040 : 02 48 02 4F 3B 47 01 50  00 C0 A0 00 30 00 61 1A   .H.O;G.P....0.a.
0050 : 42 02 10 00 A0 00 00 00  00 03 00 00 02 10 00 A1   B...............
0060 : 00 00 00 00 05 00 00 02  10 00 A2 00 00 00 00 05   ................
0070 : 1F 0B 02 10 00 03 00 00  00 00 05 04 48 02 10 00   ............H...
0080 : 04 00 00 00 00 05 0F 35  02 10 00 05 00 00 00 00   .......5........
0090 : 05 19 0D 02 50 00 B0 FF  FF FF 01 4F 3B 47 00 00   ....P......O;G..

MSF of the 1st 0xb0 had been overwritten by the MSF of 2nd 0xb0. I fixed it.

F1ReB4LL wrote:

Why does C2 rereading give different results every time?

I answered about it in the past.
http://forum.redump.org/post/57771/#p57771
http://forum.redump.org/post/70466/#p70466


Got further this time (past the initial error) but new issue:
[ERROR] This program doesn't support to dump the multi-session disc by the plextor CD Drive

Post's attachments

frog-feast.rar 13.91 kb, 14 downloads since 2021-06-03 

You don't have the permssions to download the attachments of this post.

2,895

RevQuixo wrote:

Got further this time (past the initial error) but new issue:
[ERROR] This program doesn't support to dump the multi-session disc by the plextor CD Drive

See below.
https://github.com/saramibreak/DiscImag … /issues/41

2,896

sarami wrote:
RevQuixo wrote:

Got further this time (past the initial error) but new issue:
[ERROR] This program doesn't support to dump the multi-session disc by the plextor CD Drive

See below.
https://github.com/saramibreak/DiscImag … /issues/41

Okay, tried another drive.  Getting a C2 error now at the transition of a session.  Not seeing any physical damage to the disc so not sure of next steps (if any)

Post's attachments

frog2.rar 532.07 kb, 15 downloads since 2021-06-03 

You don't have the permssions to download the attachments of this post.

2,897

RevQuixo wrote:

Getting a C2 error now at the transition of a session.

018072 is the lead-out sector. No problem if /c2 do not use for your disc.

2,898

Regarding several VCDs which are showing up with mastering errors in DIC - example https://ia801809.us.archive.org/view_ar … 20logs.zip

This seems to be a pervasive issue with VCD so it would be monumental if it could be fixed :3

Maddog believes he knows what the issue is - "I think there's some disagreement between where subs say the data should be and where TOC says the data should be." Could this clue help? It would save many VCDs worldwide big_smile

All my posts and submission data are released into Public Domain / CC0.

2,899

user7 wrote:

Maddog believes he knows what the issue is - "I think there's some disagreement between where subs say the data should be and where TOC says the data should be."

LBA[002173, 0x0087d]: Track[01]: Invalid mode. 
========== LBA[002173, 0x0087d]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF FF FF FF FF  FF FF FF 00 01 B0 73 82   ..............s.
0910 : 5C 7A B9 E3 32 C9 D5 96  DF 2E D8 1C 5A 89 FB 26   \z..2.......Z..&
0920 : C3 5A D1 FB 1C 43 49 F1  F6 C4 46 D3 72 DD E5 99   .Z...CI...F.r...
LBA[002174, 0x0087e]: Track[01]: Invalid mode. Invalid reserved byte. Skip descrambling
========== LBA[002174, 0x0087e]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF FF FF FF FF  FF FF FF 00 01 B0 74 A2   ..............t.
0010 : 00 28 00 1E 80 08 60 06  A8 02 FE 81 80 60 60 28   .(....`......``(
0910 : DD 98 DD 98 DD C9 DD 98  DD 98 DD 98 5A 89 DD 98   ............Z...
0920 : DD 98 DD 98 1C 43 DD 98  DD 98 DD 98 A0 1D DD 98   .....C..........
LBA[002175, 0x0087f]: Track[01]: Invalid sync. Skip descrambling
========== LBA[002175, 0x0087f]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : DD 98 DD 98 FF FF DD 98  DD 98 DD 98 01 B1 DD 98   ................
0010 : 00 FF FF FF FF 4F FF FF  FF FF FF 00 80 60 00 C2   .....O.......`..
0020 : 00 28 00 1E 68 66 60 06  A8 02 FE 81 80 3A 60 28   .(..hf`......:`(
0920 : 5C 7A B9 E3 32 C9 D5 96  DF 2E D8 1C 5A 89 FB 26   \z..2.......Z..&
LBA[002176, 0x00880]: Track[01]: Invalid sync. Skip descrambling
========== LBA[002176, 0x00880]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : C3 5A D1 FB 1C 43 49 F1  F6 C4 46 D3 72 DD E5 99   .Z...CI...F.r...
0010 : 00 FF FF FF FF FF FF FF  FF FF FF 00 01 B1 01 E2   ................
0020 : 00 28 00 1E 80 08 60 06  A8 02 FE 81 80 60 60 28   .(....`......``(

LBA 2174 has 2352+16 bytes? Due to this sector LBA 2175 ... last are all shifted.
If possible, try to dump other drives (plextor CD drive or 0xF1 drive of ASUS firmware).

2,900

Similar disc on another Plextor model - https://ia801807.us.archive.org/view_ar … 20logs.zip

So we've tried with 3 Plextor models. If you think it's worth a try, I will buy an Asus.

All my posts and submission data are released into Public Domain / CC0.