Pregap question

[jamjam]

Would it be safe to rip audio with no pregaps, then detect the pregaps with a different drive and prepend the pregap?

I ask because I finally have a drive with a big enough offset to rip -647 write offset discs, but it seems to be having trouble detecting pregaps on some discs with all 3 methods.

For example. Trying to verify Actua Soccer 3, but the detected pregap for track 2 is either 0, or some non 2.00 value. Track 2 definitely has a 2.00 pregap, because I've searched there for scrambled data and came up with a -647 write offset (and indeed matched the db by prepending a 2.00 pregap). With a different drive, the proper pregap is detected.

Note: This is for psx discs, so no data in the pregap as far as I am aware if that makes a difference.

[RiMMER]

It's an EAC bug. EAC can't detect pregaps on an audio track IF the disc has only 2 tracks. Just dump the audio track without detecting the pregap and THEN append the pregap manually.

[jamjam]

Thanks.

[F1ReB4LL]

Would it be safe to rip audio with no pregaps, then detect the pregaps with a different drive and prepend the pregap?

If the combined offset is positive, better dump it with clonecd and cut the pregap from there instead of generating it.

[jamjam]

How would I do that? Would  I have to dump the whole disc with clonecd, then a track by eac with no pregaps, to find the eac dump in the clonecd dump?

[F1ReB4LL]

Dump the whole disc, then cut the proper bytes range. You need to skip the (1st_track_size_in_bytes + combined_offset_size_in_bytes) and cut the pregap_size_in_bytes (for 00:02:00 it's 352800 bytes).

[jamjam]

Thank you for the information. Will come in handy.

[Nexy]

you can also dump it with isobuster using the from-to way. If you know how the guide works and follow the instructions for dumping the data track, you already know where the pre-gap starts. Then you just dump from there to the the LBA of Track02+1 sector.

You then need edit the pregap a bit in a hex editor, you need to cut the crap bytes off the start (the ones you used to detect offset) note how many bytes it is. Then in a calculator you do 2352-bytes, the result is how many bytes to cut off the end of the pre-gap.

It's easy to figure out than the clonecd way.

[jamjam]

That sounds sensible, thanks.

Hopefully one day soon, I won't require hand-holding