Savagesteel wrote:
I get the same error:
This problem can't be fixed now.
Try below.
1. Change the drive speed.
2. Resurface if scratches exist in the disc.
3. Change the disc if possible
4. Change the drive if possible.
2,526 2020-05-19 06:57:56
2,527 2020-05-19 13:31:25
- sadikyo
- Administrator
- Offline
so, I already submitted this information to DICUI for update, but I wanted to share here also. I was talking with Enker about the layerbreak information for xbox discs, and apparently people (myself included until I discovered the issue) have been submitted the incorrect layerbreak for xbox discs, when they should essentially all be the same default one.
Here is what Enker shared with me:
"Hey, yes the DICUI layerbreak for Xbox/Xbox360 (and also Blu-ray discs) is incorrect. It's caused by DIC reporting two layerbreaks, one for the video partition and one for the game partition (DICUI uses this one). It never logs the actual layerbreak that takes into account the video partition+middle zone that comes before the game partition. If you add the video LayerZeroSector + Middle Zone + game LayerZeroSector, then you get the default value on the disc page.
DICUI could omit the layerbreak for Xbox/Xbox360/Blu-ray discs, since we never need to enter one for those discs."
As I said, I've already sent this to DICUI to pull the correct one, but I wanted to share with you as well sarami, in case anything has to be done on the DIC side.
The correct layerbreak is apparently the default of 1913776, and not the 1715632 that often/sometimes gets reported.
2,528 2020-05-19 16:51:26 (edited by Savagesteel 2020-05-19 16:51:51)
sarami wrote:
1. Change the drive speed.
2. Resurface if scratches exist in the disc.
3. Change the disc if possible
4. Change the drive if possible.
1. I tried with 2x, 4x and 20x and had the same error
2. The disc is in very good condition I cannot see any scratch or damage
3. Yes in the following weeks I will scout ebay to get one and compare the dumps 
4. Unfortunately I don't have a second drive which supports 0xC8 instructions
Also when I dump the disc with IsoBuster and the same Plextor drive the image has the same size but data is different (different hash).
When dumping the disc with IsoBuster and two different drives I get the same image file (same hash).
Plextor PX-712A (Firmware 1.09)
Lite-On iHAS124 (Firmware CL9J)
Lite-On iHAS124 (Firmware CL9J)
2,529 2020-05-19 18:00:51
Savagesteel wrote:
Also when I dump the disc with IsoBuster and the same Plextor drive the image has the same size but data is different (different hash).
When dumping the disc with IsoBuster and two different drives I get the same image file (same hash).
Perhaps, your disc is no problem.
Try to downgrade the firmware and test DIC with no-firmware-check build. http://forum.redump.org/post/74000/#p74000
sadikyo wrote:
The correct layerbreak
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
Added: output layerbreak to _disc.txt (only xbox or xbox 360)
2,530 2020-05-22 23:03:54
http://forum.redump.org/post/79651/#p79651 - could you look at it? Why does it have a missing sector (resulting in incorrect lead-in and first pregap sizes)?
Heartbreak Diary also has a weird lead-in size, probably incorrect. And the "Subs indexes" cue is missing its lead-out/lead-in/pregap tags, bug?
2,531 2020-05-23 01:48:23
09chairs --- reentrant reported this problem. http://forum.redump.org/post/79155/#p79155 Perhaps, this occurs by the combined offset minus disc. I'll get this disc to test.
Heartbreak Diary --- RevQuixo reported this problem. http://forum.redump.org/post/79442/#p79442 Perhaps fixed it by the latest test version.
And the "Subs indexes" cue is missing its lead-out/lead-in/pregap tags, bug?
Ah yes. I'll fix it.
2,532 2020-05-23 13:08:05
sarami wrote:
I'll get this disc to test.
https://www.mercari.com/jp/items/m39989856327/
https://www.mercari.com/jp/items/m84877193423/
There's also a problem with CCD and IMG files for multisession discs. IMG files should not contain the lead-out+lead-in+1st-pregap areas, it should only contain all the tracks merged together (these areas should be skipped while descrambling from scm to img).
And some CCD indexes are wrong. I'm attaching CloneCD, T..p and DIC .ccd files for http://redump.org/disc/70115/ (removed INDEX01 entries from DIC cue for easier comparison). DIC's [Entry 20] is incorrect.
2,533 2020-05-23 14:48:41
And another example, [Entry 5] is incorrect.
Also, it's probably better not to add the additional indexes and catalog/isrc stuff into ccds, since the ccd is a TOC, not CUE replacement and only needs to contain the TOC (including the CD-TEXT stuff, I guess?) and all the additional indexes/MCN/ISRC stuff can be taken from the sub.
2,534 2020-05-24 00:34:32
http://forum.redump.org/topic/28059/abn … ory-rev-a/ -- have you seen this? weird issue
2,535 2020-05-24 01:52:50
F1ReB4LL wrote:
IMG files should not contain the lead-out+lead-in+1st-pregap areas, it should only contain all the tracks merged together (these areas should be skipped while descrambling from scm to img).
F1ReB4LL wrote:
And some CCD indexes are wrong.
ok, I'll fix it.
F1ReB4LL wrote:
Also, it's probably better not to add the additional indexes and catalog/isrc stuff into ccds
But CloneCD outputs them.
F1ReB4LL wrote:
have you seen this? weird issue
Perhaps, it was fixed when I fixed about ROM^2 Karaoke Volume 5 at 2019-12-23.
2,536 2020-05-25 19:29:14
sarami wrote:
F1ReB4LL wrote:Also, it's probably better not to add the additional indexes and catalog/isrc stuff into ccds
But CloneCD outputs them.
Are you sure? Attaching "as is" cool herders ccd files now and CloneCD one only lists index1s, tru doesn't list them at all and only DIC lists all the indexes, never seen CloneCD ccds with more than 1 index, maybe some special setting is needed? Same for CATALOG and ISRC, never seen them in CloneCD ccds, only in tru and DIC ones.
2,537 2020-05-26 00:17:25
https://www.sendspace.com/file/z6hof7 - any idea what happened here? Why the final image is completely undescrambled?
2,538 2020-05-26 10:01:29
F1ReB4LL wrote:
any idea what happened here? Why the final image is completely undescrambled?
>ガルフ・ウォー 蒼鋼伝
http://forum.redump.org/topic/16418/add … new-dumps/
Same problem?
F1ReB4LL wrote:
maybe some special setting is needed?
1. Create new profile (not to edit default profile).
2. Check "Read SubChannel Data from Data Tracks of Data Read Settings tab.
3. Check "Regenerate Data Sectors of Data Read Settings tab.
4. Check "Read SubChannel Data from Audio Tracks of Audio Read Settings tab.
sarami wrote:
F1ReB4LL wrote:IMG files should not contain the lead-out+lead-in+1st-pregap areas, it should only contain all the tracks merged together (these areas should be skipped while descrambling from scm to img).
F1ReB4LL wrote:And some CCD indexes are wrong.
ok, I'll fix it.
Done. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
09chairs
I got the disc.
2,539 2020-05-26 16:45:18
sarami wrote:
F1ReB4LL wrote:any idea what happened here? Why the final image is completely undescrambled?
>ガルフ・ウォー 蒼鋼伝
http://forum.redump.org/topic/16418/add … new-dumps/
Same problem?
Seems so, but there are no glitches in the "user area" (lba 0 to leadout), so you need to somehow report about a 'double offset' in the logs, but you shouldn't leave the image scrambled.
2,540 2020-05-27 18:22:49
- ClevelandDynamics
- Dumper
- Offline
I'm not sure where to post this. Per: http://wiki.redump.org/index.php?title= … patibility
I have confirmed some specifications of the LG BU40N, and used it to dump with DIC successfully:
LG (HL-DT-ST)
BU40N
UHD Blu-ray / DVD Writer
Slim / SATA slimline
Tested firmware: 1.03
Chipset: MediaTek
Offset: Confirmed +6
2,541 2020-05-28 13:55:07
09chairs
I got the disc.
Uploaded
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
http://www.mediafire.com/file/uw3e03kdk … ar.gz/file
F1ReB4LL wrote:
Seems so, but there are no glitches in the "user area" (lba 0 to leadout), so you need to somehow report about a 'double offset' in the logs, but you shouldn't leave the image scrambled.
I'll support it in the future. (I don't have both discs now.)
2,542 2020-05-31 21:20:03
F1ReB4LL wrote:
sarami wrote:I checked it by Cosmic Fantasy 3. If this code is no problem, I'll remove /m flag.
Don't forget the last pregap sector and the first sector after the pregap can be also replaced with EAN sectors and need the opposite logic: if the current sector is EAN/ISRC, the next sector's Q-channel has its index changed to 01, but the next sector's P-channel is still padded with 0xFF, then the current EAN/ISRC sector still belongs to pregap. And if the current sector is EAN/ISRC, the next sector's Q-channel has its index changed to 01, but the next sector's P-channel is padded with 0x00, then the current EAN/ISRC sector does not belong to pregap, but belongs to the track's index 01 (because the first sector of the 01 index should have its P-channel padded with 0xFF). Even if you take the 1st indexes from TOC, this check is still important for the TOC/cue desync detection.
Still needed. See the logs for http://redump.org/disc/70477/ - tracks 10 and 29 gaps have EAN sectors and were misdetected as desync (while DIC should detect the last gap sector is EAN and check the P-channels of this and of the following sector, 0xFFs for this sector and 0x00s for the next sector means the EAN sector doesn't belong to the gap, while 0xFFs for both means it does).
2,543 2020-06-01 03:42:06
F1ReB4LL wrote:
Don't forget the last pregap sector...
I uploaded it at 2020-01-23 00:39:01 as test version.
But exe version is here...
20191116 221523
Desktop\DIC_\DiscImageCreator.exe cd H: TestD8 4 /c2 10 /d8
Bug report of old version is useless and waste of time for me (and bug reporter).
2,544 2020-06-01 09:39:51
sarami wrote:
Bug report of old version is useless and waste of time for me (and bug reporter).
Sorry, haven't noticed
2,545 2020-06-01 12:50:56
F1ReB4LL wrote:
Sorry, haven't noticed
Uploaded.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
http://www.mediafire.com/file/uw3e03kdk … ar.gz/file
- changed: _cmd.txt to _[buildData].txt like this
test_20200601T212407.txt2,546 2020-06-02 16:23:14 (edited by LoStraniero91 2020-06-02 16:30:21)
- LoStraniero91
- Dumper
- Offline
Sarami, is it possible to add a function in DIC where you can just output a .cue without having to dump the whole disc? I have many ringed discs and the only way I can generate a .cue is to eject the disc and reinsert it past the ring sections so it completes the dump (without /c2). It's annoying!
Salviamo la cultura videoludica italiana.
2,547 2020-06-04 04:12:11
LoStraniero91 wrote:
is it possible to add a function in DIC where you can just output a .cue without having to dump the whole disc?
It's difficult.
----
Uploaded 20200604 https://github.com/saramibreak/DiscImag … r/releases
- added: support for make install command (Linux only) (thanks pseiler)
- added: support multi-session disc that the combined offset is minus
- added: new 0xf1 drive (thanks olofolleola4)
-> ASUS BW-12B1ST a 1.00
-> ASUS BC-12D2HT 3.01
-> HL-DT-ST BD-RE WH16NS60 1.00
- added: extract MicroSoft Cabinet File (.cab) for searching protection (Windows only)
- added: extract InterShield Cabinet File (ISc) to detect protection using i6comp.exe (Windows only)
- added: extract Wise Installation to detect protection using E_WISE_W.EXE (Windows only)
- added: output log of SecuROM DLL Header (AddD, CA DD DD AC) to _volDesc.txt
- added: output fullpath of file to _volDesc.txt
- added: output import directory log to _volDesc.txt
- added: output ISRC country, owner, year, serial to _disc.txt
- added: output layerbreak to _disc.txt (only xbox or xbox 360)
- added: output log of cdg instruction to _subReadable.txt
- added: output DVD header of the raw dump to _rawReadable.txt
- added: REM LEAD-OUT, LEAD-IN, REM PREGAP in Subs indexes cue
- changed: Data and Time format (ISO8601 is used)
- changed: _cmd.txt to _[BuildData].txt
- fixed: BD-ROM also uses "Anchor Volume Descriptor Pointer", not TOC length
- fixed: dat is empty if current directory is root
- fixed: detecting 1st lead-in sector of 2nd session
- fixed: detecting psx anti-mod string when the string across sector boundary
- fixed: disk dumping (use Read10, not ReadFile)
- fixed: raw dump of GCC-4241N & GCC-4242N
- fixed: PLBA of ccd if LBA is over 404850
- fixed: XBOX dumping (failed to dump if transfer length is over max)2,548 2020-06-04 18:36:06
- wiggy2k
- Dumper
- Offline
Thats some update @Sarami, Thanks
2,549 2020-06-15 02:42:35 (edited by usurper 2020-06-15 02:42:57)
DIC crashes for me on the latest stable version (20200604) after doing the hashing.
2,550 2020-06-15 03:11:21
usurper wrote:
DIC crashes for me on the latest stable version (20200604) after doing the hashing.
Needs more info.