oh, ok
thank you very much
Is this the only one with positive offset? http://redump.org/disc/2320/
- themabus
- Dumper
- Offline
yes, 1st track's crc match with TJCD1018
so i think it should be ok
29 2008-01-12 07:08:16 (edited by themabus 2008-01-12 14:42:40)
- themabus
- Dumper
- Offline
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*
- themabus
- Dumper
- Offline
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.
- themabus
- Dumper
- Offline
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 
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 2008-01-12 19:47:09 (edited by themabus 2008-01-12 19:55:36)
- themabus
- Dumper
- Offline
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.
- themabus
- Dumper
- Offline
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?
no way, I was just the one handing out all the beta's..
- themabus
- Dumper
- Offline
oh, i see
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
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
- themabus
- Dumper
- Offline
ok, thank you very much!
- themabus
- Dumper
- Offline
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 2008-01-15 18:21:41 (edited by themabus 2008-01-15 22:25:35)
- themabus
- Dumper
- Offline
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 
But I trust you, if there's something wrong please fix it
gigadeath wrote:
Actually I don't think I understand, it's beyond my comprehension skills
Looks like he's talking about postgap for audiotracks and additional pregaps for datatracks, if I understood this correctly...
46 2008-01-16 09:12:32 (edited by themabus 2008-01-16 09:25:40)
- themabus
- Dumper
- Offline
yes
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
- themabus
- Dumper
- Offline
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
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
woops.. now the db is a mess 
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)
- themabus
- Dumper
- Offline
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