Message for themabus/gigadeath - Ys 4 PCE help!

How? I try to calculate on the first data track (setting the read sector where the track starts) but nothing.
And how can you set the gaps to 3.00? What is the theory behind this?
If the gap is 3.00, the tracks have to be dumped with a "manual" procedure

hi, xenogears
i was more like testing so far myself and intended to write something like a brief summary next week (about 10% would be dumped), but well, since also gigadeath already joined in, and so far everything's seems fine, so ok..
but if some of mods or anyone think ther's something wrong with this, please let me know, ok? i just really hope it's allright

1)you can get offset using D8 as described in Vigi's guide , but difference is that ther's audio @LBA 0 for PCE, so you must use other one, to hit on data track, gigadeath's suggested 4350 will work most of the time. (i think this is the best way to go)

2)you still can do sector view method: for positive offseted CDs it's the same as for psx and the rest, only now you should look for scrambled audio at the track 02 -> track 03 boundary;
for negative (most PCE CDs) you should subtract amount of data sectors in audio->data transition area +1 from data track's LBA.
most often track 02 has LBA 3590 and 150 sectors in TA: 3590-151=3439. now on, math is just the same, just that you look for a scrambled data backwards.

3)you can try to use this awk script, it'll wrap px_d8 and do math, but if ther's something wrong with it, we will not know, so maybe you shouldn't..
to make it work you must place it in the same directory where ps_d8 is and execute command:
offset.bat <drive> <LBA> <DriveOffset>
like: offset.bat d 3600 30
and it'll do 3 readings and return result like this:
------------------------------
DRIVE Correction    30
------------------------------
LBA    Left    Rel.    Abs.
------------------------------
3600    135    -1311    -1341
3750    135    -1311    -1341
3900    135    -1311    -1341
------------------------------
PLEXTOR    ASUS    LITE-ON
------------------------------
-1311    517    -1335
------------------------------

last column: -1341, that repeats x3, it's absolute offset to submit to DB, it should always match. those at footer are offsets i'd use for my drives in EAC, to set up your drives you'd have to change 3 variables in offset.awk to you'r drive offsets (EACish, not reversed):
D1=30
D2=1858
D3=6

