oh, ok
thank you very much

Is this the only one with positive offset? http://redump.org/disc/2320/

yes, 1st track's crc match with TJCD1018
so i think it should be ok

29 (edited by themabus 2008-01-12 14:42:40)

sometimes  EAC would get a strange gap layout again. all close to 0 except for those wraping data tracks. for example TJCD0007 Death Bringer:
Track|Gap
01    |02:00
02    |03:00 <=data
03    |02:00
04    |00:00
05    |00:02
06    |00:01
07    |00:02
08    |00:01
09    |00:00
10    |00:01
11    |00:01
12    |00:00
....
and so this is what's going on in subchannel:

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 
 10382 ffffffffffffffffffffffff         0          1   03      01    00    18      46     00     02     20       31    7ff2 
 10383 ffffffffffffffffffffffff         0          1   03      01    00    18      47     00     02     20       32    e5c0 
 10384 ffffffffffffffffffffffff         0          1   03      01    00    18      48     00     02     20       33    9018 
!10385!ffffffffffffffffffffffff        !0         !1  !03     !01   !00   !18     !49    !00    !02    !20      !34   !4aae 
 10386 ffffffffffffffffffffffff         0          1   04      01    00    00      00     00     02     20       35    45f6 
 10387 000000000000000000000000         0          1   04      01    00    00      01     00     02     20       36    dfc4 
 10388 000000000000000000000000         0          1   04      01    00    00      02     00     02     20       37    2137
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 
 15614 ffffffffffffffffffffffff         0          1   04      01    01    09      53     00     03     30       13    3e72 
 15615 ffffffffffffffffffffffff         0          1   04      01    01    09      54     00     03     30       14    2941 
 15616 ffffffffffffffffffffffff         0          1   05      01    00    00      00     00     03     30       15    bef4 
!15617!000000000000000000000000        !0         !1  !05     !01   !00   !00     !01    !00    !03    !30      !16   !24c6 
 15618 000000000000000000000000         0          1   05      01    00    00      02     00     03     30       17    da35
 15619 000000000000000000000000         0          1   05      01    00    00      03     00     03     30       18    818b 
 15620 000000000000000000000000         0          1   05      01    00    00      04     00     03     30       19    f67e
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 
 16374 ffffffffffffffffffffffff         0          1   05      01    00    10      08     00     03     40       23    f891 
 16375 ffffffffffffffffffffffff         0          1   05      01    00    10      09     00     03     40       24    2227 
 16376 ffffffffffffffffffffffff         0          1   06      01    00    00      00     00     03     40       25    adba 
!16377!000000000000000000000000        !0         !2  !00     !00   !00   !00     !00    !00    !00    !00      !26   !65d1 
 16378 000000000000000000000000         0          1   06      01    00    00      02     00     03     40       27    c97b 
 16379 000000000000000000000000         0          1   06      01    00    00      03     00     03     40       28    92c5 
 16380 000000000000000000000000         0          1   06      01    00    00      04     00     03     40       29    e530 
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 
 21794 ffffffffffffffffffffffff         0          1   06      01    01    12      18     00     04     52       43    6e89 
 21795 ffffffffffffffffffffffff         0          1   06      01    01    12      19     00     04     52       44    b43f 
 21796 ffffffffffffffffffffffff         0          1   07      01    00    00      00     00     04     52       45    cabe 
!21797!000000000000000000000000        !0         !1  !07     !01   !00   !00     !01    !00    !04    !52      !46   !508c 
 21798 000000000000000000000000         0          1   07      01    00    00      02     00     04     52       47    ae7f 
 21799 000000000000000000000000         0          1   07      01    00    00      03     00     04     52       48    f5c1 
 21800 000000000000000000000000         0          1   07      01    00    00      04     00     04     52       49    8234 
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 
 28496 ffffffffffffffffffffffff         0          1   07      01    01    29      25     00     06     21       70    714a 
 28497 ffffffffffffffffffffffff         0          1   07      01    01    29      26     00     06     21       71    8fb9 
 28498 ffffffffffffffffffffffff         0          1   07      01    01    29      27     00     06     21       72    158b 
!28499!ffffffffffffffffffffffff        !0         !1  !08     !01   !00   !00     !00    !00    !06    !21      !73   !3715 
 28500 000000000000000000000000         0          1   08      01    00    00      01     00     06     21       74    eda3 
 28501 000000000000000000000000         0          1   08      01    00    00      02     00     06     22       00    6831 
 28502 000000000000000000000000         0          1   08      01    00    00      03     00     06     22       01    d241 
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 
 30342 ffffffffffffffffffffffff         0          1   08      01    00    24      43     00     06     46       41    7faa 
 30343 ffffffffffffffffffffffff         0          1   08      01    00    24      44     00     06     46       42    281d 
 30344 ffffffffffffffffffffffff         0          1   08      01    00    24      45     00     06     46       43    926d 
