651

(3,497 replies, posted in General discussion)

Madroms wrote:

So they have a different LBA:4

http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- added: detecting "          Licensed  by          Sony Computer Entertainment(Europe)"

If /nl is used, LBA:4 is outputted in _mainInfo.txt like this.

========== LBA[000004, 0x00004]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 20 20 20 20 20 20 20 20  20 20 4C 69 63 65 6E 73             Licens
0010 : 65 64 20 20 62 79 20 20  20 20 20 20 20 20 20 20   ed  by          
0020 : 53 6F 6E 79 20 43 6F 6D  70 75 74 65 72 20 45 6E   Sony Computer En
0030 : 74 65 72 74 61 69 6E 6D  65 6E 74 20 45 75 72 6F   tertainment Euro
0040 : 20 70 65 20 20 20 00 00  00 00 00 00 00 00 00 00    pe   ..........
========== LBA[000016, 0x00010]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 01 43 44 30 30 31 01 00  50 4C 41 59 53 54 41 54   .CD001..PLAYSTAT
0010 : 49 4F 4E 20 20 20 20 20  20 20 20 20 20 20 20 20   ION             
0020 : 20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                   
0030 : 20 20 20 20 20 20 20 20  20 20 20 20 20 20 20 20                   
 :
 :

Plz try and report.

652

(3,497 replies, posted in General discussion)

As cmd says,
1. If your disc has scratches, it needs to be polished
2. Try to dump with different drive speed
3. Try to dump with different drive

If the problem isn't solved, you can use this.

Option (for CD SubChannel)
          /nq     Not fix SubQ

653

(3,497 replies, posted in General discussion)

Jackal wrote:

But is there an easy way (without redumping) to check similar dumps for any descrambled sectors that should have remained scrambled?

Scrambled sector of mode 1
---
0x814: 0x48, 0x815: 0x64, 0x816: 0x36, 0x817: 0xab, 0x818: 0x56, 0x819: 0xff, 0x81a: 0x7e, 0x81b: 0xc0

descrambled sector of mode 1
---
0x814: 0x00, 0x815: 0x00, 0x816: 0x00, 0x817: 0x00, 0x818: 0x00, 0x819: 0x00, 0x81a: 0x00, 0x81b: 0x00


Jackal wrote:

but can we be sure that the offset of this dump is correct? ... but there were some cases where different reading modes would give different offsets (588 samples difference with some SecuROM discs)

According the disc.txt, SubCode[0], [2] and [8] show 285 samples. Perhaps px_d8 also outputs same result. But there isn't sync in LBA:14098.

This sync of LBA:14098 is LBA:14099.

