PC Engine/dumping guide questions

hello Li Wang
it's great you decided to contribute to this project, so thank you very much

PCE CDs can be somewhat difficult to extract though unless you open up drive and do swapping
but i hope this won't be the case

to answer your questions:
1. offset value is not dependant on gaps in any way or vice versa,
gaps just happen to be place where it manifests
so once it is determined you would extract all tracks with same value
you can find offset for PCE CDs the same way as for the rest systems,
between Data->Audio tracks (when offset is positive) and also Audio->Data tracks (if it's negative)
so in this case you'll be looking at Track 02->03 gap at first as if they were Tracks 01 & 02 from guide
if nothing is there, then likely offset is negative and you should examine Track 01->02 gap instead

negative offset is determined following way:
click Sector View on Data Track (02) - IsoBuster should position on it's 1st sector from TOC
e.g. 3596
go 150 (usually but in rare cases this value can be different) sectors back
e.g. to sector 3446 and there should be sense error instead of nulls
(or it could probabbly be data sector on some drives but either way it shouldn't be nulls)
(this is how you can determine value different from 150 for previous step)
go one more sector back and there should be scrambled data
so for example on my +6 LiteOn drive Tengai Makyou: Ziria look this way:

and math is:
$930-$278=$6b8=1720
-1720/4=-430
-430-DriveOffset=-430-6=-436
if whole 1st page would be full with scrambled data you'd increase offset by -2352 or -$930 bytes, and so on

alternatively you could try Truman's excellent px_d8 program - it would really ease things a lot
but unfortunately most drives do not support this command
for LBA parameter any data sector can be given,
so 0 won't fit for PCE most of the time, but likely something around 4000 should

output for same CD on +30 Plextor:

Sector: 4000
MSF: 00:55:26
Combined offset: -1624 bytes / -406 samples

-406-DriveOffset=-406-30=-436

so i would extract with -430 offset on one drive, with -406 on the other and submit -436 to db

also very often for Japanese PCE CDs 1st track is common one with CRC value b979500c
this is the case for commercial release of Ys IV currently in db
and by track size also could be true for your CD
so this could hint whether offset was determined right or not

2. yes, you're right - in IsoBuster's options default extension can be configured to be either .iso or .bin
and does not influence file content in any way,
so as long as you extract raw 2352 byte data - it shouldn't matter

3. yes, it should be fine

one proble you'll run into though: Track 03 pregap appears to be determined incorrectly by EAC
(which can happen quite often for PCE CDs)
so likely you'll need to cut it's 1st sector after extraction -
you should be able to tell this from file sizes and content of last Track 02 sector after 2sec gap is removed

edit:
ah, i forgot about data track pregap - usually drive won't be able to extract it correctly,
so unless you'll be doing swapping
you'll need to determine of exactly how many data and audio sectors it consist
(like when looking for negative offset)
and then recreate it with generic data and prepend to Track 02

DJoneK: Yeah, I have the 64 bit version. I keep finding more reasons to wish I could have gotten this laptop loaded with XP or gone with 32. Blech. I'll try fiddling with Vista more tonight.

There's a new development with the dumping process that I didn't notice last night. EAC is giving me a sync error on track 4. Actually, it didn't occur last night since I had accidentally set a couple things incorrectly. Earlier I had not had the "Overread into lead-in and lead-out" option checked. When ripped with the option unchecked, EAC gives a track quality of 99.8% and does not report a sync error. When checked, the sync error is reported and the track quality is 92%. The files always come out byte for byte identical each time the track is ripped. Could this kind of thing be caused by a mastering error or some sort of junk data in the leadout rather than a surface defect? If it is a surface error, does the consistency of the data between different rips tell us that it's being compensated for correctly?

Overread log

No overread log

Thanks. ISOBuster is indeed giving me a different rip of the file, but as you mentioned there may be a problem with the offset value and in ripping the file. With 40 bytes trimmed from the beginning, the beginning of the track matches the EAC file. At the end of the file there may still be a problem. IsoBuster tells me 55844 can't be read (seems normal) and with the default "Replace with User Data All zeroes" option the end of the file looks like this:

Is that actual data that's showing up at the end or filler data by IsoBuster? Everything else is zeroes.

The data that corresponds to the ending of the EAC track can be seen here:

Does this look right? Everything after 30364320 bytes should be trimmed, correct?

I see. The data I'm getting from IsoBuster is actually very different at the end of the track. Instead of being all zeroes like with EAC, I'm getting different data from 01CF2488:

to 01CF492F:

Why is this?

I have another drive I'll try with IsoBuster later. I dumped track 4 with EAC using that drive earlier and I got an identical file as with EAC with this drive. I didn't get any errors with EAC through that drive. It uses caching, though.

I'm trying to rip some retail discs to compare with entries in the database to make sure I'm doing this right. I have a couple questions.

How do I do this?

Should the pregap for track 1 be showing as 2 seconds in EAC?

What is the swapping method?