Search options (Page 14 of 16)

i don't know about psp but, if these are cd tracks (for psx or such), extracted, like described in guide, buy 'copy /b' they basically should reassemble .bin/.img with only difference that audio is realigned to 0 offset and gaps reconstructed. it's like pure thing should work.

from old guide:

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.

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.

but, Snake, it's not just that. be it even 1 byte - you'll get different crc. and besides all cds have already an factory offset, sum that with drive offset, multiply with 4 and you will get the amount of bytes you'll miss. and the thing with Sega cds is that this factory offset can be huge so it's rather an exception if you get to align audio right and can get crcs to mach on some drives - but for this to happen on many drives it would have to be like a ...miracle
here, i did some more math:
name|offset(bytes)|silence(b)|difference(b) -you'll miss that on 0 offset drive
nostalgia|7800|1864|~6k
sangokushi 3|3880|1344|~2.5k
jangou w c|19|lucky
cosmic fantasy|7208|676|a lot
gambler j.|1823*4|1760|4x
...i just walked up directories sorted by serial skipping winning post... only 1 cd from 5 has little offset and a lot of silence, but if you don't belive you can teset by yourself - make the images with cdrwin and see if last byte in image is still data, it will often be.

wow, thank you very much!

i only have Japanese KOF96 for NeoGeo.

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

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

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.

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.

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.