DiscImageCreator

[wiggy2k]

just curious, is there a switch I can use to allow using an older unsupported (but used to be) Plextor like a Plexwriter 12/10/32A I'd like to compare some tracks from difficult discs like Eikan3.

[sarami]

just curious, is there a switch I can use to allow using an older unsupported (but used to be) Plextor like a Plexwriter 12/10/32A I'd like to compare some tracks from difficult discs like Eikan3.

Use cdtoimg (simple 0xd8 dumping tool) http://www.mediafire.com/file/9b31r4fv4 … g.rar/file


https://github.com/saramibreak/DiscImag … g/20201101

Code: Select all

*2020-11-01
- added: detect cppm
- added: /ps flag for dvd command (for [PS2] Katamari Damacy (USA))
- added: support HL-DT-ST UH12NS40 1.00 and HL-DT-ST WH14NS40 1.01 as 0xF1 drive (thanks olofolleola4)
- added: if TOC is weird, fix it (for [CD-i] Op Jacht Naar Vernuft (Netherlands))
- added: output TOC (binary) to _mainInfo.txt
- added: output P-channel and Q-channel gaps to _subInfo.txt
- added: execute "ad 00 00 00 00 00 00 03 00 c0 00 00" forcibly when the drive recognizes Nintendo disc
- changed: css-auth to DVDAuth_linux
- fixed: firmware version of BC-12D2HT
- fixed: output incorrect pregap when Q-channel's pregap is 00:01:74 and the adr of 00:01:74 is 2(MCN) or 3(ISRC)
- fixed: escape the c2 error "F0 F0 F0 00 00 00 0F 0F 0F"
- fixed: check the offset twice when the combined offset is over 1 sector.

[Jackal]

- fixed: output incorrect pregap when Q-channel's pregap is 00:01:74 and the adr of 00:01:74 is 2(MCN) or 3(ISRC)

I'm lost now

This new version produced the same (bad?) dump as old versions (from 2019 and earlier) for this disc: https://redump.info/disc/25734/

"01:74 is wrong, because the P and Q gaps are in sync and P-channel shows 00:02:00 gap there"

That disc was the reason that we were rechecking everything: /viewtopic.php?t=26898 … he-damage/

New logs: https://cdn.discordapp.com/attachments/ … 0/Hexen.7z

So please tell us. How to identify possible bad dumps and which version should be used to redump them? And this new fix is invalid?

[user7]

Tried with new DIC build, same problem that Op Jacht had (failed to find write offset), very cheap:
https://www.discogs.com/Various-Het-Nat … ase/613001

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

[sarami]

Tried with new DIC build, same problem that Op Jacht had (failed to find write offset)

It's not the same. TOC is not corrupt. This is another bug.
Try it please. http://www.mediafire.com/file/eq80y20l9 … st.7z/file

And this new fix is invalid?

Ah... Yes.

The problem is that there is MCN or ISRC in the 1st pregap sector or last sector of the track.

Hexen

Code: Select all

LBA[021026, 0x05222]: P[00], Q[41010104402600044226d37d]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[04:40:26], AMSF[04:42:26]}, RtoW[0, 0, 0, 0]
LBA[021027, 0x05223]: P[00], Q[4200000000000000002707ea]{ Data,      Copy NG,                  MediaCatalogNumber [0000000000000], AMSF[     :27]}, RtoW[0, 0, 0, 0]
LBA[021028, 0x05224]: P[ff], Q[0102000001740004422895f9]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[00:01:74], AMSF[04:42:28]}, RtoW[0, 0, 0, 0]

Quake /viewtopic.php?p=25885#p25885

Code: Select all

