Search options (Page 8 of 16)

are you sure it's 5 minutes?
i have whole PCE set on ImageDiff - it's always a matter of seconds on my machine
those are small ImageDiffs, however - rarely larger than 10 megabytes

md5 on 600mb file (fsum.exe) completes in ~20 seconds

if ImagePatch is slow it's implementation fault then, as in theory, it should be faster than unecm
ecm has a map of sectors where to recreate ecc
all program like ImagePatch needs, imho, is map of sectors to insert and those sectors themselves
it's practically 'copy /b file1+file2 file3'

as you said yourself FreeArc use symmetric compression algorithm which 7z does not
i don't think it's ultrafast - it can never be faster than 7z
it can compress better or be more convinient
but same files should extract faster from 7z

yes i'm theorizing
i'm out of space now and basically can not check anything so i have to trust you

so time results you provided earlier

what are they from?

i mean if it's single file (or two) extracted from 7z containing one .ecm and ImageDiffs,
whole archive should decompress only little slower as it is solid most likely

so what we have is .ecm and .ImageDiffs in 2 minutes
vs one ecm (or several) in 7 minutes

now if ImagePatch is bottleneck here it should be possible to replace it with less complex patcher and it should zap

or i don't understand something?

ok, maybe you think author will implement ecm and joining of files in FreeArc and everything will be done in RAM (5gb)
and then written to HDD so time on HDD access will be saved
but it's overkill imho - 5gb of RAM is not sane and probably same could be done then with ramdisk

i mean it's all good to have all those features in one program but decompression algorithm itself is way slower
so that's where it ends, imho

edit:
i don't mean that 7z is ultimate archiver btw.
if ther's one faster at same or better ratio (like TAK vs APE & FLAC) - by all means
i just don't think that FreeArc is the case unfortunately

is this FreeArc?

ok, so i guess, it's how fast single version from 378mb FreeArc would extract
could you test extraction of .ecm + one .imageDiff from 357mb .7z and 344mb .nz, please then
unecm would be the same, and ImagePatch would be slightly slower than joining, i guess

edit:
noooo, wait
ummm it says 7z

that's what i thought:
1st: FreeArc - prettyslow
2nd: 7z + ImageDiff - fast

i mean when you have files decoded from ImageDiff .7z you'd still beat FA by about 4-5 minutes
plus compression is better

oh, i see - if you'd extract single file from archive
for ImageDiff you'd need to run it through ECM and ImageDiff
but for FreeArc only ECM (and then join files)
but still decompression should be notably longer for FreeArc since it's 5.5gb vs 700mb
so what's lost on ImageDiff should be regained on decompression

rar would compress audio better, so it makes sense if all tracks go to single archive.

i honestly don't think that ability of torrentzip to produce identical archives is either something to worry about.
how many people use that really? 20 maybe, maybe less.
PackIso isn't bad, but surely if better compression ratio/speed combination can be found, why not?
(for instance: replacing ape with tak would improve it a lot)
it's really what matters - fast download/decompression, not ability to join in and seed - pretty much useless, imho.
what really happens is: somebody uploads a file and rest of the people fetch it and seed, that's all.
nobody cares about torrentzip.
so would somebody recompress everything - it wouldn't be a big deal, imho.

dunno, to me ImageDiff results look most appealing
it would depend on decompression speed difference, which one of two i'd consider the best

splitting in parts adds another layer the same as ImageDiff and both speed and compression is worse
otherwise it's just too slow, imho.

when i said years i mean single game from such merged 7z+ecm+flac (or tak)+ImageDiff set
should decompress in about 2-3 minutes or so
it's most frequent scenario, nobody really needs whole set decompressed at once,
and still ImageDiff would be faster than 10 minutes, i guess.
so, very roughly:
let it be 20 minutes overhead on game
let it be 100 such games (or decompressions user commits)
and they're shared by 1000 people
100/3 = 33 hours = 1.4 days
1.4 * 1000 = years
sure they would download faster, but download is done passively in background
when in contrast decompression takes full PC load and needs interaction from user

it (NanoZip) would decompress slower than 7z, though
right?

i wrote summary in 1st post
http://forum.redump.org/post/10732/#p10732

maybe somebody feels like experimenting with 90 or 99 min CDs?
in a way, depending on which characteristics are evaluated,
they would replicate protection ring with less distortions than 74 or 80 min ones
e.g. 74min CD would gain ~52645 channel bits per 1460 revolutions, while 99min only ~39884 (25% less)
though i don't think Saturn would read 99 at all, maybe 90

i haven't tried any of those myself since there aren't such RWs

there appears to be another value: '*EGAVIEWER' for Photo CDs
though maybe just syntax is alike

edit:
identifier '*EGASYSTEM' is also present in DC System Disc replacing CRC16 & Device Information

edit:
boot process roughly:
- check for 1st instance of '*EGA *EGASATURN ' identifier at user data offset 0 in first 15 sectors
- if present check ring
- if pass carry on with Security Code, Area Code verification
...

minimum to disable further ring checks (like SD does) appears to be pass on 1st two checks
and additionaly properly filled Maker ID & Product Number fields
all the rest can be blank dat - 0x00

also i've tried to replace identifiers with various strings that would yield same CRCs for most common models
and few other things and they wouldn't pass so i'd guess they're actually byte compared for exact match

on system discs KD01 & KD02

so what matters is valid System ID record in System Area and particularly -
special identifier in it's Product Number field: *EGASYSTEM
everything else - does not.
it can be any track layout, any content - as long as it's valid for Saturn it will function.

Product Number field is where serial usually goes,
so it's possible to change it with hex editor to value mentioned above for any Saturn CD
and it will disable repeated ring checks after 1st validation - just like system disc does - even after reboot.

difference between KD01 and KD02 lies in Maker ID field
it's '*EGA ENTERPRISES' in 1st case - 1st party and '*EGA TP' in 2nd - 3rd party
this is not different from all normal CDs and this value is kept somewhere in memory after 1st validation,
so would you make system disc out of CD with serial T-????? (3rd party) it would function as KD02
system disc made from GS-????? CDs (1st party) would work like KD01
(except that game will still boot - actual system disc does nothing after execution of AIP - cease to function)
there appears to be no further distinction between manufacturers based on company code for 3rd party CDs
so one should work for all.

after System ID record ther's Security Code. it's like always and also Area Code group is unmodified.

and then ther's Application Initial Program for about 2 sectors, i'm not sure what it does
well it displays message on screen and appears to modify fonts, i think, but that's all i could figure
maybe it sets up some additional functions for system disc,
but it appears to play no role in boot process modification whatsoever.

so this special value for Product Number field is interesting.
maybe ther's others? maybe ther's one, that would bypass ring completely?
i'd guess it isn't stored directly for comparation but rather something like checksum would be used.
(as an example: Dreamcast has CRC16 calculated on Product Number+Version stored as an field of System ID)
so if one could figure where this validation takes place,
it should be possible then to determine whether there are any more such magic numbers.

* = S

it's great program, but unfortunately it doesn't look too compatible with redump.org
it looks like it only support single file per game and also languages & regions lack some values.
i haven't checked thoroughly though, maybe i'm wrong

ther's more to it:
when i ran into this, either Plextor or Lite-On were connected through onboard IDE controller, along with primary HDD.
i've changed IDE drives a few times and it would affects this issue to a certain degree,
so i was pretty certain it's something with controller.
now i have Plextor hooked via USB converter and it still stays.
what's more interesting: READ CD command returns modified sectors but READ BUFFER right afterwards does not.
so in Plextor's buffer data is correct but somewhere on the way out it gets crooked.