2,526

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,527

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 (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 smile
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)

2,529

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

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

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

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.

Post's attachments

herders_ccd.7z 930 b, 1 downloads since 2020-05-23 

You don't have the permssions to download the attachments of this post.

2,533

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.

Post's attachments

piersolar_ccd.7z 622 b, 1 downloads since 2020-05-23 

You don't have the permssions to download the attachments of this post.

2,534

http://forum.redump.org/topic/28059/abn … ory-rev-a/ -- have you seen this? weird issue

2,535

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

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.

Post's attachments

herders_real_ccd.7z 1.06 kb, file has never been downloaded. 

You don't have the permssions to download the attachments of this post.

2,537

https://www.sendspace.com/file/z6hof7 - any idea what happened here? Why the final image is completely undescrambled?

2,538

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

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.

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

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

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).

Post's attachments

bremen.7z 1.57 mb, 1 downloads since 2020-05-31 

You don't have the permssions to download the attachments of this post.

2,543

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

sarami wrote:

Bug report of old version is useless and waste of time for me (and bug reporter).

Sorry, haven't noticed smile

2,545

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.txt