LBA[050679, 0x0c5f7]: P[00], Q[11030102240000111754c937]{Audio, 2ch, Copy NG, Pre-emphasis Yes, Track[03], Idx[01], RMSF[02:24:00], AMSF[11:17:54]}, RtoW[0, 0, 0, 0]
LBA[050680, 0x0c5f8]: P[00], Q[12000000000000000055bfb3]{Audio, 2ch, Copy NG, Pre-emphasis Yes, MediaCatalogNumber [0000000000000], AMSF[     :55]}, RtoW[0, 0, 0, 0]
LBA[050681, 0x0c5f9]: P[ff], Q[11040000017300111756fab3]{Audio, 2ch, Copy NG, Pre-emphasis Yes, Track[04], Idx[00], RMSF[00:01:73], AMSF[11:17:56]}, RtoW[0, 0, 0, 0]

Q-channel can't distinguish which track it belongs to because there isn't the track number.
I thought it could distinguish with P-channel, but It isn't necessarily so. Because P and Q-channel often mismatch.

P and Q-channel of the track02 of Hexen are estimated that it matches because all P and Q-channel of the other track match. As a result, 021027 belongs to the track02.
P and Q-channel of the track04 of Quake are estimated that it does not match because all P and Q-channel of the other track don't match. As a result, 050680 belongs to the track03.


If P and Q-channel of one track match/mismatch, P and Q-channel of all track match/mismatch. Is this hypothesis completely true? I'm not sure.

[user7]

Thanks sarami it dumps now but strange failure not making img file (only scm) https://drive.google.com/file/d/1Nx1y_r … sp=sharing

[Jackal]

P and Q-channel of the track02 of Hexen are estimated that it matches because all P and Q-channel of the other track match. As a result, 021027 belongs to the track02.
P and Q-channel of the track04 of Quake are estimated that it does not match because all P and Q-channel of the other track don't match. As a result, 050680 belongs to the track03.

So the logic before the 2020-11-01 version was to look at P-channel when Q-channel wasn't available? I agree with F1ReB4LL that it's best to stick with this logic, unless there is such a thing as a P-Q offset

I don't understand the new fix. With the new fix, the Quake track04 pregap would become 02:00? This seems wrong, when the other tracks are all 01:74.

[reentrant]

Sarami, I just got ASUS BW-16D1HT and tried to rip disc with big positive offset: 1611. Last sector of last track is different than Plextor 760. Is it expected? What's the biggest positive offset that ASUS is able to handle?

[F1ReB4LL]

P and Q-channel of the track02 of Hexen are estimated that it matches because all P and Q-channel of the other track match. As a result, 021027 belongs to the track02.
P and Q-channel of the track04 of Quake are estimated that it does not match because all P and Q-channel of the other track don't match. As a result, 050680 belongs to the track03.

It should detect the normal (P and Q matching) gaps properly, like in Heretic. Cases similar to Quake probably needs a manual checking, I don't think it's possible to do it automatically.
---


https://mega.nz/folder/gYA1QaRJ#l6P1PTC … e/NJJhACzb - .ccd file is probably wrong

Code: Select all

[Entry 0]
Session=1
Point=0xa0
ADR=0x01
Control=0x00

Code: Select all

[Entry 2]
Session=1
Point=0xa2
ADR=0x01
Control=0x00

CloneCD ccd file says: "Control=0x04" for both

[sarami]

but strange failure not making img file (only scm)

Is there error messages on the command-line screen?

I don't understand the new fix.

Added some log into _subInfo.txt and some changed. http://www.mediafire.com/file/eq80y20l9 … st.7z/file

With the new fix, the Quake track04 pregap would become 02:00?

I requested to Agent47.

Sarami, I just got ASUS BW-16D1HT and tried to rip disc with big positive offset: 1611. Last sector of last track is different than Plextor 760. Is it expected? What's the biggest positive offset that ASUS is able to handle?

I also noticed it recently, but I don't change the src about 0xF1 drive.

CloneCD ccd file says: "Control=0x04" for both

Is the same drive used? If yes, I don't know why the value is different. DIC merely outputs the value that returned by the drive.