withered.silence wrote:
Am I doing something obviously wrong here?
Firstly, please use the latest version. https://github.com/saramibreak/DiscImag … g/20230413
And try without /am, plz.
76 2023-05-06 10:45:40
Re: DiscImageCreator (3,521 replies, posted in General discussion)
77 2023-04-08 14:19:52
Re: DiscImageCreator (3,521 replies, posted in General discussion)
MrPepka wrote:
dumping it on sectors with SCSI errors
Disc can't be dumped due to this problem. I recommend this disc is polished.
78 2023-04-01 08:05:58
Re: DiscImageCreator (3,521 replies, posted in General discussion)
https://github.com/saramibreak/DiscImag … g/20230401
*2023-04-01
- added: Track[0] to _SubReadable.txt
- added: (Track 0), (Track 1)(-LBA), (Track AA), (Track all) when audio CD is dumped
- added: get non-zero byte position (1st and last) of the each track to the _disc.txt
- added: SIZE_OF_ARRAY macro
- deleted: /vrfy option and related code
- fixed: universal hash (changed sample base, not byte)
- fixed: the range of the SubQ check
- fixed: and improved C2 error recovering
79 2023-03-27 17:17:27
Re: DiscImageCreator (3,521 replies, posted in General discussion)
reentrant wrote:
Thx. Btw, could you also add command line parameter for setting c2 offset value (if there's no value assume 0)?
https://www.mediafire.com/file/eq80y20l … st.7z/file
2nd value of /c2 is the c2 offset
80 2023-03-27 04:24:36
Re: DiscImageCreator (3,521 replies, posted in General discussion)
reentrant wrote:
I think when you specify "lpNextBuf" you assume 294 C2 offset but what for drives that have 0 C2 offset?
Maybe it should be like that:
I've not confirmed the c2 offset of the non-plextor drive, but I'll add it.
Edit
added
https://www.mediafire.com/file/eq80y20l … st.7z/file
81 2023-03-26 19:06:02
Re: DiscImageCreator (3,521 replies, posted in General discussion)
reentrant wrote:
It's actually what I see - 8 bytes difference! I think that without taking into account that additional offset value c2 rereading algorithm is not correct. Plz could you also implement this - it's so close to have a perfect c2 rereading algorithm
8 bytes difference --- It's 1 byte (8 bits) for .c2 file. then at that time, I understood "Additional Offset" that ehw says is "PX-712 or newer drive have 295 byte offsets, not 294".
Foxhack wrote:
why this error is happening?
Merely HDDVD drive doesn't support DVDGetRegion. Same error occurs for my GGW-H20N.
Btw, other application (e.g. isobuster) can dump your disc? How many HDDVD do you have? All HDDVD you have can't be dumped?
82 2023-03-26 12:50:19
Re: DiscImageCreator (3,521 replies, posted in General discussion)
reentrant wrote:
Should be interpreted as being shifted by combined offset if you try to match these pointers to specific sector in SCM.
It's easy to add the combined offset value to "ofs: xxx".
ofs: 3e2 + 0x20, 3e3 + 0x20, ...
But if it also applies to .c2 file, it needs to be shfted to right by 0x20 bits. It's very complicated.
reentrant wrote:
It's still a question why I had to shift data by additional 8 bytes (2 samples). I have a feeling that not all Plextors 760 have equal C2 offset...
I have no idea. If you have other 760 drive, you can try it.
83 2023-03-26 09:32:43
Re: DiscImageCreator (3,521 replies, posted in General discussion)
reentrant wrote:
Ok, but how to explain the following:
For this issue? https://github.com/saramibreak/DiscImag … issues/154
Foxhack wrote:
it won't let me dump an HDDVD because it shows me that error above ([F:DVDGetRegion][L:472] GetLastError: 1, Incorrect function.)
I tried to dump HDDVD using GGW-H20N and it's no problem. Its error is not related.
84 2023-03-25 13:29:07
Re: DiscImageCreator (3,521 replies, posted in General discussion)
reentrant wrote:
After I applied fix above C2 rereading algorithm started to work
Thanks debugging and patching. I also confirrmed that your patch is working.
reentrant wrote:
Another thing is that it looks like single bit in C2 file should be treated as if there were 2 erroneous bytes in image file. Some bits are not reported in C2 file and 2 bytes are bad in image. It's weird.
Yes, it's known issue. For this reason, C2 error disc sometimes doesn't recover if the drive doesn't return C2.
reentrant wrote:
is the C2 file using combined offset?
I deleted it. https://github.com/saramibreak/DiscImag … b1da037109
85 2023-03-23 03:37:09
Re: DiscImageCreator (3,521 replies, posted in General discussion)
reentrant wrote:
an you check the algorithm and verify it rereads / writes correct bytes?
If there are not non-zero byte in your .c2 file, the drive judges there are not c2 errors in your disc.
86 2023-03-18 01:02:51
Re: DiscImageCreator (3,521 replies, posted in General discussion)
user7 wrote:
TSST TS-H352 supports C2 with data tracks, but not support C2 with audio tracks.
However when trying to dump a DC disc with a single data track in the HD area I get the error "[WARNING] This drive doesn't support reporting C2 error. Disabled /c2".
DIC dumps data sector as "audio" to get the scrambled sector.
87 2023-03-17 07:47:07
Re: DiscImageCreator (3,521 replies, posted in General discussion)
superg wrote:
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"?
88 2023-03-16 01:54:49
Re: DiscImageCreator (3,521 replies, posted in General discussion)
MrPepka wrote:
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.
89 2023-03-15 06:57:27
Re: DiscImageCreator (3,521 replies, posted in General discussion)
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)
90 2023-03-09 12:56:34
Re: DiscImageCreator (3,521 replies, posted in General discussion)
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"
91 2023-03-06 12:52:17
Re: offset shifting discs (14 replies, posted in General discussion)
I decided that both dumps like Subs vs. TOC desync disc (http://redump.org/disc/37134/). "TOC control" is in priority.
92 2023-03-05 03:27:00
Re: offset shifting discs (14 replies, posted in General discussion)
sarami wrote:
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.
reentrant wrote:
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.
superg wrote:
(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?
superg wrote:
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.
superg wrote:
(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/ )
superg wrote:
(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.
93 2023-03-04 10:34:01
Re: DiscImageCreator (3,521 replies, posted in General discussion)
bikerspade wrote:
That fixed the issue
Thanks. it was committed. https://github.com/saramibreak/DiscImag … 2ea246f1a5
94 2023-03-03 09:11:11
Re: offset shifting discs (14 replies, posted in General discussion)
Jackal wrote:
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
superg wrote:
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"?
95 2023-03-03 06:47:26
Re: DiscImageCreator (3,521 replies, posted in General discussion)
bikerspade wrote:
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
96 2023-03-02 02:18:32
Re: DiscImageCreator (3,521 replies, posted in General discussion)
MrPepka wrote:
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]97 2023-02-01 11:06:26
Re: DiscImageCreator (3,521 replies, posted in General discussion)
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 ARccOSsadikyo wrote:
The 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 offsetsadikyo wrote:
* Occasional imperfect track splits
Why not report as a bug if it is really true?
98 2023-01-15 02:20:17
Re: DiscImageCreator (3,521 replies, posted in General discussion)
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]99 2023-01-14 10:09:07
Re: DiscImageCreator (3,521 replies, posted in General discussion)
superg wrote:
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.
100 2023-01-13 10:19:21
Re: DiscImageCreator (3,521 replies, posted in General discussion)
bikerspade wrote:
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.