Search options (Page 1 of 16)

hi nocash

this byte defines format of following bytes
specifications of sbi format are given in 'PSEmu Pro CDR plugin interface'

yes, it's a pity
for exact data can not be reproduced from .sbi files
though it's enought to fool protection algorithm
as console does not return erroneous subchannel data, in such cases it returns previous frame instead
so .sbi basically just stores information where error occured and that's enough to bypass LC

LC1 and LC2 are LibCrypt patterns from a viewpoint of data not code
i.e. if you'll look for documents on LibCrypt, they'll reference changes that took place in code
and variations noted in those guides will not correspond to LCx generations in this DB

as i remember it this program was updated long ago for a last time
and could be it does not identify every LC pattern as such
might be some would just be reported as odd sectors
also not everything reported as odd means it's LC

generally LC always has those pairs
and backup copy of pattern further on CD, if data track is large enough
this backup though seems to never get actually used by algorithm
...many strange things with LC, it's as if it was rushed

i think such matters shouldn't affect naming in database itself
it's a concern of end user what he does with his images
naming shouldnt become cryptic for many to simplify storage for some
though database could output more information to .dat (xml),
that could be parsed afterwards, allowing implementations of various 3rd party tools
currently pretty much only names go there, while most is left on web server
so this data, it's very fragile and difficult to access, which is wrong, imho

though something very similar was already done in pakkiso - only generic track names - without serials

thanks Nexy

this is wip db structure way back from 2009
http://pics.dremora.com/redump-NGS.png
titles are seperated to a table, so no limit of 2; sub info is broken apart to release table, so no need to specify it in brackets; info on languages is more detailed
we were discussing db issues at that time, though since then more problems surfaced

i haven't messed with Starforce, it's just from observations - it spins up medium and then does some seeks, apparently clocking timing between sectors
on some specific sites or forums .mds files, that people made with DPM on can be downloaded and then they can be used with .iso images, so it's all in there, in this meta data
Starforce is quite popular here, i'd say about every 6th or so game has it, so this could be used to advantage when doing debugging, comparing information from multiple .exes
sometimes there would even be DVD and CD release of same game, both protected with Starforce, so such cases could be of particular interest

"It's time to REQUIRE sub code dumps of all CD's with CDDA/Audio tracks."
[...]
"Please contact either me or F1reb4ll for the tool we will be using for this purpose."

is this mature to you? i had this kind of maturity up to my neck, this is the reason why i left IRC and don't generally talk here anymore.

"Well come up with a better solution and suggest it"

thank you, i thought you'll never ask.

in my opinion, when you have a certain set and a subset of this set contains some oddities,
a value of those oddities should then be determined and neccessary course of actions defined based on this value.
it's not that different from what you generaly propose, i do however object on form and don't agree with value.
you probably know that this project started from PSX database and grew around it
i believe that implementation of how PSX is handled is close to optimal one, it was thought out well,
it's further down the road, where it went astray.
with PSX: those CDs with LC protection are treated slightly different - oddities are examined and defined in db (ASCII field),
from where they can be retrieved and processed/analyzed further.
(i do not like .sbi output, it can't hold all database values, but it's not really that relevant,
other output format was made - .lsd, i think, which addressed this issue,
so it could as well be .sub or different format, if needed)
this is what a good database is.
binary data is a lazy way to do things, if your motivation is to examine and preserve some sort of information -
it's just conservation you'd be doing, missing documentation part.
thus i do not agree on generaly expanding image format to .img/.sub/.ccd,  .mdf/.mds, 2448 sectors + TOC or any other.
this data should be analyzed and stored in db in readable format.
(the same with other things, i.e. medium topology based protections - timings should be analyzed and stored in table
.mds (or other neccessary format) then could be generated from this data as an output
with SafeDisc and similar protections that already are in db, this information would be much more useful
if actual sectors affected would be listed in records - this data could be examined then and worked with,
without a neccessity to have actual matching images
etc.)
so, yes, thing like this should be discussed and well thought out, it's not a matter to rush
i do not agree on "all CD's with CDDA/Audio tracks"
let me give you an analogy with PSX again:
some PSX CDs have gaps larger that 3 seconds, it makes them partially unreadable on drives i tested with:
Plextor, Lite-On (most popular ones at that time)
might be that some drives read them well though, i however did swapping for those.
is this the reason to read all PSX CDs with multiple tracks with swapping or with specific drives/methods?
no. why would it be? it's only a small fraction of CDs affected.
you are wildly exaggerating there.
IMHO only those specific discs should be treated differently, if value of gained data is sufficient.
with case of gaps, i do not believe it is, as this information is of little significance
and implementation of said process to gather this data
would complicate image making process far too much (see my previous post)
possibly bringing it to stall

