this is a list of problems i and other people had with IB / EAC, and some possible answers but please comment, if you have something to add, ok? or if something's wrong
IsoBuster 2.3 / data track dumping
q: how to dump two sequential data tracks?
a: just as always with IB but if ther's an gap at the end of the 1st, you would need to relocate it to the beggining of second (actually move bytes, not just cut and replace with silence, like with audio) and afterwards modify cue sheet accordingly, e.g. PSX with gap of 2 seconds:
FILE "Track 01.bin" BINARY
TRACK 01 MODE2/2352
INDEX 01 00:00:00
FILE "Track 02.bin" BINARY
TRACK 02 MODE2/2352
INDEX 00 00:00:00
INDEX 01 00:02:00
safest way to determine gap presence, i guess, would be with 'CD Tool', to look in subcode or extract it to .sub but you can try to dump it with Alcohol (preferable) also or CloneCD and examine with 'Subcode Analyzer' afterwards. for example this is how gap between Breath Of Fire IV (J) data tracks looks:
Alcohol .sub in Subcode Analyzer (SCA counts frames from 1, not zero so ther's +1 difference):
Frame P Q-CONTROL Q-ADDRESS Q-TNO Q-INDEX Q-MIN Q-SEC Q-FRAME Q-ZERO Q-AMIN Q-ASEC Q-AFRAME Q-CRC16
278311 000000000000000000000000 4 1 01 01 61 50 60 00 61 52 60 8443
278312 000000000000000000000000 4 1 01 01 61 50 61 00 61 52 61 3e33
278313 000000000000000000000000 4 1 02 00 00 01 74 00 61 52 62 7d85
278314 ffffffffffffffffffffffff 4 1 02 00 00 01 73 00 61 52 63 0a70
CD Tool:
278310:
00000000000000000000000041010161
50600061526084430000000000000000
278311:
00000000000000000000000041010161
5061006152613E330000000000000000
278312:
00000000000000000000000041020000
0174006152627D850000000000000000
278313:
FFFFFFFFFFFFFFFFFFFFFFFF41020000
0173006152630A700000000000000000
278314:
[FFFFFFFFFFFFFFFFFFFFFFFF][4][1][02][00][00
0172][00][615264][D0C6]0000000000000000
so you see, P is set, INDEX=0, MSF counts backwards. this is how gap is defined on subcode level
and if there is such pattern at the end of 1st track, you'd know it's there and so you can determine gap's sizeq: ther's always a lot of errors between two consecutive data tracks (at the very end of 1st) and it gets very slow and...
a: please try the drive that supports d8 (e.g. Plextor) or you could try to use audio cd to replace TOC and read data that way: please read this guide for details. (but when it's done, please remember to do scan for errors with cdmage or such)
q: i'm looking in IB .cue and it's Mode 2, even though i'm sure it can't be.
a: there's apparently a bug so it would always determine Mode 2 on some (all?) Lite-On (could be other brands too) drives. to be sure, please, use any other software or examine extracted track manually (4th byte after sync denotes track mode. (e.g. byte 16th from offset 0))
q: data track is followed with audio and it looks like ther's still some data in determined gap...
a1: if combined offset is positive there may be junk (scrambled data) that looks somewhat like valid data but is not aligned on sector boundaries and MSF is XORed. if you'd uncramble it, you'd see it's a part of last or few last data sectors, nothing more.
some drives may scramble audio silence at the end of such track so it will not appear much dissimilar from data. you can distinguish such data by sync + $01 $80 $00 $60 <- it's a scramble pattern (not a real header) and unscrambles to $00.
it's safe to remove those, and should be - it's not a real data.
a2: however if you are convinced that it is data, possibly gap size was determined incorrectly - can happen with EAC, especially on PCE, SCD, SS, early PC CDs. it's mainly because such CDs often contain q-Mode 2 subcode frames and EAC have problems with those. but you can usually tell by one-two frames difference from common values. in this case you'd have to remove less data than EAC says (it's also possible that EAC detect gap less than it is and so you would have to remove more or otherwise there would be junk left and CRCs would not match on different drives) and correct cue sheet manually. so for example EAC detected gap of 2.01 between data and audio track but you take a look 151 sector back from the end of data and it's valid sector there but next is with junk. so you remove 150 and change gap in .cue to 00:02:00
in other words, with some very, very rare exceptions, data track, that precedes audio ends with last valid data sector (or erroneous data sector, for PSX, sometimes) and gap starts either with silence (all $00) or some of this junk.
q: when dumping audio track that is followed by data track, extraction may hang in pre-gap or return errors.
a: it sometimes works when you hit 'cancel' and retry 2nd time. if not, different software may work.
q: drive return errors and extraction becomes very slow, when audio silence at the end of data track exceeds 2 seconds
a: Alcohol / CloneCD with 'skip errors' usually work much faster. so if it's really damn slow you could abort IsoBuster (but don't delete this file) and dump cd on one of those. then extract data track from Alcohol/CCD image, remove gap from the end. if this is an PlayStation cd, last sector in this new image may be erroneous so you can replace it with sector extracted from IsoBuster image (if you selected 'Replace with user data all zeroes') or replace with previous sector and correct MSF. and it's still much faster than extracting full track with IsoBuster - it can take as much as an hour for 5seconds audio silence. but please, be sure about what you do.
q: gap is huge, exceeds 2 seconds, and drive returns read errors, when trying to determine an offset.
a: you could try D8 method or fake TOC with an audio and then determine offset in dumped file relative from requested sector, like with D8.
q: looking for offset at the end of data track, tried everything but still nothing is there.
a1: there will be no scrambled data if combined offset end up negative. please try D8 method.
a2: if you can not use D8 and this cd has an audio track preceeding data it's possible to determine offset there (at the beginning of data track).
so for example 'Ys I & II: Ancient Ys Vanished' an PCE cd:
LBA of datatrack (track 02) is 3596 and ther's usually 150 data sectors in pregap (you need to know this. total gap size does not matter now) so you'd select 'Sector View' on audio track preceeding data (1st track for this cd) and enter 3445 (3596-151). if returned sector is all filled with scrambled data, you'd go further back and add full sector size to calculation (just like in guide). this scrambled data, at this position (before data track), it should always start with sync pattern: 00 FF FF FF FF FF FF FF FF FF FF 00, and first 00 counts as scrambled (offset always divides by 4 without remainder). this time it's @offset $4e4. so: $930-$4e4=$44c=1100 1100/4=275 so combined offset value is -275. since my drive offset was 30, write offset = -275 -30 = -305
a3: if there is no audio before data track it is still possible to determine offset if you read data as an audio stream, when you use an audio cd to replace original TOC.
q: when dumping PCE (possibly other early cd console) last data track, drive returns errors at the very end.
a: sometimes there might be empty Mode 0 sectors (Sync + Header with mode=0 + $00) or audio silence (2352 bytes of $00) and some drives will have problems with those. so then, if all your drives fail, and you want to be certain, once again, if reading data track with audio TOC works for you, please try it.
Exact Audio Copy v0.99pb4 / audio track dumping
q: ther's only 1 audio track following data track(s) (there could be several consecutive e.g. Saturn) and audio pregap is detected as 0...
a: it's a bug in EAC, it often will not see gap on CDs with such layout (in fact sees, if gap exceeds 2 seconds considerably, that's a bit strange...). you can determine gap size from subcode, the same way as described above.
q: audio tracks get listed as 'FILE "Track 02.wav" WAVE', is it ok?
a: well it's better to change WAVE to BINARY before submitting to db (though i'm not sure, maybe db accepts .cues with WAVE too), but anyhow if you followed guide faithfully, track content should not be affected in any way, it's just EAC does this.
q: i get sync errors at the end of the last audio track...
a: this means that either your drive does not overread or EAC does not overread with your drive. in 1st case, unfortunately, ther's nothing much you can do, unless you have other drive. in 2nd EAC will return even less data, than there is in LBA range, when overreading is enabled, and will even cut off data if last audio track is followed by data track (not lead-out!). so you can dump this track as sector range (little more than this track, in fact, to cover offset) with IsoBuster / Cdrwin or such program, that allows it, and then remove leading / succeeding data. for example: combined offset=590; Last Track=LBA 1000..2000. so you would extract sector range 1000..2002 (590 samples=1 sector + 2 more samples) and remove 590 samples from beginning and 586 from the end of this file (final file size should divide with 2352 without remainder).
for 2nd case it's also possible to disable overreading and redump this track with EAC - may work if relative offset is negative or if ther's still data track after last audio, like often on PCE, but otherwise this is not safe!! - dat will be lost and no warning given so you should do this only when comparing data to an existing dump.
q: data starts early in audio track succeeding data track and i get different CRCs on each drive...
a: EAC does not return data from pregap - replaces it with $00 instead, so if combined offset is negative and some audio data gets pushed back into pregap it will get nullified. please try extracting sector range, as described above only this time it should work on all drives. if you have drive that gets positive combined offset for this CD, it's results from EAC should be correct.
q: i selected 'Create CUE Sheet' but ther's ony 1st track listed, what's wrong?
a: again seems to be a bug in EAC. if 1st track is audio and 2nd data or if ther's 2 consecutive data tracks - only 1st will get listed. you could try to modify .cue from other application or create it manually.
