You are not logged in. Please login or register.
Redump Forum → Posts by sarami
sarami wrote:"Write offset" is set to +670? I think the db needs to be fixed by your hash. Anyway, please contact reentrant.
There is not non-zero byte in the (Track AA) and (Track 01)(-LBA) in the disc MrPepka is dumped. The disc should be based as "Write offset 0"?
Sarami, do you have an idea for this?
"Write offset" is set to +670? I think the db needs to be fixed by your hash. Anyway, please contact reentrant.
DiscImageCreator_test.7z
https://www.mediafire.com/file/eq80y20l … st.7z/file
- added: (Track 0), (Track 1)(-LBA), (Track AA), (Track all) when audio CD is dumped (Only Plextor)
- fixed: universal hash (changed sample base, not byte)
https://github.com/saramibreak/DiscImag … g/20230309
*2023-03-09
- added: output universal (from the 1st non-zero byte position to the last non-zero byte position) hash when audio CD is dumped
- added: output hash for XXH3 (64bit and 128bit) when using /d
- added: output .toc file
- changed: do not skip descrambling when reserved area(0x814 - 0x81b) is invalid
- changed: TOC vs. Subs are desync about the control(data/audio) flag, TOC in priority. Subs are created as "(Subs control)"
- improved: log of the CD sync
- fixed: ISRC issue of cuesheet for "Nine Inch Nails - Broken"
I decided that both dumps like Subs vs. TOC desync disc (http://redump.org/disc/37134/). "TOC control" is in priority.
2017-07-28 : skip descrambling when reserved area(0x814 - 0x81b) is invalid
At least, Jackal, reentrant and superg don't agree this. I'll delete this code. Some disc with erroneous sectors needs to redump.
It should be possible to reconstruct such image given some metadata in comments section. If you want working ISO, just generate it by yourself using special tool like redumper or sth else
I totally agree. Fixed dump page (e.g. http://redump.org/disc/99290/) don't need and I want to delete it.
(3) - no sync, I'd say it's audio. But I'd add one exception to that rule.
Then, sector with damaged sync is "audio" ok?
There are some CD-I discs where whole sync is zeroed but data is scrambled, it's more than one disc, so ideally:
Tell me the url of the database of this site.
(6) - definitely audio
I think so. Some Sega Saturn and CD-i ready disc (and etc.) have it. (e.g. http://redump.org/disc/58172/, http://redump.org/disc/35804/ )
(4),(5),(7),(8) - this is a source of discrepancies because of TOC subchannel properties mix.
You say, "subchannel based split we should use only data/flags from subchannel". Redump.org adopts "subchannel based split" except for TOC vs. Subs desync disc. Then (7),(8) should be descrambled in accordance with subchannel and (4),(5) should not be descrambled in accordance with subchannel.
That fixed the issue
Thanks. it was committed. https://github.com/saramibreak/DiscImag … 2ea246f1a5
There were some examples recently where DIC was leaving sectors scrambled inside a data track with correct sync/header and mostly correct data, resulting in different dumps than before.
According to the commit log
. 2016-05-14 to 2017-05-07 : skip descrambling when sync is invalid
. 2017-07-02 : skip descrambling when mode is invalid
. 2017-07-28 : skip descrambling when reserved area(0x814 - 0x81b) is invalid
. 2018-09-15 : support mode 0
we should not rely on sector content (or rely less) when deciding whether we should unscramble sector or not.
I agree if admin and other mods agree. I think TOC and SubQ and sync should be checked.
1. Data track on TOC, Data sector on SubQ and sync is valid --- it's apparently "data" and there is no room for discussion.
2. Audio track on TOC, Audio sector on SubQ and no sync --- it's apparently "audio" and there is no room for discussion.
3. Data track on TOC, Data sector on SubQ, but there is not a sync (or sync is damaged) --- It's "data" or "audio"?
4. Data track on TOC, Audio sector on SubQ, there is not a sync (or sync is damaged) --- It's "data" or "audio"?
5. Data track on TOC, Audio sector on SubQ, there is a sync --- It's "data" or "audio"?
6. Audio track on TOC, Audio sector on SubQ, but there is a sync --- It's "data" or "audio"?
7. Audio track on TOC, Data sector on SubQ, there is not a sync (or sync is damaged) --- It's "data" or "audio"?
8. Audio track on TOC, Data sector on SubQ, there is a sync --- It's "data" or "audio"?
For this Nine Inch Nails - Broken audio CD, the ISRC value of USIR19200539 is being incorrectly applied to tracks 93-97 in the cuesheet. It should only be applied to Track 98, with no ISRC values for tracks 93-97.
Test please.
https://www.mediafire.com/file/eq80y20l … st.7z/file
The disc is not in the best condition, but some errors seem to indicate an incorrectly burned disc (mastering errors?)
I'm talking about "Mode2 NoEdc subheader" errors here
It can't read correctly from 22209.
LBA[022209, 0x056c1]: [F:ProcessReadCD][L:288]
Opcode: 0xd8
ScsiStatus: 0x02 = CHECK_CONDITION
SenseData Key-Asc-Ascq: 03-02-8d = MEDIUM_ERROR - VENDOR UNIQUE ERROR
LBA[022209, 0x056c1]: Read error. padding [2352 bytes]
LBA[022210, 0x056c2]: Read error. padding [2352 bytes]
LBA[022211, 0x056c3]: Read error. padding [2352 bytes]
LBA[022212, 0x056c4]: Read error. padding [2352 bytes]
LBA[022213, 0x056c5]: Read error. padding [2352 bytes]
LBA[022214, 0x056c6]: Read error. padding [2352 bytes]
LBA[022215, 0x056c7]: Read error. padding [2352 bytes]
LBA[022216, 0x056c8]: Read error. padding [2352 bytes]
LBA[022217, 0x056c9]: Read error. padding [2352 bytes]
LBA[022218, 0x056ca]: Read error. padding [2352 bytes]
LBA[022219, 0x056cb]: Read error. padding [2352 bytes]
LBA[022220, 0x056cc]: Read error. padding [2352 bytes]
LBA[022221, 0x056cd]: Read error. padding [2352 bytes]
LBA[022222, 0x056ce]: Read error. padding [2352 bytes]
LBA[022223, 0x056cf]: Read error. padding [2352 bytes]
LBA[022224, 0x056d0]: Read error. padding [2352 bytes]
LBA[022225, 0x056d1]: Read error. padding [2352 bytes]https://github.com/saramibreak/DiscImag … g/20230201
*2023-02-01
- added: support the c2 offset of the plextor 712A or newer
- added: change the default path of the driveOffset.txt file on linux
- added: fix subQ using next subQ when crc does not match by index 0
- added: /d option (hash sha224, sha256, sha384, sha512)
- added: /sk for dvd
- changed: do not use the combined offset in .c2
- changed: set mode using LBA 11
- changed: remove printing directory from .dat output file on linux
- fixed: forgot .raw hashing
- fixed: failed to read directory record when record size is more than the max transfer length (only GD-ROM)
- fixed: check subchannel of lead-in of the 2nd session
- fixed: cue indexes when there is index 2 or more in track 1
- fixed: detecting ARccOSThe present method of dumping Audio CDs using DIC in some cases leads to imperfect results, including:
* Failure to capture data in the lead-in and lead-out
It has supported for just one year now (20220201).
/vrfy Check non-zero byte in the lead-out and pregap of 1st track (Only Audio CD)
val 0: audio cd can be read without offset (default)
1: audio cd can be read with offset
and select 'y' then read without offset or select 'n' then not read
2: logs are only generated with offset* Occasional imperfect track splits
Why not report as a bug if it is really true?
This is a similar case. Please understand this is not special.
[PCE] Madou Monogatari I - Honoo no Sotsuenji (Japan)
http://redump.org/disc/37150/
LBA[183031, 0x2caf7]: P[ff], Q[01210100317000404231bc6d]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[21], Idx[01], RMSF[00:31:70], AMSF[40:42:31]}, RtoW[0, 0, 0, 0]
LBA[183032, 0x2caf8]: P[ff], Q[020000000000000000323764]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0000000000000], AMSF[ :32]}, RtoW[0, 0, 0, 0]
LBA[183033, 0x2caf9]: P[00], Q[012201000001004042336c90]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[22], Idx[01], RMSF[00:00:01], AMSF[40:42:33]}, RtoW[0, 0, 0, 0][PCE] Cosmic Fantasy 3 - Bouken Shounen Rei (Japan)
http://redump.org/disc/2416/
LBA[142873, 0x22e19]: P[ff], Q[41370000000000314673bc02]{ Data, Copy NG, Track[37], Idx[00], RMSF[00:00:00], AMSF[31:46:73]}, RtoW[0, 0, 0, 0]
LBA[142874, 0x22e1a]: P[ff], Q[420000000000000000746d7c]{ Data, Copy NG, MediaCatalogNumber [0000000000000], AMSF[ :74]}, RtoW[0, 0, 0, 0]
LBA[142875, 0x22e1b]: P[00], Q[413701000001003147002c45]{ Data, Copy NG, Track[37], Idx[01], RMSF[00:00:01], AMSF[31:47:00]}, RtoW[0, 0, 0, 0]
LBA[261585, 0x3fdd1]: P[00], Q[01950100136900580960087c]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[95], Idx[01], RMSF[00:13:69], AMSF[58:09:60]}, RtoW[0, 0, 0, 0]
LBA[261586, 0x3fdd2]: P[00], Q[020000000000000000615df2]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0000000000000], AMSF[ :61]}, RtoW[0, 0, 0, 0]
LBA[261587, 0x3fdd3]: P[ff], Q[019600000273005809625f79]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[96], Idx[00], RMSF[00:02:73], AMSF[58:09:62]}, RtoW[0, 0, 0, 0]it belongs to the current track, not to the next one.
No. See other tracks.
LBA[000000, 0000000]: P[ff], Q[010101000000000002005a28]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[01], Idx[01], RMSF[00:00:00], AMSF[00:02:00]}, RtoW[0, 0, 0, 0]
LBA[000001, 0x00001]: P[00], Q[01010100000100000201e058]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[01], Idx[01], RMSF[00:00:01], AMSF[00:02:01]}, RtoW[0, 0, 0, 0]LBA[003364, 0x00d24]: P[00], Q[010101004464000046644b69]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[01], Idx[01], RMSF[00:44:64], AMSF[00:46:64]}, RtoW[0, 0, 0, 0]
LBA[003365, 0x00d25]: P[00], Q[01020000027400004665d274]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:74], AMSF[00:46:65]}, RtoW[0, 0, 0, 0]
LBA[003366, 0x00d26]: P[ff], Q[0102000002730000466685c3]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:02:73], AMSF[00:46:66]}, RtoW[0, 0, 0, 0] :
:
LBA[136098, 0x213a2]: P[ff], Q[013501061417003016482f95]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[35], Idx[01], RMSF[06:14:17], AMSF[30:16:48]}, RtoW[0, 0, 0, 0]
LBA[136099, 0x213a3]: P[ff], Q[01360100000000301649cc7e]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[36], Idx[01], RMSF[00:00:00], AMSF[30:16:49]}, RtoW[0, 0, 0, 0]
LBA[136100, 0x213a4]: P[00], Q[01360100000100301650e537]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[36], Idx[01], RMSF[00:00:01], AMSF[30:16:50]}, RtoW[0, 0, 0, 0]LBA[138279, 0x21c27]: P[00], Q[013601002905003045540ab3]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[36], Idx[01], RMSF[00:29:05], AMSF[30:45:54]}, RtoW[0, 0, 0, 0]
LBA[138280, 0x21c28]: P[00], Q[01370000027400304555f71f]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[37], Idx[00], RMSF[00:02:74], AMSF[30:45:55]}, RtoW[0, 0, 0, 0]
LBA[138281, 0x21c29]: P[ff], Q[01370000027300304556a0a8]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[37], Idx[00], RMSF[00:02:73], AMSF[30:45:56]}, RtoW[0, 0, 0, 0]It's not always but P channel of 1st sector of the track and 2nd sector of the track is different typically.
A relatively recent dump of a particular PCECD disc (Metamor Jupiter) produced a bad track split, where the hashes for track 15 and track 16 are incorrect.
DB is incorrect. The pregap of the track 16 is 00:03:00, not 00:02:74.
LBA[047436, 0x0b94c]: P[00], Q[01150100386600103436d96b]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[15], Idx[01], RMSF[00:38:66], AMSF[10:34:36]}, RtoW[0, 0, 0, 0]
LBA[047437, 0x0b94d]: P[00], Q[0200000000000000003767c1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [0000000000000], AMSF[ :37]}, RtoW[0, 0, 0, 0]
LBA[047438, 0x0b94e]: P[ff], Q[01160000027300103438dcb1]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[16], Idx[00], RMSF[00:02:73], AMSF[10:34:38]}, RtoW[0, 0, 0, 0]LBA 47437 belongs to the track 16.
Ok, it was fixed as I expected.
That fixed the problem with this disc. Thank you!
Do you upload logs if possible? I want to see if it's fixed as I expected.
LBA 10714 belongs to the track 2 but I think DIC takes it as a part of track 1
Uploaded test version.
https://www.mediafire.com/file/eq80y20l … st.7z/file
Can't help at all? Not in any circumstances?
I'm not sure because I don't have GD-R. Can dump GD-R without /be?
Sarami, is there any downside to adding the "/be pack" command when dumping DC HD Area?
Due to "/be pack", _mainError.txt is so big size. This option is not need for Plextor.
Sarami is it possible for DIC to properly dump DVDs that have data in two layers?
Perhaps, it's not possible due to the filesystem problem.
when I do, DIC dumps the disk, and then hangs on the headquarters
"Rewrited img (LBA) 248676/299058"
And I don't know if I'm doing it right or wrong. This is how I set up this command
/c2 5000 1 248676 252396
Try to reduce the retry count from 5000 to 20 if the app really hangs.
all the dumps have 49 errors
It's weird. Your disc is no c2 and no mainError.
Let me know if you need something more
Is there executable binary in disc 2? If there is not, it's difficult to find its protection.
Sarami, would you look at one of my disks?
There are c2 errors. You need to get another disc or polish it.
I cannot dump one disc, namely the CD from the "newspaper" (actually a cardboard) Kinderland Extra 4/2006. I have strange errors when trying to dump my disk
Sarami, would you look at this?
If it's not the protected disc, do not use /sf and /ns.
NumberOfDIUnits are not Number of layers.
Number of layers of your disc is 1.
DIUnitFormatDependentContents
NumberOfLayers: 01
LayerType: 02 (Writable)
ChannelBit: 01 (74.5 nm)I noticed that the _disc.txt file seems to have four times the information
NumberOfDIUnitsInEachDIBlock: 04I'm not sure where this information is being derived from
PIC.bin
Redump Forum → Posts by sarami
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.