Confirmed.
The pre-last sector is erroneous. The last sector is reverted/scrambled.
Exactly, the last 4510 byte is reverted/scrambled. BTW, does reading error occur if isobuster reads these 2 sectors?
1,051 2017-07-13 02:31:47
1,052 2017-07-15 08:07:54
I just had a small morning debugging session and one of the dumpers found a CD which has corrupted Path Table Record. I inspected it under debugger and basically all fields are off. I think Path Table Records related values in PVD are wrong.
Please add an option to disable reading Path Table Record via command line in order to fight such weird CDs...
1,053 2017-07-15 14:29:34
http://forum.redump.org/post/55106/#p55106
http://forum.redump.org/post/55327/#p55327
http://forum.redump.org/post/55479/#p55479
Attention
1. Before you report a bug, could you test the latest test version. Nevertheless a bug exists, could you upload all created file except bin, img and scm. And could you tell me the disc title ,region, barcode and ringcode.
Thanks several report, but I don't have these disc, so I can't test and fix them.
About PVD:
If it can't be read by IsoBuster, it is weird disc, otherwise dic's bug.
1,054 2017-07-15 15:13:50
It's not a bug in DIC. DIC correctly parses the data. It's disc fault. New operating systems do not detect anything on the cd. Only old Windows show the data (I guess those old versions do not handle Path Table records).
1,055 2017-07-15 16:53:00
Is it really ISO9660 disc? If so, it is easily unbelievable that "Only" old Windows (3.1?, 95?, 98?, 2000? etc) can read it.
1,056 2017-07-15 19:56:14
sarami wrote:
BTW, does reading error occur if isobuster reads these 2 sectors?
Of course.
1,057 2017-07-15 21:08:02
sarami wrote:
Is it really ISO9660 disc? If so, it is easily unbelievable that "Only" old Windows (3.1?, 95?, 98?, 2000? etc) can read it.
here are the dump files with reentrant's DIC http://www107.zippyshare.com/v/xb6AmTRp/file.html i could open the disc on windows xp but not on windows 8.1 tested on 4 plextor drives
1,058 2017-07-16 09:37:21 (edited by Jackal 2017-07-16 09:38:15)
olofolleola4 is having some problems dumping a disc. The disc has 3 data tracks and in the third track seems to switch between different data modes. DIC seems to be descrambling it erroneously, starting from byte 529200.
There seem to be some bytes missing in the last sector of the .scm, which make it impossible to fully descramble.
When I manually descramble the .scm, I get these results:
D:\dic>eccedc check "d:\descramble_CDDA_TEAZLE_CD (Track 3).bin"
FILE: d:\descramble_CDDA_TEAZLE_CD (Track 3).bin
[F:handleCheckOrFix][L:512] GetLastError: 2, The system cannot find the file specified.If sub file exists, this app can check the data sector precisely
Checking sectors (LBA) 512/ 512
User data vs. ecc/edc match all
Does this mean that if properly descrambled, the dump is correct and doesn't need any 0x55 fixes?
1,059 2017-07-16 15:54:18
xTMODx wrote:
i could open the disc on windows xp but not on windows 8.1 tested on 4 plextor drives
Weird.. if you can, please try on win7, win10, linux(ubuntu, fedora etc.)
Jackal wrote:
olofolleola4 is having some problems dumping a disc.
_mainError.txt
LBA[308560, 0x4b550]: Track[00]: Sync is invalid
========== LBA[308560, 0x4b550]: Main Channel ==========
+0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B +C +D +E +F
0( 0) 00 ff ff ff ff ff ff ff 00 ff ff ff ff ff ff ff
10( 16) ff ff ff 00 69 b6 10 61 03 83 f4 cd bf 24 63 7a
:
:The garbage byte (a part of the sync?) exists in first 8 byte of this sector. So, the offset is shifted by 8 byte... dic can't descramble these sector for this reason. Can you read these sector by the other tools (Isobuster, perfectrip clonecd etc.)?
Does this mean that if properly descrambled, the dump is correct and doesn't need any 0x55 fixes?
I don't know whether these sector are a mastering error, or a protect or not.
1,060 2017-07-16 19:38:59
"308558-->308560 isn't readable.
Track 3 is recognized as Audio mode in IsoBuster."
I guess the shift is caused by data > audio transition?
1,061 2017-07-17 14:06:12
Only 3 sector? but clearly, 289 sectors are error if use 0xd8..
Track 3 is recognized as Audio mode in IsoBuster."
I guess the shift is caused by data > audio transition?
I don't know, but these sectors are clearly including the data sector. "00 ff ... ff 00" is sync, "69 b6 10" is the scrambled msf, "61" is the scrambled mode.
1,062 2017-07-18 16:29:50 (edited by sarami 2017-07-18 17:25:51)
F1ReB4LL wrote:
http://redump.org/disc/16920/ -- scrambled contents has the pre-last sector half-scrambled, half-descrambled and the last sector descrambled, so the descrambled dump should have the last sector scrambled and the pre-last sector inverted. It's a common Saturn mastering error. For some reason DIC leaves the last sector as is without scrambling it, that's not correct. And the earlier DIC versions work fine, I remember I've tested such discs, dumps were correct.
20170719 test
- changed: Directory record size from 8192 to 16384 (for some amiga CD)
- fixed: data sector is descrambled when sync and mode is valid and reverted sector
xTMODx wrote:
sarami wrote:Is it really ISO9660 disc? If so, it is easily unbelievable that "Only" old Windows (3.1?, 95?, 98?, 2000? etc) can read it.
here are the dump files with reentrant's DIC http://www107.zippyshare.com/v/xb6AmTRp/file.html i could open the disc on windows xp but not on windows 8.1 tested on 4 plextor drives
_volDesc.txt
========== LBA[000016, 0x00010]: Volume Descriptor ==========
Volume Descriptor Type: 1
Standard Identifier: CD001
Volume Descriptor Version: 1
System Identifier:
Volume Identifier: MASTERQUIZ
Volume Space Size: 510448
Volume Set Size: 1
Volume Sequence Number: 1
Logical Block Size: 1024
Path Table Size: 116
Location of Occurrence of Path Table: 36
Location of Optional Occurrence of Path Table: 0
Length of Directory Record: 34
Extended Attribute Record Length: 0
Location of Extent: 40
:Correct size of "Volume Space Size" is perhaps 255384. "Location of Occurrence of Path Table" is perhaps 18. "Location of Extent" is perhaps 20. Other values may be corrupt.
If possible, I don't want to skip reading the path and directory table. These values are to fix manually in app. Of course, the image file isn't fixed.
1,063 2017-07-18 22:16:57
i have exact the same disc twice i can send you as a donation if that can help
1,064 2017-07-18 22:20:45
In this case it's possible to reimage from mounted image in virtual drive
1,065 2017-07-20 18:45:10
Updated test version.
----
Logical Block Size: 1024I had thought that "Logical Block Size" is fixed in 2048 byte. But Ecma-119 says below.
6.2.2 Logical Block
The Volume Space shall be organized into Logical Blocks. Each Logical Block shall consist of 2n+9 bytes,
where n equals 0 or a positive integer. The number of bytes in a Logical Block shall be referred to as the Logical
Block size which shall not be greater than the Logical Sector size.
That is, it is correct that "Logical Block Size" is 1024 byte and "Volume Space Size", "Location of Occurrence of Path Table" and "Location of Extent" is double size because "Logical Block Size" is half size.
http://redump.org/disc/43476/
File system doesn't corrupt, but CD-ROM that "Logical Block Size" isn't 2048 byte is perhaps rare or irregular. So, I think the OS that is newer than WinXP doesn't support it.
1,066 2017-07-21 01:50:25
Gap detection glitch (last track).
1,067 2017-07-21 06:36:40
sarami wrote:
http://redump.org/disc/43476/
File system doesn't corrupt, but CD-ROM that "Logical Block Size" isn't 2048 byte is perhaps rare or irregular. So, I think the OS that is newer than WinXP doesn't support it.
Nice find. Also some tools do not support it either (Total Commander) + 7z.
1,068 2017-07-21 17:24:09
F1ReB4LL wrote:
Gap detection glitch (last track).
_disc.txt
========== TOC ==========
:
Audio Track 50, LBA 247692- 250338, Length 2647
Audio Track 51, LBA 250339- 255212, Length 4874
Total 255213========== FULL TOC ==========
Session 1, Track 50, MSF 55:04:42 (LBA[247842, 0x3c822])
Session 1, Track 51, MSF 55:00:00 (LBA[247500, 0x3c6cc])LBA of TOC is correct but LBA of FULL TOC is incorrect. I don't know why...
1,069 2017-07-21 21:49:33
sarami wrote:
LBA of TOC is correct but LBA of FULL TOC is incorrect. I don't know why...
Another one:
1,070 2017-07-22 16:14:26
Updated.
----
I suspect PX-716, but the LBA of "FULL TOC" and "TOC" is same if it is single session disc, so the LBA of "FULL TOC" is only used in multi session disc.
1,071 2017-07-23 13:27:16 (edited by reentrant 2017-07-23 15:13:53)
So in case of this 1024B sector is DIC going to have support for this?
Sarami: Could you made a commit to git with latest changes? I think I have a DVD that fails to dump and I'd like to debug it...
1,072 2017-07-23 14:23:29
Another weird bug. 2nd track misdetected as audio. The dump is correct, the 2nd track is properly descrambled, but the cuesheet is wrong.
Maybe there's something unusual with the disc itself, because the older TruRip db dump is totally broken, with the incorrect total image size (16 sectors smaller than should be) and incorrect sizes for most of the tracks. Subs are normal, all the 2nd track's sectors are marked as 41 02 (data).
1,073 2017-07-23 20:08:52 (edited by sarami 2017-07-25 02:15:37)
reentrant wrote:
So in case of this 1024B sector is DIC going to have support for this?
Yes, path/directory table can read correctly.
reentrant wrote:
Sarami: Could you made a commit to git with latest changes? I think I have a DVD that fails to dump and I'd like to debug it...
Fixed a transfer length for reading Volume Descriptor of DVD. Concerning committing, plz wait...
F1ReB4LL wrote:
Another weird bug. 2nd track misdetected as audio.
Combined Offset(Byte) -30576, (Samples) -7644
- Drive Offset(Byte) 120, (Samples) 30
----------------------------------------------
CD Offset(Byte) -30696, (Samples) -7674
Overread sector: -14Sector size "-14" is incorrect. "-13" is correct. This is fixed but I don't know whether the misdetecting is fixed or not.
1,074 2017-07-25 02:23:28 (edited by sarami 2017-07-28 16:27:27)
Jackal wrote:
usurper wrote:Sarami, if you are looking for a challenging protection, get yorself this or this disc.
https://www.medimops.de/infogrames-der- … 6FS54.html
https://www.medimops.de/infogrames-der- … 6FS55.htmlThis one from the same publisher has the same protection:
https://www.medimops.de/vivendi-univers … edVeryGood
GameCopyWorld wrote:The process took 18 hours to complete because about 35% of the CD contains unreadable errors!
I bought Fort Boyard Millenium. There are some errors in CDDA area. Is this true? Jackal, usurper, if you have this, plz check...
EDIT:
20170728
- added: /ss option (scan sector for protectCD-VOB)
- changed: Option name is /rc -> /sf (scan file)
- changed: Directory record size from 8192 to 16384
- changed: Data sector is descrambled when sync is valid and mode is valid
and there is the reverted sector, and unknown mode but reserved byte all zero
- changed: The LBA of FULL TOC is used only the multi session disc.
- fixed: Reading path/directory record (support the logical block size under 2048 byte)
- fixed: The transfer length to read path/directory record for DVD
- fixed: Short of the shifted sector if the combined offset is 2352*n (n is integer)
1,075 2017-08-15 18:33:47 (edited by Jackal 2017-08-15 18:42:46)
Trying to dump a CD-i game (Dimo's Quest).
It seems that the offset is misdetected, which results in a dump with shifted data that is missing 3816 bytes in the first sectors.
What is also strange, is that when I do a normal sector view in IsoBuster with the Plextor, there is an offset in the data sectors. The Optiarc drive does not have this.
The old px_d8 tool detects the combined offset correctly as -924. The dump should match this other disc(which also matches Trurip) - http://redump.org/disc/35804/
Is this a drive bug or a software bug?