wow, thank you very much! smile

i only have Japanese KOF96 for NeoGeo.

[00:32] <Tolvatar> too bad, pce games has data in subchannels
[00:32] <Tolvatar> this dumps are not correct
[00:32] <Tolvatar> i think
[00:33] <Tolvatar> on super cd-rom games, the second track and the last one are similar, only a few bytes differ
[00:33] <Tolvatar> this bytes can be found on subchannels
[00:33] <Tolvatar> and manually change the gaps seems awful
[00:34] <Tolvatar> thanks anyway for the link

any thoughts on this?

53 (edited by themabus 2008-01-26 06:45:31)

Vigi wrote:

[00:32] <Tolvatar> too bad, pce games has data in subchannels
[00:32] <Tolvatar> this dumps are not correct
[00:32] <Tolvatar> i think
[00:33] <Tolvatar> on super cd-rom games, the second track and the last one are similar, only a few bytes differ
[00:33] <Tolvatar> this bytes can be found on subchannels
[00:33] <Tolvatar> and manually change the gaps seems awful
[00:34] <Tolvatar> thanks anyway for the link

any thoughts on this?

i wish it would be true smile ...since there was no lc on jpn psx and all, it would be something. i actually dump subchannel twice but so far besides Q-ADDRESS=2 and messed up layout i haven't noticed anything unusual. i guess that would mean non zero RSTUVW channels. in that case it should be easy to scan throug. i'll write a program and give it a try.
about 1st and last track it's true they are very alike but since we read in raw and last track hasn't got those empty secotrs at the end it would not show in db, only sizes are close.
gaps - well, what can we do? EAC does not pick them up. and since those last 4 or 5 cds i've added yesterday i'm actually now 99% sure this is the right thing to do. along with everything i posted before ther's one more case when EAC would fail - it's when absolute time frame at the end of gap repeats twice - EAC would decrease it by a frame. and about those 02:74 gaps when Audio changes into Data - ther's always  75 empty audio sectors and 150 empty data (75 empty audio and something, some bytes to fill last sector with audio data). only difference with 3:00 second cds is that 1st empy audio sector is not set as a gap in subchannel. so it's like those cds were prepared for standart 3 second transition area but somewhere late in process it just didn't happen smile . only cds with ring imprint * R1? V have this, so i think it was a bug. this pretty much rules every oddity out i have seen so far to 3s audio-data; 2s data-audio; 0s audio-audio. with sole exception where audio-data gaps were 2s, but that's ok, i guess. so if i wasn't sure about this before, because 2:74 gaps seemed perfectly valid, now i think it's better to just go with 3:00.

themabus wrote:

i wish it would be true smile ...since there was no lc on jpn psx and all, it would be something. i actually dump subchannel twice but so far besides Q-ADDRESS=2 and messed up layout i haven't noticed anything unusual. i guess that would mean non zero RSTUVW channels. in that case it should be easy to scan throug. i'll write a program and give it a try.
about 1st and last track it's true they are very alike but since we read in raw and last track hasn't got those empty secotrs at the end it would not show in db, only sizes are close.
gaps - well, what can we do? EAC does not pick them up. and since those last 4 or 5 cds i've added yesterday i'm actually now 99% sure this is the right thing to do. along with everything i posted before ther's one more case when EAC would fail - it's when absolute time frame at the end of gap repeats twice - EAC would decrease it by a frame. and about those 02:74 gaps when Audio changes into Data - ther's always  75 empty audio sectors and 150 empty data (75 empty audio and something, some bytes to fill last sector with audio data). only difference with 3:00 second cds is that 1st empy audio sector is not set as a gap in subchannel. so it's like those cds were prepared for standart 3 second transition area but somewhere late in process it just didn't happen smile . only cds with ring imprint * R1? V have this, so i think it was a bug. this pretty much rules every oddity out i have seen so far to 3s audio-data; 2s data-audio; 0s audio-audio. with sole exception where audio-data gaps were 2s, but that's ok, i guess. so if i wasn't sure about this before, because 2:74 gaps seemed perfectly valid, now i think it's better to just go with 3:00.

I'm sure you will do what's right.. anyway, maybe existing rip tools like turborip can also be used to rip the subchannels, but they will have to be cleaned so there will be no random errors. I'm looking forward to seeing what kind of scan tool you will come up with.

55 (edited by themabus 2008-01-26 15:11:29)

no, no, i would not be able to do something to something like that smile, i meant something rather trivial just to get user data from raw tracks and scan existing .sub and such. from those CDs checked so far about half are SUPER CD ROM, if it is like he said, i think some pattern must manifest even on inperfect .subs, so ok well i'll let you know if anything comes up.

56 (edited by themabus 2008-01-28 08:15:48)

i've checked 8 games so far with this track structure (not all were super cd rom),  but none appears to have anything unusual. ther's always some bits set in R-W channels, but it's rather random, those must be errors i guess. then i dumped that neo-geo cd, i think you said they would have a moded subchannel, and clonecd would give a lot of warnings about INDEX change on data track, and it tagged .cue and .ccd accordingly and in .sub INDEX does change the same way. and then i remembered ccd would warn in a similar way when reading pce cds. but it turned out to be just a gaps, nothing more. it would warn of INDEX 0 of every gap when track type change. so i don't know, i'll keep checking .sub when i see 1st/last tracks are alike but so far nothing special.
-----------------------------------------------------
turborip doesn't seem to rip subchannel at all, i guess it would use it to detect gaps only. it gets audio with riff headers, and data in cooked mode by default, but can do raw reading. cuts out gaps. audio gets messed up with offsets. it doesn't do anything special with data tracks.
-----------------------------------------------------
in 7 cases from 8, 1st track=last(byte identical, comparing user data only)+00 @theend. this is about where transition area starts. and since gaps are marked in subchannel, i think it's what he intended to say. if he was using turborip, it's how it may appear, since gaps are cut and in program documentation it says that drive must read subchannel, but i'll still keep checking for a while, it's still interesting smile even though i don't hope to find anything unusual anymore.