!30345!ffffffffffffffffffffffff        !0         !1  !08     !01   !00   !24     !46    !00    !06    !46      !44   !0c58 
 30346 ffffffffffffffffffffffff         0          1   09      01    00    00      00     00     06     46       45    181e 
 30347 000000000000000000000000         0          1   09      01    00    00      01     00     06     46       46    822c 
 30348 000000000000000000000000         0          1   09      01    00    00      02     00     06     46       47    7cdf 
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 
 34836 ffffffffffffffffffffffff         0          1   09      01    00    59      65     00     07     46       35    5344 
 34837 ffffffffffffffffffffffff         0          1   09      01    00    59      66     00     07     46       36    8df5 
 34838 ffffffffffffffffffffffff         0          1   09      01    00    59      67     00     07     46       37    3785 
!34839!ffffffffffffffffffffffff        !0         !1  !10     !01   !00   !00     !00    !00    !07    !46      !38   !1136 
 34840 000000000000000000000000         0          1   10      01    00    00      01     00     07     46       39    ab46 
 34841 000000000000000000000000         0          1   10      01    00    00      02     00     07     46       40    aa2a 
 34842 000000000000000000000000         0          1   10      01    00    00      03     00     07     46       41    105a 
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 
 35484 ffffffffffffffffffffffff         0          1   10      01    00    08      45     00     07     55       08    4e38 
 35485 ffffffffffffffffffffffff         0          1   10      01    00    08      46     00     07     55       09    b0cb 
 35486 ffffffffffffffffffffffff         0          1   11      01    00    00      00     00     07     55       10    095f 
!35487!000000000000000000000000        !0         !2  !00     !00   !00   !00     !00    !00    !00    !00      !11   !2365 
 35488 000000000000000000000000         0          1   11      01    00    00      02     00     07     55       12    6d9e 
 35489 000000000000000000000000         0          1   11      01    00    00      03     00     07     55       13    d7ee 
 35490 000000000000000000000000         0          1   11      01    00    00      04     00     07     55       14    c0dd

! - denotes last frame of the previous track (from TOC)
so there are no gaps. INDEX is never 0; MSF never count back. only thing different is relation between subchannel track index and TOC. size of pause is presumed depending on this difference alone. Tracks 4, 9: hit on TOC - pause =0; Tracks 8,10 differ by 1 frame - pause =01; Tracks 5, 7 kick in with a 2 frame delay - pause =02; Tracks 6,11 should have been 02, applying this math, but ADRESS=2 type frame shifts them to 01.
so there is no reason for gaps, it's only a strange mastering of cd. i'll go instead for a cdrwin gap layout in such cases: audio2audio=00

*edit: i forgot about numbering difference. it's last frame marked not first*

also when in pause, Q-FRAME would usually go like this
74 73 72..03 02 01 [00] 74 73...
but in some cases ther's 2 F=00 frames
74 73 72..03 02 01 [00 00] 74 73
so EAC would for some reason excluded those additional 00 frames from math
and determine pause to be smaller than it is (TJCD9002 Super Albatross: T2:EAC=2.73/should be 3.00)
i'll post this on EAC forum, maybe they can fix it or explain algorithms, maybe there is a reason but unlikely

And what about Human Sports Festival 2.74 data tracks pregap? That a 99,99999% 3.00 pregap misjudged by EAC.

I'm really starting to think we must edit those strange MegaCD and PCE gaps by hand. Why would we have to keep clearly wrong info in the database? Whoever is going to dump discs has to post them here or as wip first anyway, so we can pre-check their new info before confirmation.

EAC guys seem nice, but I'm pessimist by nature and I think there's no real chance EAC errors will be corrected, since EAC gap detection algo has been the same for many years and I don't think they're going to change it now.

The console discs we dump here are funky exceptions to the rule, as you said it's a matter of strange mastering, and EAC was born primarily for plain old audio CDs, not to dump funky exceptions.

And your posts on EAC forums have gone unanswered for weeks now.

We could always wait for the perfectrip successor and hope it will work on all drives

Hopefully. Current PerfectRip can't dump PCE games at all.

The bad thing, as I said, is that all programs are built to read a certain variety of CD standards, but not all of them. PCE discs have such a peculiar standard that it would take a huge effort from programmers to adjust their programs to these strange layouts too. It's the kind of work not all programmers are willing to do: it takes much time and it doesn't bring recognition, because these games are niche.

EAC is too much into plain audio layout to care, maybe PerfectRip authors will, after all there were MegaCD games I could dump only with PerfectRip and not with EAC.

gigadeath wrote:

And what about Human Sports Festival 2.74 data tracks pregap? That a 99,99999% 3.00 pregap misjudged by EAC.

i think 2.74 is valid. it looks intentional. 3s gap would count form 74 to 0 x3 so 75x3=225 frames. these 2.74 start with one frame delay and count from 73 so 75x2+74=224. and on same cd next gap (2s) goes from 74 as usual. though, maybe i fail to notice something. i would dump image with CloneCD or Alcohol and open .sub with Subcode Alayzer, maybe you can figure something out. it would be nice if all PCE 1st tracks are same size and maybe crc match more often smile

