You are not logged in. Please login or register.
Redump Forum → Posts by sarami
@mictlantecuhtle
I'm changing the code for dumping the multi-session disc https://github.com/saramibreak/DiscImag … issues/208 . Please wait a few days.
EDIT
Updated test version. https://github.com/saramibreak/DiscImag … r_test.zip
- deleted: /ms and the related code
Plextor is not able to fix C2 errors on this disc.
Does it means that plextor cannot fix errors by 5000 times? If yes, plz specify 10000, 20000, 30000...
The problem only affects this one disc and interestingly only the LG drive
Can you check yourself the different bytes of the two "SHOK_PL_CD1.bin"?
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.
dumping it on sectors with SCSI errors
Disc can't be dumped due to this problem. I recommend this disc is polished.
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
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
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
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".
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?
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.
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.
Ok, but how to explain the following:
For this issue? https://github.com/saramibreak/DiscImag … issues/154
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.
After I applied fix above C2 rereading algorithm started to work
Thanks debugging and patching. I also confirrmed that your patch is working.
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.
is the C2 file using combined offset?
I deleted it. https://github.com/saramibreak/DiscImag … b1da037109
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.
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.
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]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.