Search options (Page 2 of 16)

hmm
could you please test raw output unscrambling (-u) performance, is there difference between 0.4/0.5 or win/nix?

np
that would be really great

good luck, flibitijibibo!

i've mailed it to that other Linux guy and that was the last time i've heard from him
and he was sole person within a year interested in this
so i didn't think anyone else would be

well, it's a mess
*nix part was neglected and, what is, is hackish
it probably won't even compile on those machines
so you'd have to compare 0.5.3 with 0.4.0 and update nix platform specific functions
http://www.mediafire.com/?3h11a0gxrjf0mx0

but two requests in a month it's like superpopular
i guess i better add link to main topic then

no, in current db structure matching CDs wouldn't be counted separately, even when from different releases

np, i'm glad if this is of any help

yes this could be done this way
thing with CloneCD is though that it outputs all tracks in single file
so you would have to join those EAC audio tracks togeather, remove same amount of data from CloneCD's .img
and then add that EAC data there
.cue and .ccd should be fine then as they are
you could mount this image on virtual drive then and test it with emulator to see if everything is right
with .ccd subchannel data from .sub file would be used, but not with .cue

good luck, ploder

if it's not LibCrypt protected CD, ImgBurn, BlindWrite and CDRWIN should work
it won't really be 1:1 (e.g. some audio samples might get lost or gaps modified)
but it's as close as you can get - it won't affect gameplay

yeah, it's fine
i've checked friidump and it's pretty impossible for it to pass bad sectors
EDC check is part of core decoding logic
it's likely to be HDD fault then
could it be IDE and on the same cable as CD unit?
to be certain in future you could make raw image with -r switch instead of -i
and afterwards decode this image twice, with -u parameter:
friidump.exe -u "input.raw" -i "output.iso"

it's quite useless for emulation, yes. but it's necessary to organize good db (i.e. preservation project).

gaps is one thing, another thing with TOSEC is that they do not cancel CD offset. this shifts all audio data in one direction or other relative to data tracks. some of audio data often enough is shifted out of dumped range - if it ends up in gap or lead-out - then it's cut off and lost.

so TOSEC dumps depend from offset of master (there often are several); single game made from masters with different offsets will have different entries, when actually it's same CD. instead of verifying one another, those entries create clones (also no relation among audio data from different regions, or consoles, since usually those would have different offsets too). and since audio data can be cut off, they can end up with several clones none of them covering whole audio data, so no matter how you shift this data afterwards, it won't fully match to that from another entry.

specifically for DC they do not cancel drive offset too, which they assumed was always the same for this console, but as it later turned out - it isn't - yielding more problems.

the devil is in the details.

i agree it's important information to have
db model Dremora was working on would link those records togeather, like vgrebirth or gamefaqs
that would have been great and is way to go imho
don't know what happened to it

but i think comments field as it is now is misused:
- actual comments and notes would go there
- links to related media would go there
- compilation content
- protection info
- layer break
- header dump

this makes bad db
all of those special entries should have fields of their own, imho, and don't belong in comments
it is good we have this info somewhere, but db should have been periodically updated, now it's a mess
i hope, if not Dremora, somebody else would finally rewrite db structure taking into account all of this
in that case imho it's better not to mass-add those names to comments now
it will be difficult to fetch out what's already in there as it is now

i could send you pascal part without assembler routines, if you want to
it should be possible to link it with CloneCD's ElbyECC.dll instead
but it's really rather simple:
- mode of each sector is determined
- each element (sync, address, subheader, etc.) compared with pregenerated
- those matching removed
so what's wrong with ECM, i think, since it has support of many formats: .cdi, nrg, mdf? - well at least some of those
it might be that on certain data layouts it would get confused and would try to analyze data too much
possibly trying to determine whether given sector belongs to any of those
anyway, that's only thing that comes to my mind without looking at code,
since basis is just a simple comparison and there are no faster/slower sectors per se
except for ECC part but that hardly influence anything
and PSX would actually have less of those than regular CDs