51 Reply by sarami

(52 replies, posted in General discussion)

Edness wrote:

I know you've already confirmed the multi-partition UMD GAME+MOVIE discs are most likely correct size in your original post, but out of curiosity if you have any on hand, could you provide the PFI for one of those too?

Stealth feat. WipEout Pure Stealth Edition http://redump.org/disc/57052/

 00 00 00 00 00 00 00 00 12 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 16 00 00 80 00 31 E0 00 03 00 00 00 FC D3 3F
 00 09 C0 BF 00 03

Edness wrote:

Anyway: sceUmdExecGetConfigurationCmd() - Sends the expected command 0x46

Edness wrote:

Lastly: sceUmdExecReadDiscInfoCmd() - Sends the expected command 0x51

Thanks research. I'll code and test in the near future.

Edness wrote:

Random side note:

Thanks to you I know SysclibForKernel_NID().

Go to forum: General discussion

52 Reply by sarami

(3,497 replies, posted in General discussion)

Kyaerosaber wrote:

Logs for DiscImageCreator_test dump of Ys Book I & II (USA) [TurboDuo]:

"Sub Indexes" tracks/cue are created. I think it's no problem.

Go to forum: General discussion

53 Reply by sarami

(52 replies, posted in General discussion)

I tried "bufStruct[9] = 8" (0x800). Function call succeed, but hardware hanged up.
And tried "bufStruct[9] = 16" (0x1000). Function call failed.

By the way, if possible, could you research sceUmdExecReadDiscInfoCmd and sceUmdExecGetConfigurationCmd? Both are also SCSI-like fuctions.

Go to forum: General discussion

54 Reply by sarami

(52 replies, posted in General discussion)

Changed to 16.

bufStruct[8] = 16;

The result is same as you expected. Disc is Dissidia 012.

 00 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 10 00 00 80 00 31 E0 00 03 00 00 00 FC AB 2F
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

EDIT:
PFI of DVD is 2048 bytes. According to Ecma-365, it's the same for UMD, but byte 19 - 2047 of UMD are all zeros. That is why dumping 18 bytes is sufficient for preservation.

Go to forum: General discussion

55 Reply by sarami

(52 replies, posted in General discussion)

Edness wrote:

it also writes the number 40 at 0x08 in the 1st function

As you say, I set 40 at 0x08.

    unsigned char bufStruct[72] = {};
    bufStruct[8] = 40;
    _sceUmdManWaitSema();
    res = _sceUmdExecReadUMDStructureCmd(pUmdDrive, bufStruct, &bufStruct[32]);
    _sceUmdManSignalSema();
    if (res < 0) {
        OutputPspError("_sceUmdExecReadUMDStructureCmd", 0, res);
        sceKernelDelayThread(5 * 1000000);
    }
    else {
        uid = sceIoOpen("ms0:/_sceUmdExecReadUMDStructureCmd.bin", PSP_O_CREAT | PSP_O_TRUNC | PSP_O_WRONLY, 0777);
        sceIoWrite(uid, bufStruct, sizeof(bufStruct));
        sceIoClose(uid);
    }

As a result, non-zero bytes are written in _sceUmdExecReadUMDStructureCmd.bin
Disc is Mugen Kairou http://redump.org/disc/53372/

 00 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 28 00 00 80 00 01 E0 00 03 00 00 00 04 5D 5F
 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

It seems 0x28 at 0x21 is the size from 0x20 to 0x47. Other non-zero bytes are unknown now.

EDIT1:
Disc is Dissidia 012: Duodecim Final Fantasy http://redump.org/disc/25036/

 00 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 28 00 00 80 00 31 E0 00 03 00 00 00 FC AB 2F
 00 09 C0 BF 00 01 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

EDIT2:
Disc is Jigen Kairou http://redump.org/disc/54489/

 00 00 00 00 00 00 00 00 24 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 28 00 00 80 00 01 E0 00 03 00 00 00 05 07 BF
 00 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00

Go to forum: General discussion

56 Reply by sarami

(52 replies, posted in General discussion)

@Edness
Thanks the detailed information.

Go to forum: General discussion

57 Reply by sarami

