3,501

bikerspade wrote:

http://forum.redump.org/topic/55215/neo … odown-iii/

When dumped with DiscImageCreator, it does not produce a CATALOG in the cuesheet. When dumped with redumper, it does. Which one is correct?

DIC logs: https://drive.google.com/file/d/1tBKDvZ … sp=sharing

Between 20240101 and 20240401 DiscImageCreator changed how it creates .cue files from being based on subchannel information to being based on the TOC (more context in this issue). Those logs were made with 20230606, does this happen with the latest stable version?

3,502

Lugamo wrote:

Between 20240101 and 20240401 DiscImageCreator changed how it creates .cue files from being based on subchannel information to being based on the TOC (more context in this issue). Those logs were made with 20230606, does this happen with the latest stable version?

There is not CATALOG (MCN) in TOC and Full TOC.

Reported redumper issue here: https://github.com/superg/redumper/issues/143

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,504 (edited by bikerspade 2024-05-10 17:48:03)

Here is where the MCN is being pulled (reference):

[LBA:   -151, LBAQ: 134850] control: 0000, ADR: 2, 12 34 56 78 90 12 30 00 00, crc: D1EB (+) P: 0/96
BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,505

Ok. I confirmed that MCN is only recorded in subchannel of the lead-in area. That would mean that drive other than Plextor can't  get MCN.

LBA[041175, 0x0a0d7]: P[00], Q[4100a0091100000100002791]{ Data,      Copy NG,                  Track[00], Point[a0], AMSF[09:11:00], TrackNumOf1stTrack[01], ProgramAreaFormat[00]}, RtoW[0, 0, 0, 0]
LBA[041176, 0x0a0d8]: P[00], Q[4100a0091101000100008dc0]{ Data,      Copy NG,                  Track[00], Point[a0], AMSF[09:11:01], TrackNumOf1stTrack[01], ProgramAreaFormat[00]}, RtoW[0, 0, 0, 0]
LBA[041177, 0x0a0d9]: P[00], Q[4100a0091102000100006312]{ Data,      Copy NG,                  Track[00], Point[a0], AMSF[09:11:02], TrackNumOf1stTrack[01], ProgramAreaFormat[00]}, RtoW[0, 0, 0, 0]
LBA[041178, 0x0a0da]: P[00], Q[02123456789012300000ebd1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [1234567890123], AMSF[     :00]}, RtoW[0, 0, 0, 0]
LBA[041179, 0x0a0db]: P[00], Q[02123456789012300000ebd1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [1234567890123], AMSF[     :00]}, RtoW[0, 0, 0, 0]
LBA[041180, 0x0a0dc]: P[00], Q[02123456789012300000ebd1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [1234567890123], AMSF[     :00]}, RtoW[0, 0, 0, 0]
LBA[041181, 0x0a0dd]: P[00], Q[0100a1091106002000006e2b]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[00], Point[a1], AMSF[09:11:06], TrackNumOfLastTrack[20]}, RtoW[0, 0, 0, 0]
LBA[041182, 0x0a0de]: P[00], Q[0100a109110700200000c47a]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[00], Point[a1], AMSF[09:11:07], TrackNumOfLastTrack[20]}, RtoW[0, 0, 0, 0]
LBA[041183, 0x0a0df]: P[00], Q[0100a109110800200000a183]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[00], Point[a1], AMSF[09:11:08], TrackNumOfLastTrack[20]}, RtoW[0, 0, 0, 0]
LBA[041184, 0x0a0e0]: P[00], Q[02123456789012300000ebd1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [1234567890123], AMSF[     :00]}, RtoW[0, 0, 0, 0]
LBA[041185, 0x0a0e1]: P[00], Q[02123456789012300000ebd1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [1234567890123], AMSF[     :00]}, RtoW[0, 0, 0, 0]
LBA[041186, 0x0a0e2]: P[00], Q[02123456789012300000ebd1]{Audio, 2ch, Copy NG, Pre-emphasis No, MediaCatalogNumber [1234567890123], AMSF[     :00]}, RtoW[0, 0, 0, 0]
LBA[041187, 0x0a0e3]: P[00], Q[0100a2091112006400394d15]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[00], Point[a2], AMSF[09:11:12], StartTimeOfLead-out[64:00:39]}, RtoW[0, 0, 0, 0]
LBA[041188, 0x0a0e4]: P[00], Q[0100a209111300640039e744]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[00], Point[a2], AMSF[09:11:13], StartTimeOfLead-out[64:00:39]}, RtoW[0, 0, 0, 0]
LBA[041189, 0x0a0e5]: P[00], Q[0100a2091114006400398090]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[00], Point[a2], AMSF[09:11:14], StartTimeOfLead-out[64:00:39]}, RtoW[0, 0, 0, 0]

3,506 (edited by bikerspade 2024-05-11 16:52:00)

Thank you for confirming. I’m not sure what the correct behavior should be, even if it would be limited to some drives.

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,507

bikerspade wrote:

Thank you for confirming. I’m not sure what the correct behavior should be, even if it would be limited to some drives.

Generally, MCN is recorded per 98 frames in subchannel of the lead-in, track, lead-out area. The presence of numerous indexes on track 1 of the NeoGeo CD is said to be a type of protection. The presence of MCNs only in the lead-in may also be a type of protection.

3,508