IMHO this would just complicate process to an extent where it would pose more problems than solve
as it IMHO is with those systems mentioned

problem being addressed here is a doubtful interpretation of gaps
but the thing is that cue sheet defines only start and end frames of gaps, while in subcode gaps are referenced in channel P and channel Q with possibly independent fields and other oddities you mention
and so proposed solution is different interpretation of said gaps with subsequent translation to same limited format
(and there are oddities that can only be guessed - data can be such, that there won't be 'correct' answer
when image format comes with full subcode, burden of this interpretation
is then placed on end application that will use this image
it's still always an interpretation though - not caring about channel P is an interpretation,
AFAIK some hardware solutions read P exclusively and don't bother with Q,
maybe some consoles in some reading modes do too
for example PSX won't position precisely on audio tracks it can shoot off by full sector if i remember correctly
and if Q-CRC does not pass it would just return Q from last valid frame
but because we are locked in this limited format that requires gap definition, we have to carry it out ourselves -
make a decision whether frame belongs to gap or not)
process for said solution requires rather time consuming reading on specific drives
(which does not guarantee resulting subcode to be precise, as there are no control information for it;
only processing of different discs on different drives would give this certainty (to an extent, as different drives can still share similar chipsets (see Plextor Mode2 firmware bug for an example) and so on))
this translation to cuesheet might then require manual analysis of aquired subcode data
after it's done, one might need to scramble sectors and carry them from one track to another
and when this is done, actual result is this carrying sector from file to file - no, data gained, only carried from file to file
it's just so meaningless, it's ultimately useless to address it this way IMHO

ice.exe was made to automate additional steps in DC dumping (unscrambling/track separation)
AFAIR error indication in brackets is based on EDC/ECC check per sector (it determines sector nature: data or audio) and was intendet for gap managment
so there might indeed be cases when indicated number is different from 75 for good image or is 75 for bad image
75 only means that gaps are of common configuration
ice.exe was not meant for image validation
validation is performed by obtaining two matching images, preferably on different drives

hi, jamjam

i tried DCdumper.exe 0.2a but it would just crash on my PC (XP SP3)

usually programs would use SCSI Pass Through Interface (SPTI) to communicate with drive
(SCSI_PASS_THROUGH_DIRECT / SCSI_PASS_THROUGH_DIRECT_WITH_BUFFER)
it has least problems
and you can get handle with CreateFile, so only letter is needed - it shouldn't matter if its USB or ATA or SATA
there are good examples in Kris Kaspersky's book
http://forum.mobilism.org/viewtopic.php … ;view=next
(look for RAW reading through SPTI
there should be precompiled examples and .c files that came on CD with the book somewhere on web too,
but if you can't find those PM me and i'll send them to you)
and on Truman's homepage
http://www.cdtool.pwp.blueyonder.co.uk/workshop.htm

good luck

ah, i missed this too

how to make ring green?
it looks like i have a matching WOW expansion, even IFPI's are the same
which is pretty strange IMHO
but i don't see an option to set color
do i add it 2nd time exactly the same and it will group and become green?

PCE had a primitive way of stream interleaving, by mixing data/audio tracks
so it was important for this console to preserve actual data alignment
however, it is fully done with raw images
you don't need additional steps for this

this TOC, you refer to, is not more than a cue-sheet
about a decade ago there were those .iso/.mp3 dumps
and .mp3, when converted to .wav, could have different size, than the original
so you could sometimes spot those (.bin or .img originated from .iso/.mp3, not real CD) this way, that's about it
(i.e. compare .cue from raw image to .cue from image in question)

no, it's name, that should have been changed
it's pretty messy like that
this Reed–Solomon unit is there for Lite-On, since those drives erase two bytes from each raw sector
this data has to be regenerated
they would not work at all, would there be something wrong

i made that unit atop of Morelos-Zaragoza & Thirumoorthy code
(3. 'Reed-Solomon errors-and-erasures decoder' @The Error Correcting Codes (ECC) Page)

i don't know, maybe i'll clean it up someday
not anytime soon though,  i'm pretty done with this for now

edit:
ah, right, you mean, it shifts all data out now?
probably can just remove this bracket then

yes,  type is determined with disc_detect_type by simply requesting some sectors ahead of standard GC disc size
and then, if it pass, ahead of Wii size
i guess maybe your drive just doesn't return expected sense code
there was other method left in source, relying on content of DVD, but it was not used for some reason
so i left it alone

maybe you could check what sense your drive returns
on Windows IsoBuster could do this but i don't know about Linux tools

edit:
oh, right, i guess you could just compile it to print sense it returns

edit:
i've rechecked 0.5.3 (that precompiled version from year back) on my Lite-On with DVD+R and DVD+R DL
and it gets first one as Wii and 2nd as Wii_DL
so, i would say, on Windows generally it's fine