on audio:
gaps for PCE often are interpretable, and will wary depending on software. when those differences, as seen in EAC, are little (do not exceed 2 frames) from: 3 seconds audio->data; 2 seconds data->audio; 0 seconds audio->audio: it's so far always was either because of a different interpretation of subcode data or because one audio silence sector is left unmarked as pause. in all such cases we agreed to map gaps to this 3-2-0 scheme.
to do so:
1.1) audio->data gap < 3":
we cut corresponding count of sectors from the end of this dumped audio track:
for example: 2.74 gap for Track 02 in EAC - cut 1sector=2352 bytes from the end of Track 01
1.2)audio->data gap > 3":
we'd dump it with zero gap instead (<- this is very important! because otherwise data is lost), and then cut 3 seconds (=225 sectors) from the end.
**worst possible case it's when you have an audio track that is enclosed by data tracks (so you can't just ignore detected gaps) and this following data track gets gap detected larger than it should be, then you'd have to extract sector range or dump twice with and without gaps and then combine this data, but it's maybe on 1 cd from 100 or like so.
2.1)data->audio < 2":
add corresponding number of audio silence sectors to the beginning of affected audio track (psxt001z generated)
2.2)data->audio > 2":
remove that amount of sectors from beginning of this audio track.
3)audio->audio >0:
shift back those sectors from the beginning of track that follows gap, to the end of one that preceeds it. or alternatively just read such tracks without detecting gaps (like in 1.2 you can't ignore gaps if this 1st affected track is preceeded by data track).

(it's, maybe looks a bit bizarre, but actually most cd's are 3-2-0 or seldom with some minor changes, i mean, there can be 6 cds with correct gaps and then one with 6 messed up gaps, it's like that, so please don't worry about it, if ther's something very strange you can just skip it for now.)

from 50 CDs there's so far were, i think, 5 exceptions with different gaps (Ys 1&2/Ys 3 are two of them, btw), where this scheme would not work.

on data tracks:
data->audio gaps must be fixed the same way as always - removing audio sectors (so far always 150 on my tested CDs). if data track is the last one on CD, ther's no gap so this should not be done (<-again very important to remember).

and we did also agreed to fix audio->data gap structure. amount of sectors similar to the target gap must be added to data track that follows audio. but unlike data->audio gaps (where only audio part of transition area is set as pause), those consists of both parts: 1st audio silence (psxt001z --gen output); 2nd mode 1 empty sectors - my brother and i, we made a very basic program for those, that you can use.

so for Ys 4:
it's 2.74 audio->data gaps (case 1.1):
1.dump everything with IsoBuster/EAC as usually
2.remove 1sector=2352 bytes from the end of Track 01 and Track 31 (would be great, if you could check if this sector is silence)
3.remove 150 sectors from the end of Track 02 only. (again, it's better to always check if ther's no data, when you cut something, tho there can be scrambled audio that may appear somewhat like a data, depending on drive)
3.generate 75 audio silence sectors with psxt001z:
psx --gen "Track 02.000" 176400
psx --gen "Track 32.000" 176400
4.generate 150 empty mode 1 sectors for Track 02 and 32 (75+150=225=3"=our target gap):
GenEDCECC.exe "Track 02.ecc" 3440 150
GenEDCECC.exe "Track 32.ecc" 311960 150
(1st parameter is target file name, it'll be overwriten without warning, so be careful, please. 2nd parameter is DataTrack LBA-number of Mode 1 sectors in transition area (150 always so far). 3rd: number of Mode 1 sectors in transition area. and i assumed here, in this example, that you have the same LBAs as i did)
5.recombine data tracks:
copy /b "Track 02.000" + "Track 02.ecc" + "Track 02.bin" "Track 02.out"
copy /b "Track 32.000" + "Track 32.ecc" + "Track 32.bin" "Track 32.out"
6.you must modify .cue manually with target gaps, like 3;2;0... in this case.

7? would be great if you could error check data tracks @this point, i'd use a custom program for this but you can open this moded .cue with cdmage, there will be errors on those audio sectors at the beginning (75 for each track, usually), and sometimes there can be few errors at the very end of last data track (if ther's happen to be mode 0 sectors), i think, but other than that it should be ok. please don't fix it, just scan, ok? .

8? finally to be sure that everything's reassembles correct, it would be great to dump a .cue with IsoBuster from original CD and compare it with .cue you'd get with IsoBuster from virtual drive where those tracks are mounted (Alcohol or such). it's because IsoBuster has LBAs in .cues so those two must byte match (fc /b original.cue redump.cue) or have the same crc. (although it does not contain LBA of leadout or total CD size so it's still possible to mess up last track and not notice it, but this should not happen as long, as you remember not to slice those 150 sectors off from the end of it )

EAC will usually return same gaps on all drives, if they all use method A, so you can verify audio tracks from EAC gui and only need to do realigning once. btw it's important to do reading on different drives, i had a CD that would not return any errors but two output audio tracks was always different by few bytes on each of 3 drives (Burst mode/Paranoid/C2&cache on/off.. it didn't matter - always the same crc on the same drive but different among them), so i didn't submit it, but on one drive it's impossible to tell.

so i think this pretty much sums it all up.
this way you should have all meaningful data that there was on a cd dumped to images; audio offset is realigned to 0; TOC stays true to original; transition areas are reconstructed, as they were in original; subchannel will be recreated when burned/mounted - it's the only thing that can differ a bit, well because of those gaps.. about as perfect as it gets.
would EAC create .cue files for PCE CDs and use different algorithms for gaps (at least on those ADDRESS=2 subcode sections) it'd be much easer then, and not much different from dumping as it's in the guide, so i really just hope these problems will be fixed soon.

i'll try to write that resume next week, on some stats and exceptions that was there so far, but they are very rare..

Another thing that has to be note, if you dump PCE disc data tracks has to be resized at the end only by 348096 bytes, not 352800! Taking out 2 full seconds you'll cut 2 sectors of data! And when dumping with PerfectRip you have to add only 348096 bytes of 00 silence at the beginning of the following audio track, otherwise you'll have a bigger file than the actual one. It's not always 348096, depends on the shifting.

Themabus can you confirm?