https://github.com/saramibreak/DiscImag … g/20240601
*2024-06-01
- added "DVDRawBruteforce - Drive Sheet - Sheet1.tsv" to get DVD raw sector size etc.
- added support to dump DVD raw sector (2304 bytes/sector)
- added support to descramble of DVD raw (2236 bytes/sector)
- fixed /a is invalid when pregap sector exists in the 1st track.
- fixed infinite loop occurs when reading UDF
- fixed output Joliet identifiers
- fixed smartE sectors don't descramble
- fixed regression in track handling between versions 20240101 and 20240401
- fixed output irregular CD-TEXT

3,509

https://github.com/saramibreak/DiscImag … g/20240901
*2024-09-01
- added support meson
- added /trp option to skip creating pregap sectors of track 1 starting from minus LBA
- added /ra to the bd command
- changed SS.bin output place
- changed SpeedRead Setting
- changed filename of the (Track 0), (Track 00) and (Track AA) to (Lead-in)(Track 0), (Lead-in)(Track 00) and (Lead-out)(Track AA)
- improved detecting 1st track pregap sector when reading lead-in
- fixed error handling when lead-in area is read
- fixed overflow iso9660 filename
- fixed Kreon drive on Linux with CDB10 for libata
- fixed UDF Volume Identifier not detected
- fixed failed to output "There is non-zero byte in the (Lead-out)(Track AA)" to the _disc.txt

3,510

https://github.com/saramibreak/DiscImag … g/20241001
*20241001
- added support to dump DVD raw sector (2816 bytes/sector)
- fixed skip hashing of (Track all).img when /trp is 0

3,511 (edited by user7 2024-11-03 15:43:41)

/sf doesn't seem to skip dummy sectors on PS2 unlicensed discs anymore.

Not sure when this change would have occurred, but dumping these sectors is very slow.

All my posts and submission data are released into Public Domain / CC0.

3,512

Here are the logs of 3 dump attempts. First two I cancelled the dump at the end, it tries to reread c2 sectors despite /sf. 3rd dump is run with /c2 0 /sf but has to many errors.

https://drive.google.com/file/d/1iWG15X … drive_link

3,513

Here another dump of same disc on old DIC 20211101T132455

https://drive.google.com/file/d/1Yj0BxG … drive_link

3,514

user7 wrote:

/sf doesn't seem to skip dummy sectors on PS2 unlicensed discs anymore.

It has occurred since 20231201. http://forum.redump.org/post/113507/#p113507

Uploaded.
Windows: https://www.mediafire.com/file/eq80y20l … st.7z/file
Linux: https://www.mediafire.com/file/uw3e03kd … ar.gz/file

3,515

log: https://drive.google.com/file/d/1JYr4-c … drive_link

Tested with test build, I think it is still wrong?

3,516

gmipf wrote:

Tested with test build, I think it is still wrong?

Fixed.
Windows: https://www.mediafire.com/file/eq80y20l … st.7z/file
Linux: https://www.mediafire.com/file/uw3e03kd … ar.gz/file

3,517 (edited by gmipf 2024-11-06 18:14:00)

Seems to work now.

https://drive.google.com/file/d/1snEP2R … drive_link

3,518

sarami, your github README mentions that 4824 is not good for "Securom 3"

Protected CD:

  • SecuRom 3

    • PLEXTOR PX-4824A (ecc/edc of the 2 sector doesn't match)

  • CDS100, CDS200, Label Gate, XCP

    • PLEXTOR PX-4824A (doesn't get the TOC correctly)

Which particular discs did you encounter that had issues? I have not encountered any yet.

Also, regarding CDS100/CDS200/Label Gate/XCP, using the Full TOC works with the 4824 to get matching hashes. And only XCP1 has illegal TOC (retail XCP discs use XCP2 which does not have an illegal TOC, 4824 has no problems with them).

3,519

Deterous wrote:

Which particular discs did you encounter that had issues? I have not encountered any yet.

Diablo II (USA) (Play Disc). Serial is S7092920. If it's dumped by PX-755, it's no error. But this may be a problem with my PX-4824.

Deterous wrote:

regarding CDS100/CDS200/Label Gate/XCP, using the Full TOC works with the 4824 to get matching hashes.

It's TOC that I mention, not FULL TOC. But if Full TOC gets LBAs correctly, I'll change from TOC to FULL TOC in the future.

3,520 (edited by Deterous Yesterday 02:48:43)

sarami wrote:

Diablo II (USA) (Play Disc). Serial is S7092920. If it's dumped by PX-755, it's no error. But this may be a problem with my PX-4824.

I dumped Diablo II (Korea) (Play Disc) just fine with my 4824 http://redump.org/disc/119191/

sarami wrote:

It's TOC that I mention, not FULL TOC

Yes I can confirm that the 4824 does get the wrong TOC for Label Gate and CDS200, splitting the scram into bin with --force-qtoc on redumper fixes it.
However the Full TOC shouldn't be used by default, redump uses TOC splits.

3,521

Deterous wrote:

I dumped Diablo II (Korea) (Play Disc) just fine with my 4824

OK perhaps your PX-4824 is correct, if you or someone dump S7092920 with no error using PX-4824, I'll edit README.

Deterous wrote:

However the Full TOC shouldn't be used by default, redump uses TOC splits.

I'll add /fulltoc option for the drive returning broken TOC. TOC is default, Full TOC is 2nd choice.