You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
Another topic: is it normal that for some PSX PAL demo discs, DIC reports: [INFO] This disc isn't PSX PAL. /nl is ignored.
Demo discs that I dumped which have this info reported by DIC:
http://redump.org/disc/531/
http://redump.org/disc/52732/
Another topic: is it normal that for some PSX PAL demo discs, DIC reports: [INFO] This disc isn't PSX PAL. /nl is ignored.
I am assuming this has something to do with "SYSTEM.CNF" file.
Those discs may lack of "SYSTEM.CNF" file or the file lacks of "VMODE = PAL" value.
BOOT2 = cdrom0:\SLES_542.18;1
VER = 1.02
VMODE = PAL
Can you check which is the case?
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.
Ok I fixed Magic Carpet according to these specifications (scrambled sector 79916). But is there an easy way (without redumping) to check similar dumps for any descrambled sectors that should have remained scrambled?
Some of the dumps that need to be checked:
Chasm - The Rift (Europe) (Sold Out Software)
Cyberwar (USA) (Disc 1)
Cyberwar (USA) (Disc 2)
Cyberwar (USA) (Disc 3)
MER Innebandy (Sweden)
PowerHouse (Europe) (En,Fr,De,Es)
Push-Over (Europe) (En,Fr,De,Es) (Hit Squad - Regenerator)
SimCity 2000 (Germany)
Steel Panthers (Germany)
Trolls (Europe) (1995)
More on this list, but it's outdated: http://forum.redump.org/topic/16655/ibm … to-redump/
I guess we can find most of them this way:
http://redump.org/discs/errors/2/system/pc/
http://redump.org/discs/errors/3/system/pc/
http://redump.org/discs/errors/4/system/pc/
http://redump.org/discs/errors/5/system/pc/
http://redump.org/discs/errors/6/system/pc/
http://redump.org/discs/errors/7/system/pc/
http://redump.org/discs/errors/8/system/pc/
http://redump.org/discs/errors/9/system/pc/
http://redump.org/discs/errors/10/system/pc/
http://redump.org/discs/errors/12/system/pc/
Also, maybe a stupid question, but can we be sure that the offset of this dump is correct? http://redump.org/disc/19878/
Logs attached. The previous (old) dump of this disc was submitted with +0 offset and different Track02 pregap (and the old audio is off by 285 samples compared to the new dump). Most likely it was a dumping error, but there were some cases where different reading modes would give different offsets (588 samples difference with some SecuROM discs), so can we be sure that there is no drive/firmware bug here?
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
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/
hi sarami, i had to redump this disc http://redump.org/disc/55274/ but i couldnt get a dump with newest DIC so i redumped with old dic and isobuster and they produced a different hash than the old one... could you check the logs please, i couldnt find any error
https://www.mediafire.com/file/5jmhv55m … p.rar/file
https://www.mediafire.com/file/f5wi1ql5 … p.rar/file
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 SubQMadroms 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.
So they have a different LBA:4
24D8h: 20 20 20 20 20 20 20 20 20 20 4C 69 63 65 6E 73 Licens
24E8h: 65 64 20 20 62 79 20 20 20 20 20 20 20 20 20 20 ed by
24F8h: 53 6F 6E 79 20 43 6F 6D 70 75 74 65 72 20 45 6E Sony Computer En
2508h: 74 65 72 74 61 69 6E 6D 65 6E 74 28 45 75 72 6F tertainment(Euro
2518h: 70 65 29 00 00 00 00 00 00 00 00 00 00 00 00 00 pe)............. Some early PAL and NTSC-U/C PS1 games have a different licensing string
Licensed by Sony Computer Entertainment(Europe)or
Licensed by Sony Computer Entertainment of Americawhich is definitely worth noting if you need to detect regions. It shouldn't matter though, since libcrypt probably isn't on any of these early PAL discs.
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 driveIf the problem isn't solved, you can use this.
Option (for CD SubChannel) /nq Not fix SubQ
i have tried with the /nq option and the plextor 712 drive but DIC crashed then, but with the plextor premium it worked perfectly even without the /nq option
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.
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...
When I'm finally up and running (and caught up), I'll happily run a script on the entire catalogue if someone can throw together a linux bash script 
(All files will be DEcompressed, so they'll be far easier to work on rather than needing a decompression routine)
(I'm currently moving from Windows & Multiple Hardware RAID5s with NTFS & data deduplication to Linux & ZFS. It's taking far longer than i'd hoped, but i'll get there!)
Plz try and report.
Ok will do.
Plz try and report.
Tried and reported:
========== 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 28 45 75 72 6F tertainment(Euro
0040 : 70 65 29 00 00 00 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 44 45 4D 4F 5F 4F 4E 45 DEMO_ONE
0030 : 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20
0040 : 20 20 20 20 20 20 20 20 00 00 00 00 00 00 00 00 ........It works.
Another question, probably already replied: 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.
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
I tried going back, going forward, flushing cache, but it's all in vain...
Oh that's quite bad. Maybe eject + load (like hard reset) will make it work?
What happens when crc is 0 - some data is invalid?
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.
Madroms wrote: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.
I know DICUI create such file, but I don't use it as I use my own batch file to do multiple tasks. Ok, so it is not implemented atm.
Hello Sarami
Using DICUI_1.12.2, 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:
LBA[269200, 0x41b90]: [F:ReadCDForCheckingSubRtoW][L:803]
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, 04, 1b, 90, 00, 00, 00, 01, 08, 00
dwBufSize: 2742Dump result attached to this post...
sarami, do you have all the info to add proper multisession dumping / cue info?
We would love to start submitting these discs
http://forum.redump.org/topic/20409/dis … ssion-cue/
sarami, do you have all the info to add proper multisession dumping / cue info?
We would love to start submitting these discs
From what I understand there isn't a consensus on the format, it would be a waste of time for him to implement something that could be changed at any time.
On the discord, Jackal said to just go with Fireball's suggestion. Better than waiting another 10 years because not everyone can be 100% happy with the spec.
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.
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'?
Done... And it has the 'Compact disc Interactive' logo.
Redump Forum → General discussion → DiscImageCreator
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.