UploadedI got the disc.09chairs
I'll support it in the future. (I don't have both discs now.)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.
Still needed. See the logs for https://redump.info/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).F1ReB4LL wrote: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.sarami wrote:I checked it by Cosmic Fantasy 3. If this code is no problem, I'll remove /m flag.
I uploaded it at 2020-01-23 00:39:01 as test version.F1ReB4LL wrote:Don't forget the last pregap sector...
Bug report of old version is useless and waste of time for me (and bug reporter).20191116 221523
Desktop\DIC_\DiscImageCreator.exe cd H: TestD8 4 /c2 10 /d8
Sorry, haven't noticedsarami wrote:Bug report of old version is useless and waste of time for me (and bug reporter).
Uploaded.F1ReB4LL wrote:Sorry, haven't noticed
Code: Select all
test_20200601T212407.txtIt's difficult.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?
Code: Select all
- 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)Needs more info.usurper wrote:DIC crashes for me on the latest stable version (20200604) after doing the hashing.