04B0 : 1C 43 49 F1 F6 C4 1A 43  1F 41 38 2B 00 FF FF FF   .CI....C.A8+....
04C0 : FF FF FF FF FF FF FF 00  02 89 74 61 00 28 00 1E   ..........ta.(..

I don't know why there isn't sync in LBA:014098. Gulf War Soukouden of FMT has similar problem. http://forum.redump.org/topic/16418/add … new-dumps/

654

(3,497 replies, posted in General discussion)

Madroms wrote:

Another topic: is it normal that for some PSX PAL demo discs, DIC reports: [INFO] This disc isn't PSX PAL. /nl is ignored.

dic checks this string of LBA: 4.

LBA: 4

0000 : 20 20 20 20 20 20 20 20  20 20 4C 69 63 65 6E 73             Licens
0010 : 65 64 20 20 62 79 20 20  20 20 20 20 20 20 20 20   ed  by          
0020 : 53 6F 6E 79 20 43 6F 6D  70 75 74 65 72 20 45 6E   Sony Computer En
0030 : 74 65 72 74 61 69 6E 6D  65 6E 74 20 45 75 72 6F   tertainment Euro
0040 : 20 70 65 20 20 20 00 00  00 00 00 00 00 00 00 00    pe   ..........

You can also check LBA:4.

Jackal wrote:

KailoKyra dumped this disc: http://redump.org/disc/3927/ but it wasn't matching the database, because DIC is not descrambling any of the last 3 sectors.

Attached the 3 last data sectors for this disc and the DIC log:

If I remember correctly, we agreed before that all sectors inside a data track with a valid sync should always be descrambled? But still DIC is not descrambling the first 2 sectors. The third and last sector has an invalid sync and shouldn't be descrambled.

LBA[079915, 0x1382b]: Track[01]: Invalid mode. 

This sector was descrambled. IIRC, we agreed before about invalid mode.

LBA[079916, 0x1382c]: Track[01]: Invalid mode. Invalid reserved byte. Skip descrambling

This sector was not descrambled because this sector is incomplete as data sector. IIRC, we also agreed before about incomplete data sector. For this sector, it seems sync of next sector is shifted by 12 bytes.

655

(3,497 replies, posted in General discussion)

F1ReB4LL wrote:

In fact, the damaged sectors are 14097, 14098, 14099 and 14100. Why does it say 901 instead of 14100? DIC is probably using a wrong algorithm to show the sector numbers.

Replace EccEdc.exe with this
http://www.mediafire.com/file/2quudw2bl … st.7z/file

Jackal wrote:

Olo dumped a disc at 8x speed, but the SecuROM data was messed up

If random error also exists in SecuROM data, it's difficult to fix.

Detailed page says https://web.archive.org/web/20080911180 … cl:80/?p=8

donde ss.bin es un dump en bruto (2064 bytes) del PSN 0xFD021E

I googled '0xFD021E', and it seems this value is correct, not '0xFD21E'.
'0xFD021E' is the lead-out area of layer 1.

F1ReB4LL wrote:

Still doesn't work.

Sorry, fixed. http://www.mediafire.com/file/eq80y20l9 … st.7z/file

iR0b0t wrote:

Because it should not skip any sectors besides those in ss ranges, i would say.

Yes. if reading error occurs out of the ss ranges, its sector is bad.

Jackal wrote:

Requiring manual input of ss ranges is silly

I think so too. Btw I found this https://web.archive.org/web/20081221213 … ng_pref=en

where ss.bin is a raw dump (2064 bytes) of data @PSN 0xFD21E

We may get the ss.bin by xbox raw dumping without kreon drive... I'll try it.

16 ss is needed.

        xboxswap <DriveLetter> <Filename> <DriveSpeed(0-16)>
                                          <StartLBAOfSecuritySector_1>
                                          <StartLBAOfSecuritySector_2>
                                                         :
                                          <StartLBAOfSecuritySector_16> [/f (val)] [/q]
                Dump a Xbox disc from A to Z using swap trick

659

(3,497 replies, posted in General discussion)

Test version
20190413 (Linux)
http://www.mediafire.com/file/uw3e03kdk … est.tar.gz
- fixed: output _volDesc.txt (many DWORD/LONG was changed to UINT/INT because DWORD/LONG is 8bytes not 4bytes in 64bit build)

user7 wrote:

hmmm, what about for DVD or BD

http://forum.redump.org/post/62345/#p62345
Perhaps this problem hasn't solved yet.

user7 wrote:

What command should be be dumping Mil-CD / Dreamcast unlicensed with /ms or regular CD?

As you know, multi-session's cue is being discussed now. Probably cue format is changed (also bin & scm?).

F1ReB4LL wrote:

We need our own variants of these to show the amount of Lead-In and Lead-Out sectors to generate (similar to PREGAP and POSTGAP commands) - http://forum.redump.org/post/67312/#p67312

I see, then should we add 'REM LEAD-IN' and 'REM LEAD-OUT' and 'REM SEGA-LOGO' etc in dreamcast's cue?

http://forum.redump.org/post/69075/#p69075

iR0b0t wrote:

@sarami, do you have some thoughts?

I think 'REM LEAD-IN' and 'REM LEAD-OUT' don't need in multi-session's cue of multi-track (redump'org) format.
1. Because multi-session's cue of multi-track format doesn't have lead-in area and lead-out area.

2. Because Dreamcast's cue doesn't have 'REM LEAD-IN' and 'REM LEAD-OUT'. (Admin and mod defined only REM SINGLE-DENSITY AREA and REM HIGH-DENSITY AREA. Actually, GD-ROM has lead-out after the last track of single-density area and lead-in before first track of high-density area.)

3. With only 'REM SESSION 01' and 'REM SESSION 02', IsoBuster can recognize that multi-session's cue of multi-track is multi-session.

But IsoBuster needs 'REM LEAD-OUT' because IsoBuster's bin has the lead-out area of 1st session and lead-in area of 2nd session.

662

(3,497 replies, posted in General discussion)

Drive does not always return the error properly. You do know it regarding puzzle bobble 4 of dreamcast. (To dump the track 12, dcdumper rereads several hundred? times until the hash matches. dcdumper compares the hash, not detect the error.)

663

(3,497 replies, posted in General discussion)

user7 wrote:

VGHF is looking to use it with an automatic disc feeder (nimbie), so ejecting it not be doable.

Does it means that nimbie can't execute DIC by multiple start? How nimbie assures that some discs are good dumping without hashing?

664

(3,497 replies, posted in General discussion)

Test version
20190409 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190409 (Linux)
http://www.mediafire.com/file/uw3e03kdk … est.tar.gz
- changed: hashing order of DVD/XBOX (old: iso -> SS/PFI/DMI.bin, new: SS/PFI/DMI.bin -> iso)

user7 wrote:

sarami, could you add a command to disable hashing? I'm advising VGHF on a large scale preservation project and they have too many discs and not enough time, a flag to disable hashing would be an immense help to speed things up. I would prefer they use DIC to other options, and this be a deciding factor.

When DIC is hashing, DIC doesn't access the disc anymore. That is, you can eject the disc and insert new disc and dump new disc by new DIC when DIC is hashing.

F1ReB4LL wrote:

have you tried to implement that?

http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- added: /nss flag in xbox, xboxswap and xgd2swap

DiscImageCreator.exe xbox <drive> <filename> <speed> /nss 10
'10' is a max rereading value per sector
DiscImageCreator.exe xbox <drive> <filename> <speed> /nss
If value is omitted, '100' is set automatically.

I've not tested yet xboxswap and xgd2swap
Give me a comment, plz.

666

(3,497 replies, posted in General discussion)

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

- added: Output volume descriptor and directory entry of XDVDFS to volDesc.txt(readable format) and mainInfo.txt(binary format)
like this. (volDesc.txt)

========== XDVDFS ==========
========== LBA[198176, 0x30620]: VOLUME DESCRIPTOR ==========
                            Header: MICROSOFT*XBOX*MEDIA
    Sector of root directory table: 1363536(0x14ce50)
      Size of root directory table: 68(0x44)
               Image creation time: 2002/01/25 02:28:43
                            Footer: MICROSOFT*XBOX*MEDIA
    ========== LBA[1561680, 0x17d450]: DIRECTORY ENTRY ==========
     Offset to left sub-tree entry: 5(0x5)
    Offset to right sub-tree entry: 12(0xc)
           Starting sector of file: 1365413(0x14d5a5)
                   Total file size: 2048(0x800)
                   File attributes: directory
                Length of filename: 5
                          Filename: Media

        ========== LBA[1563557, 0x17dba5]: DIRECTORY ENTRY ==========
         Offset to left sub-tree entry: 6(0x6)
        Offset to right sub-tree entry: 74(0x4a)
               Starting sector of file: 1366601(0x14da49)
                       Total file size: 2048(0x800)
                       File attributes: directory
                    Length of filename: 8
                              Filename: scenario

            ========== LBA[1564745, 0x17e049]: DIRECTORY ENTRY ==========
             Offset to left sub-tree entry: 8(0x8)
            Offset to right sub-tree entry: 96(0x60)
                   Starting sector of file: 1366715(0x14dabb)
                           Total file size: 845824(0xce800)
                           File attributes: normal
                        Length of filename: 17
                                  Filename: SCENARIOVAR01.NB9
Parotaku wrote:

It stops with a 'Directory Record is invalid' error..

Thanks.
- fixed: checking the directory table size when transfer length is beyond a maximum

haynor666 wrote:

DIC crash

I don't know the cause of that malfunction.

maxoojc wrote:

SubFailed to reread because crc16 of subQ is 0

Same problem as The Amazing Spider-Man vs. The Kingpin. I can't fix this problem now.

- The data inside the security sector ranges seems to be random garbage that has no meaning or purpose.

Its pointless, the data is not useful, its not fully retrievable, and the result will be no dumps verify.

How can we prove that data has no meaning or purpose? Do you read machine/assambly code? Doesn't easter egg exist in the security sector?

668

(3,497 replies, posted in General discussion)

[ERROR] Number of sector(s) where bad MSF: 77
    Sector: 5342, 5343, ...

Perhaps 5343 was misdetection.

Test version
20190401 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190401 (Linux)
http://www.mediafire.com/file/uw3e03kdk … est.tar.gz
- added: Extract several string from DMI.bin to _disc.txt for Xbox
like this

========== DiscManufacturingInformation ==========
    System Version: 02
         Timestamp: 2007/03/19 00:00:00
           Unknown: 02
          Media ID: d8f835e4ff632505557da02d4916ecda
         Publisher: Namco
            Serial: 2005
           Version: 1.01
            Region: Japan
           Unknown: 0X
              Disc: 1 of 1

- fixed: misdetection of bad MSF

669

(3,497 replies, posted in General discussion)

Spört wrote:

Sorry, should have said. Those happened when I ran it as root indeed!

ReadBufferCapacity fails. I don't know why... PX-755A supports this. At least, app works well by KNOPPIX 8.2.

fuzzball wrote:

Has the new version (2019-03-26) changed the return code?

No.

F1ReB4LL wrote:

Was 313 errors (incorrect), became 315 errors after your fixes (also incorrect, should be 314 or am I wrong?).

Which sector should be correct?

670

(3,497 replies, posted in General discussion)

Spört wrote:

Sadly it crashes for me.

Please try to use su or sudo.

671

(3,497 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … r/releases
*2019-03-26
- added: GDR-8084N and GCC-4244N for GC/Wii
- added: output dat for linux
- added: /vn flag (support VideoNow)
- added: /sf flag in dvd command for RingProtect
- added: support pregap data track
- added: support 288 and 264 and 240 bits of SafeDisc
- changed: /74 option is only used by swap command
- changed: app is aborted if crc16 of subQ is 0 when disc is reread
- fixed: detecting SecuROM (devided v3 to v3_1 and v3_2)
- fixed: detecting SecuROM Type 4 (4.5.x.xx - 4.6.x.xx)
- fixed: detecting smartE
- fixed: SafeDisc Lite dumping
- fixed: buffer offset overflow of GD-ROM TOC
- fixed: CDTEXT
- fixed: Subs vs. TOC desync

672

(3,497 replies, posted in General discussion)

reentrant wrote:

Each of these vary by 24. I can confirm that this is correct info.

reentrant wrote:

LayerZeroSector: 1533693 (0x1766fd)

Updated test version.

673

(3,497 replies, posted in General discussion)

user7 wrote:

This seems to be the issue: [F:GetFilenameToSkipError][L:150] GetLastError: 2, The system cannot find the file specified.

You lost ReadErrorProtect.txt

enderghast13 wrote:

DIC failed to dump a PS2 Action Replay disc that I bought.

It seems last 40 sectors have errors.

674

(3,497 replies, posted in General discussion)

reentrant wrote:

Hi sarami. I have a safedisc protected disc and I want to report some weird info. Below is a list of C2 error counters from protected range:
240
264
288
312

Each of these vary by 24. I can confirm that this is correct info.

ok. I trust your info.

user7 wrote:

DIC seems to have failed dumping a PS3 beta (BD-R)

Weird... My BD-RE disc is no problem.

========== TOC ==========
      Data Track  1, LBA        0 - 23652351, Length 23652352
                                              Total  23652352
========== DiscStructure ==========
FormatCode: 00, Sendable:  No, Readable: Yes, FormatLength: 4098
========== DiscInformationFromPIC ==========
                DiscInformationIdentifier: DI
                    DiscInformationFormat: 01
             NumberOfDIUnitsInEachDIBlock: 28
                         DiscTypeSpecific: 02
    DIUnitSequenceNumber/ContinuationFlag: 00
           NumberOfBytesInUseInThisDIUnit: 63
                       DiscTypeIdentifier: BDW
                   DiscSize/Class/Version: 02
            DIUnitFormatDependentContents: 2401000001000000000000000002000000194e7e01ec6464464646463c3c3c3c00000000c0427b0a0a4a4a1bc0427b0a0a4a4a1b
 
user7 wrote:

PS: Please publish a new stable release to github :3

I've asked to F1ReB4LL about VideoNow. Please wait for several days/weeks. You can use test version.

675

(3,497 replies, posted in General discussion)

LoStraniero91 wrote:

Still unsure how to make it work. Can you please tell me step by step?

1. Check the 1st LBA when reading error occurs.
2. Check which file has the 1st error LBA by IsoBuster.
3. Rewrite the 2nd line of ReadErrorProtect.txt by its filename.
4. Exec dvd command with /sf flag.