PCE first tracks are doubtful too. They have 3366 sectors when they come before a 2.74 gap, and 3365 sectors when they come before a 3.00 gap. Aren't those first tracks all the same audio sample? They should be all either 3366->2.74 or 3365->3.00.

The way it is now is strange.

36 (edited by themabus 2008-01-12 19:55:36)

it's because we slice off pause and move it to the next track: larger pause=smaller first track. but full track size LBA to LBA (hence TOC as well) still stays true to original in both cases. but i guess you're right. maybe it was issue with hardware or software they used back then to master CDs. and so some CDs ended up with 2.74 pauses, some with 3.00, much like offsets on PSX.

Vigi wrote:

We could always wait for the perfectrip successor and hope it will work on all drives

but i thought you're one of the developers, aren't you?

themabus wrote:
Vigi wrote:

We could always wait for the perfectrip successor and hope it will work on all drives

but i thought you're one of the developers, aren't you?

lol no way, I was just the one handing out all the beta's..

oh, i see smile

but can you make a sugesstion, then? it's just that i thought about all of this and i guess there is no perfect way - machine would still make a wrong assumption at some circumstances, no matter how good algorithm is. so if they could make an interface to allow users to redefine gap layout in PerfectRip, this would solve a lot.

themabus wrote:

oh, i see smile

but can you make a sugesstion, then? it's just that i thought about all of this and i guess there is no perfect way - machine would still make a wrong assumption at some circumstances, no matter how good algorithm is. so if they could make an interface to allow users to redefine gap layout in PerfectRip, this would solve a lot.

the delphi version that we are using isn't actively worked on anymore.. I'll pass it on as a suggestion for the future version

ok, thank you very much!

one more thing:
when audio track changes into data we would fill the whole gap, with 00. on data->audio as i understand now we did this only for audio part, so ther's always around 150 empty data sectors at the end of the data track as well. but on PCE sometimes, maybe always, this layout is true for audio->data transition, only in reverse order, so first come blank audio sectors then empty data (but with header and edc/ecc), both parts about the same size. should not we keep those empty data sectors? to keep transition area structure valid. they are hard to read sometimes and each drive i have would treat them differently, but even if it is possible to determine size of each area, i gess they could be generated.

43 (edited by themabus 2008-01-15 22:25:35)

i've checked 12 CDs, and data part is always 150 frames. i guess it's no use to check it any further, the fate of this data is to get corrupted anyway but since CD specifications defines track type transition structure this way, we can generate 75 or 74 empty audio sectors (depending on gap) / 150 data. if you, guys, decide on this, i can resubmit CRCs for data tracks any time.

Actually I don't think I understand, it's beyond my comprehension skills big_smile

But I trust you, if there's something wrong please fix it smile

gigadeath wrote:

Actually I don't think I understand, it's beyond my comprehension skills big_smile

Looks like he's talking about postgap for audiotracks and additional pregaps for datatracks, if I understood this correctly...

46 (edited by themabus 2008-01-16 09:25:40)

yes smile
on PCE this is how tracks change among different modes

...DATA|150 ED|150 EA | AUDIO...
              |  GAP  | 
   Track n            | Track n+1


...AUDIO|75 EA|150 ED | DATA...
        |    GAP      | 
   Track n            | Track n+1

---------------------------------
ED..empty data sectors (header+00+edc/ecc)
EA..empry audio sectors (all 00)

it takes a time for a drive to react on type change, so 2nd part of transition area
would at least partly end up like garbage, it depends on drive how much
so we would all see different kind of junk in these parts and get different crcs
on data->audio: part of audio sectors would get scrambled, like data so we would
replace it with correct empty audio sectors, just all 00 like, it's all perfect what we do here
on audio->data: part of data sectors won't get scrambled, like they should
and we replace whole area with empty audio sectors but part of them were data

the truth is, emulators don't need it and i think burners can't burn it
they would fill gaps with track descriptor blocks or just redefine content freely
maybe there is software, maybe, but i don't know...
so anyway if we keep it, that data part, it would be more true to original
but harder to accomplish and like ...completely useless, i guess big_smile

ok, i resubmited everything +2 new cds but only crcs for data tracks should change
i'll keep checking every cd for that exact data sector number in gaps, not assuming 150 <- scrap that, let's do it perfect smile

themabus wrote:

ok, i resubmited everything +2 new cds but only crcs for data tracks should change
i'll keep checking every cd for that exact data sector number in gaps, not assuming 150 <- scrap that, let's do it perfect smile

woops.. now the db is a mess sad I wish you just could have edited the old entries.. Dremora should definately give you moderator rights and perhaps remove -v- and cHr from this status because they're never around (anymore)

oh that would be great, even if for a short time while i get my pce cds done

themabus wrote:

oh that would be great, even if for a short time while i get my pce cds done

short time? heh.. you're one of the biggest contributors.. I think moderator status is the least we could give you

slightly offtopic: do you also have SNK Neogeo CD discs?

edit: Dremora gave you moderator and added delete function, but I already deleted the dupe PCE for you smile