(3,497 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … g/20230909
*2023-09-09
- added: support dumping RVT-R/NR with Plextor drive
- added: reading speed for /c2
- added: subchannel correction when the lead-in is dumped
- added: command-line message to the log file
- changed: transfer length when fixes C2 errors on BW-16D1HT drive with firmware 3.10
- changed: (Track AA).scm filesize

Go to forum: General discussion

58 Reply by sarami

(3,497 replies, posted in General discussion)

F1ReB4LL wrote:

Can you add more debug info logging to understand the problem?

Added it.
https://www.mediafire.com/file/eq80y20l … st.7z/file

Go to forum: General discussion

59 Reply by sarami

(3,497 replies, posted in General discussion)

F1ReB4LL wrote:

the log is full of "Subchannel & TOC doesn't sync." messages, but no "Sub Indexes" tracks/cue created? Why?

I dumped Tengai Makyou: Ziria(http://redump.org/disc/37134/) and "Sub Indexes" are dumped. I'm not sure why Ys Book I & II (USA) are not dumped.

Go to forum: General discussion

60 Reply by sarami

(3,497 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … g/20230606
20230606
- added: support BD-RE BH16NS40 1.03
- added: print ProductRevisionLevel and VendorSpecific of the drive in the command-line screen
- added: /v for printing the version & build info
- added: _suppl.dat for .scm, .img, .raw, _SS.bin, _DMI.bin, _PFI.bin, _PIC.bin
- added: support GC/Wii dumping for Plextor
- added: when used /raw, .iso is generated using .raw
- added: support dvd raw dumping for ASUS/LG/Lite-on drives
- added: generate (Track 00)(Session 1), (Track 00)(Session 2), (Track AA)(Session 1), (Track AA)(Session 2), (Track 01)(-LBA), (Track xx)(Pregap)
         when multi-session disc is dumped [xx is the 1st track number of the 2nd session]
- added: /ra for dumping a specified range of sectors
- added: support macOS (It's alpha)
- added: support /rr and /ps when /r is used
- changed: C2 error rereading logic
- changed: generate (Track 0), (Track 1)(-LBA), (Track AA) for all single-session disc (not only audio but data)
- changed: when /ps is used, transfer length is 1
- changed: /ps val accepts from 0x00 to 0xff
- changed: targetname for linux
- fixed: crash when fix C2 errors by the non-plextor drive
- fixed: if ext is not specified and dvd command is used, .iso is added automatically
- fixed: subReadableLog when track is aa
- fixed: scsi error handling when /raw is used
- fixed: Failed to get (Track 01)(-LBA) when the 1st sector is MCN
- deleted: /ms and the related code

Go to forum: General discussion

61 Reply by sarami

(3,497 replies, posted in General discussion)

bikerspade wrote:

Is it possible that because DIC doesn't directly check ScsiStatus, that it is missing some bad reads?

Try this test version in this thread(https://github.com/saramibreak/DiscImag … 1551409465)
And use /ps aa, please.
https://github.com/saramibreak/DiscImag … r_test.zip

Go to forum: General discussion

62 Reply by sarami

(3,497 replies, posted in General discussion)

"Lead-out length of 1st session" is 6750.
"Lead-in length of 2nd session" is 4500.
"Pregap length of 1st track of 2nd session" is 150.
They are always same.

Go to forum: General discussion

63 Reply by sarami

(3,497 replies, posted in General discussion)

@mictlantecuhtle
I'm changing the code for dumping the multi-session disc https://github.com/saramibreak/DiscImag … issues/208 . Please wait a few days.

EDIT
Updated test version. https://github.com/saramibreak/DiscImag … r_test.zip
- deleted: /ms and the related code

Go to forum: General discussion

64 Reply by sarami

(3,497 replies, posted in General discussion)

MrPepka wrote:

Plextor is not able to fix C2 errors on this disc.

Does it means that plextor cannot fix errors by 5000 times? If yes, plz specify 10000, 20000, 30000...

MrPepka wrote:

The problem only affects this one disc and interestingly only the LG drive

Can you check yourself the different bytes of the two "SHOK_PL_CD1.bin"?

Go to forum: General discussion

65 Reply by sarami

(3,497 replies, posted in General discussion)

withered.silence wrote:

Am I doing something obviously wrong here?

Firstly, please use the latest version. https://github.com/saramibreak/DiscImag … g/20230413
And try without /am, plz.

Go to forum: General discussion

66 Reply by sarami

(3,497 replies, posted in General discussion)

MrPepka wrote:

dumping it on sectors with SCSI errors

Disc can't be dumped due to this problem. I recommend this disc is polished.

Go to forum: General discussion

67 Reply by sarami

(3,497 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … g/20230401
*2023-04-01
- added: Track[0] to _SubReadable.txt
- added: (Track 0), (Track 1)(-LBA), (Track AA), (Track all) when audio CD is dumped
- added: get non-zero byte position (1st and last) of the each track to the _disc.txt
- added: SIZE_OF_ARRAY macro
- deleted: /vrfy option and related code
- fixed: universal hash (changed sample base, not byte)
- fixed: the range of the SubQ check
- fixed: and improved C2 error recovering

Go to forum: General discussion

68 Reply by sarami

(3,497 replies, posted in General discussion)

reentrant wrote:

Thx. Btw, could you also add command line parameter for setting c2 offset value (if there's no value assume 0)?

https://www.mediafire.com/file/eq80y20l … st.7z/file
2nd value of /c2 is the c2 offset

Go to forum: General discussion

69 Reply by sarami

(3,497 replies, posted in General discussion)

reentrant wrote:

I think when you specify "lpNextBuf" you assume 294 C2 offset but what for drives that have 0 C2 offset?

Maybe it should be like that:

I've not confirmed the c2 offset of the non-plextor drive, but I'll add it.

Edit
added
https://www.mediafire.com/file/eq80y20l … st.7z/file

Go to forum: General discussion

70 Reply by sarami

(3,497 replies, posted in General discussion)

reentrant wrote:

It's actually what I see - 8 bytes difference! I think that without taking into account that additional offset value c2 rereading algorithm is not correct. Plz could you also implement this - it's so close to have a perfect c2 rereading algorithm smile

8 bytes difference --- It's 1 byte (8 bits) for .c2 file. then at that time, I understood "Additional Offset" that ehw says is "PX-712 or newer drive have 295 byte offsets, not 294".

Foxhack wrote:

why this error is happening?

Merely HDDVD drive doesn't support DVDGetRegion. Same error occurs for my GGW-H20N.
Btw, other application (e.g. isobuster) can dump your disc? How many HDDVD do you have? All HDDVD you have can't be dumped?

Go to forum: General discussion

71 Reply by sarami

(3,497 replies, posted in General discussion)

reentrant wrote:

Should be interpreted as being shifted by combined offset if you try to match these pointers to specific sector in SCM.

It's easy to add the combined offset value to "ofs: xxx".
ofs: 3e2 + 0x20, 3e3 + 0x20, ...

But if it also applies to .c2 file, it needs to be shfted to right by 0x20 bits. It's very complicated.

reentrant wrote:

It's still a question why I had to shift data by additional 8 bytes (2 samples). I have a feeling that not all Plextors 760 have equal C2 offset...

I have no idea. If you have other 760 drive, you can try it.

Go to forum: General discussion

72 Reply by sarami

(3,497 replies, posted in General discussion)

reentrant wrote:

Ok, but how to explain the following:

For this issue?  https://github.com/saramibreak/DiscImag … issues/154

Foxhack wrote:

it won't let me dump an HDDVD because it shows me that error above ([F:DVDGetRegion][L:472] GetLastError: 1, Incorrect function.)

I tried to dump HDDVD using GGW-H20N and it's no problem. Its error is not related.

Go to forum: General discussion

73 Reply by sarami

(3,497 replies, posted in General discussion)

reentrant wrote:

After I applied fix above C2 rereading algorithm started to work

Thanks debugging and patching. I also confirrmed that your patch is working.

reentrant wrote:

Another thing is that it looks like single bit in C2 file should be treated as if there were 2 erroneous bytes in image file. Some bits are not reported in C2 file and 2 bytes are bad in image. It's weird.

Yes, it's known issue. For this reason, C2 error disc sometimes doesn't recover if the drive doesn't return C2.

reentrant wrote:

is the C2 file using combined offset?

I deleted it. https://github.com/saramibreak/DiscImag … b1da037109

Go to forum: General discussion

74 Reply by sarami

(3,497 replies, posted in General discussion)

reentrant wrote:

an you check the algorithm and verify it rereads / writes correct bytes?

If there are not non-zero byte in your .c2 file, the drive judges there are not c2 errors in your disc.

Go to forum: General discussion

75 Reply by sarami

(3,497 replies, posted in General discussion)

user7 wrote:

TSST TS-H352 supports C2 with data tracks, but not support C2 with audio tracks.

However when trying to dump a DC disc with a single data track in the HD area I get the error "[WARNING] This drive doesn't support reporting C2 error. Disabled /c2".

DIC dumps data sector as "audio" to get the scrambled sector.

Go to forum: General discussion