On the Ys IV sample disc, track 1, all data from the start to 18735 (decimal) is zeroed. All data from 7063856 until the end is also zeroed.

By the way, track 1 is not the warning track commonly found in Japanese games. It's actually the English warning track found in US releases.

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.

themabus wrote:

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

How do I do this?

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

What is the swapping method?

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:

http://img397.imageshack.us/img397/9558/48072416.png

to 01CF492F:

http://img60.imageshack.us/img60/1387/47021054.png

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.

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:

http://img228.imageshack.us/img228/9581/track041.th.png

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:

http://img86.imageshack.us/img86/5133/track042.th.png

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

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

Hi, I have a couple questions about dumping a special PC Engine CD that I would like to contribute to the database and make available through the net. The title is a store demo version of Ys IV with various differences from the released game. I'd like to get the most accurate rip possible, so I'm using Redump standards.

I read through the PC Engine topics on the forum and it seems the exact format in how exactly to handle pregap information may still be under debate. I've gotten some of the requisite strange numbers in experimenting with ripping this disc, so I'd like some advice on how to get the most accurate rip possible.

1. I'm not sure I quite understand offset value correction. With PC Engine CDs, is the offset value correction in EAC handled the same way as with other systems? Because track 1 is a music track, track 2 is a data track, and then track 3 is another music track with a different pregap value, do I need to rip the first music track with a different offset value correction than track 3? What about track 4, which has a pregap of 0?

http://img530.imageshack.us/img530/6559/pcengine.th.png

2. The Redump PC Engine images I've downloaded from Underground Gamer have had both the data tracks as .bin extensions rather than the standard .iso rips I'm getting from Isobuster. Is there some sort of extra conversion process to .bin or do I just change the file extension?

3. I'm running Vista, so I can't get Resize to run. Manually editing the file with a hex editor should provide the same result, correct?

Thanks in advance for any information or advice you can give me.