Redump Forum — would you consider adding an PC Engine CD, please?

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Sat, 26 Jan 2008 20:56:02 +0000

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 even though i don't hope to find anything unusual anymore.

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Sat, 26 Jan 2008 14:00:47 +0000

no, no, i would not be able to do something to something like that , 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.

Re: would you consider adding an PC Engine CD, please?

null@example.com (Jackal) — Sat, 26 Jan 2008 11:30:30 +0000

themabus wrote:

i wish it would be true ...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 . 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.

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Sat, 26 Jan 2008 05:43:02 +0000

Vigi wrote:

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

i wish it would be true ...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 . 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.

Re: would you consider adding an PC Engine CD, please?

null@example.com (Jackal) — Sat, 26 Jan 2008 00:16:10 +0000

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

any thoughts on this?

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Sun, 20 Jan 2008 06:54:19 +0000

wow, thank you very much!

i only have Japanese KOF96 for NeoGeo.

Re: would you consider adding an PC Engine CD, please?

null@example.com (Jackal) — Sat, 19 Jan 2008 12:47:44 +0000

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

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Sat, 19 Jan 2008 12:22:18 +0000

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

Re: would you consider adding an PC Engine CD, please?

null@example.com (Jackal) — Sat, 19 Jan 2008 11:54:14 +0000

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)

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Fri, 18 Jan 2008 23:39:24 +0000

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

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Wed, 16 Jan 2008 08:12:32 +0000

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

Re: would you consider adding an PC Engine CD, please?

null@example.com (F1ReB4LL) — Tue, 15 Jan 2008 23:31:00 +0000

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...

Re: would you consider adding an PC Engine CD, please?

null@example.com (gigadeath) — Tue, 15 Jan 2008 21:36:58 +0000

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

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Tue, 15 Jan 2008 17:21:41 +0000

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.

Re: would you consider adding an PC Engine CD, please?

null@example.com (themabus) — Mon, 14 Jan 2008 11:09:12 +0000

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.