Redump Forum

Posted: **Sat Oct 31, 2020 7:37 pm**

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.

Posted: **Sat Oct 31, 2020 9:45 pm**

wiggy2k wrote: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.

Posted: **Sun Nov 01, 2020 1:34 pm**

- 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?

Posted: **Sun Nov 01, 2020 6:19 pm**

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

Posted: **Mon Nov 02, 2020 9:34 am**

user7 wrote: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

Jackal wrote: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.

Posted: **Mon Nov 02, 2020 10:16 am**

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

Posted: **Mon Nov 02, 2020 1:12 pm**

sarami wrote: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.

Posted: **Mon Nov 02, 2020 5:16 pm**

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?

Posted: **Mon Nov 02, 2020 5:21 pm**

sarami wrote: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

Posted: **Tue Nov 03, 2020 12:46 am**

user7 wrote:but strange failure not making img file (only scm)

Is there error messages on the command-line screen?

Jackal wrote: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

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

I requested to Agent47.

reentrant wrote: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.

F1ReB4LL wrote: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.

Redump Forum

DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator