You are not logged in. Please login or register.
Redump Forum → Posts by sarami
>Nexy
Long time no see 
Nexy wrote:sarami, can you add Ctrl+C abort
I think it is supported on the OS level, no?
I think so, too.
can you make it not spit out the usage when the command line is wrong.
changed: http://www.mediafire.com/file/eq80y20l9 … st.7z/file
I think i was having some issues, i saw "sleep" and no progress so closed it
darcagn and I can dump the pregap of 2nd session 1st track, 755A and 708A can dump it surely. But you can't dump it. I don't know why now...
Thanks.
- fixed: not output " Lead-out length of 1st session" in cmdline & _disc.txt
Latest is "20190508 190259" http://www.mediafire.com/file/eq80y20l9 … st.7z/file
I don't understand why 123171 is "LOGICAL BLOCK ADDRESS OUT OF RANGE"...
How about other multisessional disc?
EDIT:
Without /c2, similar problem occurred. This was fixed.
deleted: timeout value in /ms
remove "2"
ok, I understood your system can't return the error code properly.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
deleted: timeout value in /ms
added: forced to cancel reading
Uploaded. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
added: timeout value in /ms
Try this.
DiscImageCreator cd <DriveLetter> <filename> <drivespeed> /ms 2Both drives
Unable to get from AMSF 00:00:00 to 00:00:74.
Try to set smaller than -5000.
DiscImageCreator audio <DriveLetter> TOC 4 -6000 -1150DiscImageCreator audio <DriveLetter> TOC 4 -7000 -1150DiscImageCreator audio <DriveLetter> TOC 4 -8000 -1150 :
:
:
DiscImageCreator audio <DriveLetter> TOC 4 -20000 -1150I left a Multisession game dumping overnight and its still going... is it supposed to take so long?
Can PX-708A get the TOC?
DiscImageCreator audio <DriveLetter> TOC 4 -5000 -1100or get the index 0 of track 1?
DiscImageCreator cd <DriveLetter> <Filename> <DriveSpeed(0-72)> /pIf not, dic can't support /ms flag for PX-708A.
DIC needs to show not only where the leadout begins, but also where it ends (or its length)
Uploaded test version
- added: Lead-out length of 1st session in _disc.txt (needs /ms flag)
- fixed: incorrect 'REM SESSION' position.
Logs
http://www.mediafire.com/file/33yj4wjky … og.7z/file
"RUN-OUT"
It seems old isobuster supports it. https://forum.daemon-tools.cc/showthread.php?t=6281
But latest version doesn't output it.
FILE "CD.iso" BINARY
REM ORIGINAL MEDIA-TYPE: CD
CATALOG 4943674011599
REM SESSION 01 (*)
TRACK 01 AUDIO
ISRC JPWP09906010
INDEX 01 00:00:00
REM LBA: 0
TRACK 02 AUDIO
ISRC JPWP09906020
INDEX 01 03:35:47
REM LBA: 16172
TRACK 03 AUDIO
ISRC JPWP09906030
INDEX 01 06:42:30
REM LBA: 30180
TRACK 04 AUDIO
ISRC JPWP09906040
INDEX 01 08:41:55
REM LBA: 39130
TRACK 05 AUDIO
ISRC JPWP09906050
INDEX 01 11:28:17
REM LBA: 51617
TRACK 06 AUDIO
ISRC JPWP09906060
INDEX 01 14:15:62
REM LBA: 64187
TRACK 07 AUDIO
ISRC JPWP09906070
INDEX 01 17:23:67
REM LBA: 78292
TRACK 08 AUDIO
ISRC JPWP09906080
INDEX 01 22:08:10
REM LBA: 99610
TRACK 09 AUDIO
ISRC JPWP09906090
INDEX 01 24:38:62
REM LBA: 110912
TRACK 10 AUDIO
ISRC JPWP09906100
INDEX 01 27:34:52
REM LBA: 124102
TRACK 11 AUDIO
ISRC JPWP09906110
INDEX 01 29:52:25
REM LBA: 134425
TRACK 12 AUDIO
ISRC JPWP09906120
INDEX 01 32:10:72
REM LBA: 144822
TRACK 13 AUDIO
ISRC JPWP09906130
INDEX 01 34:32:62
REM LBA: 155462
TRACK 14 AUDIO
ISRC JPWP09906140
INDEX 01 37:32:67
REM LBA: 168967
REM LEAD-OUT 41:01:67 (*)
REM SESSION 02 (*)
TRACK 15 MODE2/2352
INDEX 01 43:33:67
REM LBA: 196042
REM (*) SESSION commands are not supported by all applications
REM Generated by IsoBuster 4.3.0.00 (https://www.isobuster.com)REM SESSION 01
...
REM LEAD-OUT 00:03:55
REM SESSION 02
REM LEAD-IN 00:02:00
...
I confirmed that the lead-out of 1st session are 6750 sectors and the lead-in of 2nd session are 4500 sectors.
If both num of sectors are always same, is REM LEAD-OUT and REM LEAD-IN unnecessary? because msf is always same like this.
REM SESSION 01
...
REM LEAD-OUT 01:30:00
REM SESSION 02
REM LEAD-IN 01:00:00
...And it has the 'Compact disc Interactive' logo.
Thanks.
Done...
There are some weird points...
1. Track number starts 02, not 01.
2. Index of 1st 75 sectors is 01, not 00.
3. 101 sectors is overdumped.
If you can, please dump it by subdump and upload .sub.
I got a problem dumping Philips CD-i disc 'Dimo's quest' (US version) (in perfect condition, no scratch).
It stops with the following error:
I want to see the sub-channel file. Please dump it by clonecd and upload .sub
And I have a question. Does this disc have the logo of 'compact disc interactive' or 'compact disc digital audio CD-I READY'?
Jackal said to just go with Fireball's suggestion.
http://forum.redump.org/post/67312/#p67312 or http://forum.redump.org/post/69074/#p69074 ?
Both format is a little different.
Maybe eject + load (like hard reset) will make it work?
No, in my case. But when changed to the other drive, made it work. This is the same as xTMODx.
What happens when crc is 0 - some data is invalid?
http://www.mediafire.com/file/drnxhe529 … st.7z/file
added test code to retry and output failed sector to _mainError.txt.
In my disc, all subQ is zero, not only crc16 of subQ.
why DIC does not create a submission txt file ? Or does anyone create a script for windows (batch file) ? I think I saw one for Linux (?) made by a member, but none for windows.
You can use DICUI.
When subQ crc is 0 DIC stops. When I retried it worked. Is is possible to add some more complex restart logic? If crc is 0 go back 100 sectors and retry reading? This crc 0 thing looks quite random...
I tried going back, going forward, flushing cache, but it's all in vain...
i have tried with the /nq option and the plextor 712 drive but DIC crashed then
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- fixed: tracknum of SubQ manually if /nq is used
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.
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 SubQBut 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
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/
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.
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 descramblingThis 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.
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
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 0xFD021EI googled '0xFD021E', and it seems this value is correct, not '0xFD21E'.
'0xFD021E' is the lead-out area of layer 1.
Still doesn't work.
Sorry, fixed. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
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.
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 0xFD21EWe 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 trickRedump Forum → Posts by sarami
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.