Can't you authenticate it first with 3k3y, then open isobuster?

Doesn't seem to, anyway the only guaranteed route is the mediatek chipset drive.

Could some one list a few models and Ill buy one.

I cant resuse it anyway it is using the default keys, its from a broken ps3 I got from my friend. Its never going back in a ps3 I destroyed the ps3 the otherday, in a bad frenzy of junk destruction. That along with surge protector 2 360's 2 ps2's and some other ups that was taking up far to much precious space smile

iR0b0t wrote:

tossEAC, can't you just use isobuster? since you connect your ps3 drive with your pc it should also work.

does it, wasn't sure, is their a special way, put the disc in isobuster after opening it or before.

I will dump them that way if I can sure, but I didn't know you could, I have a ps3 drive not a pc drive, will it still work, I also can't try it for 1hr as its dumping a game.

Please respond ASAP as I have begun dumping them.

The discs are...

Beyond Two Souls, Tekken Hybrid and Gran Turismo 6

I'm ***edited*** keys.

I (we) should dump the iso with MM.

And I can get the keys with 3k3y pcb + ps3 drive on my pc. ok.

I have also dumped a lot of these twice already with multiman and both dumps matched, then I just need to dump with 3k3y pcb and cancell so I can get the dkey, but I normall dump the full iso with 3k3y get the dkey, blank the bytes and then check it matches the MM dump or dumps if I had already dumped it twice with MM, and it has matched every time no bad dumps so far.


Anyway the question is, I have 3 discs which will not, under any circumstances dump with MM, the 3 discs are the only ones that I cant dump with MM ewery other disc does, its either my PS3 or the discs themselves being fairly new releases.

What I was thinking of doing was dumping it with 3k3y, getting the key, blanking the bytes to be redump compliant, then taking the checksums. As for verification, dumping with 3k3y blank the bytes and take the checksums again and see if they match.

But let me know if this cant be submitted, as it will take around 6 hrs to dump these discs using this method, and I dont want to be dissapointed if the dumps can't be submitted using this method.

131

(50 replies, posted in General discussion)

My PS3 method is slightly different, because the method above doesn't work for me:

Dumping the ISO using MultiMAN:
- In XMMB display mode, go to multiMAN > File Manager / mmOs.
- In the start menu, select 'Enable Direct Disc Access' (with the game disc inserted). The disc will eject then go back in.
- Switch back to XMMB display mode. In the multiMAN Game column, select 'Refresh'.
- Now go to the Video column. It should now show a BD/DVD entry, but for me it doesn't.
- Instead eject the disc from the multiMAN Game column, but leave it sticking out of the drive.
- Then go to multiMAN > File Manager / mmOs, you won't be able to select 'Enable Direct Disc Access'  again unless you restart multiMAN. So click restart in the start menu, and it will restart, in a few seconds you will be back in File Manager / mmOs, with your disc sticking out of the drive.
- In the start menu, select 'Enable Direct Disc Access' (again) (with the game disc half in/out) it will pause for a few seconds then swallow the disc.
- Switch back to XMMB display mode. In the multiMAN Game column, select 'Refresh'.
- Now go to the Video column. It should now show a BD/DVD entry
- Go to it, and select the 'Copy to ISO' option.

Hope that helps anyone who the original method doesn't seem to work for. This method works for me on my NTSC 60gb launch model with Emotion Engine, running 3.55 cfw and latest MM. If the original method doesn't work try this instead.

It works for me everytime if I follow my exact method to the letter.

132

(0 replies, posted in General discussion)

I know in the beginning when I started dumping I was new to the redump needs, in the way of data collecting, and I'd like to thank all who have helped me over the past few years.

But as far as the Dreamcast dumps that are in the database, I often feel like getting a loaded double barrell shotgun, putting it in my mouth and blowing my head off.

Why because I see blue not green, the likes of buggy heat, blue stinger, sega rally and quite a few others, should all be green not blue.

So does any one fancy sorting it out, or will I have to pull the trigger one day.

I bought about 100 dreamcast games all for £2 each (factory sealed) and I dumped most of them, I know I made a cock up of posting the information, but it really sickens me when I quite clearly explained that I had dumped several discs all with the same checksums, but somehow it never made its way into the database, its all in the history I have just checked.

Some discs I had say 5 copies of, and out of the 5 some had the same rings, but I still fully dumped in most cases two of them, whether it was two with different rings or two with the same rings, I still dumped more than one, and it still shows as blue.

Out of the 100 factory sealed discs I opened, I could have just opened one of each different one, but I was trying to do you all a favour.

1 was to verify the dumps
2 was to try to find some different versions.

But I really shouldn't have bothered, because just opening the games I opened, probably halved the resale value.

So if you would like my help, I can create a new post with all the data from the previous posts and we can try to sort this mess out, rather that than see dumps with blue status when it should definately be green.

The other thing this has brought to my attention is the biggest floor in the redump database.

Say I dump 5 discs all with identical data, and identical rings, I would expect it to show I have dumped it 5 times, mainly because how else am I to know if I have dumped all my discs or not.

The idea of redump is to dump every disc, but if the same person dumps the same disc with or without the same ring it should show that its been dumped by the same person more than once, it should also say in my dumps if I have dumped a disc more than once.

Its unlikely that this will ever happen but It should.

I often buy games that are cheep regardless if I have them or not, sometimes I buy cheep bundles and I am bound to end up with some dupes. And I still dump every disc I get often to check if the disc will dump or not, then I submit the info, often the ring may vary thats it.

But the way redump works seems to be short changing me, if you look at the amount of dumps I have made 1600+, that doesnt include dupes, with dupes it would probably be 1800+ I want to see that because it makes more sense.

I know Im ranting a bit, so I'll leave it their and wait to see the feedback if any.

Thanks both of you for the help. It extracted fine with saramis tool.

My Virtua Fighter 3tb v1.000 it matches the dumpcast dump. Good.

I also have another copy of this yet to be cleaned, its badly scratched but cleaning is sometimes difficult with really scratched discs, never the less I will atempt the clean and dump, with a bit of luck it may even be the v1.003 disc would be really nice if it was, and both came with the project berkley disc smile which will hopefully dump, but at the moment isn't playing ball, it has a teenie weenie scratch on it thats giving a read error.

thanks for your help, still puzzled why ice is spitting this back at my face, maybe something to do with

Combined offset (samples)      : -378

Sorry about that I guess you could be right maybe saramis tool can extract the dense.bin, my apologies smile

But I would like to extract it with ice.exe if poss, as thats the norm, and we need to view the ice log to see if their were any errors, which is quite important, I don't know if saramis tool reports errors if present when descrambling the dense.bin.

nice, but totally unrelated to dreamcast dumping, and more so dense.bin extraction, which is what this problem is about, and only this dump of this disc all other dreamcast discs are ripping happilly smile

Im trying to dump V Fighter 3tb (Jap) for the dreamcast.

When I try to extract the dense.bin, ice gives this error.

ice @20090609 / themabus@inbox.lv
---------------------------------
dense.bin
---------------------------------
Accessing                       : ok
Seeking 1st valid Mode1 sector  : ok
 LBA found                      : 44991
 @file offset                   : $00000348
 Scrambled                      : TRUE
Seeking LBA 45000               : ok
 Combined offset (samples)      : -378
Parsing IP.BIN                  : An unhandled exception occurred at $00410140 :
EConvertError : "$SEGA" is an invalid integer
  $00410140
  $00401DB3
  $0040562C

Anyone have a suggestion.

I have dumped this first section twice using DC Dumper and get matching results both time, no problem, even dumped the 1st section with CDRWin and got the same again. Looks like I need to leave this disc for now, and move on to a new one.

http://www.multiupload.nl/LKTU9NFV0Z
http://www.multiupload.nl/J5O2BNTD4P

Its not the source I don't think, but it is the programmes 0.4a & 0.42a

GoldenHawk CDRWin I am using is 4.0g

My full log, couldn't be attached, as I had already attached DCdumper, also would have liked to attach the trap disc but it was to big. Sorry smile

I only wrote this guide the other night, and oddly enough, someone requested that I write a guide for this exact thing.

I am always one step ahead, heeehe.

I hope it works for you, please post what you find, good or bad.

The most important step is when you slide your Original GDRom in, once the tray wont go any further be sure to press it in real hard to make it go that little bit further otherwise you will probably end up with scratches on your GDRoms, like me.

Dreamcast Dumping - My Best Way.

Well here is a guide on how I dump my Dreamcast Games.

This is the best way I have found, nearly all Trial & Error, with a little help from other users.

I will try to describe in this guide exactly how I dump Dreamcast with 99% perfect results.

Firstly the things you need.

1 A DVD-Drive compatible with the CDRWin method and jamjam's DCdumper (0.42a)

2 One or more blank discs to use as a Trap Disc.

3 A dreamcast game, hopefully it will be in perfect condition, if not see my next guide on how to clean discs smile.

4 A fairly decent PC, not to old, and it doesn't have to be state of the art, somewhere in between, new and old is fine.

Firstly the drive I use is always this drive: TSSTcorp DVD-ROM SH-D162C TS04.

I also have the TSSTcorp DVD-ROM SH-D162D but I find it hopeless for Dreamcast, its ok for XBOX though, so I stick to that with that.

The method I use is the eject-pin-hole method, not with the dvd drives lid off, and I find it works really well, but care is needed to avoid scratching the GDRom.

I use both CDRWin and DCdumper, as one. In other words I use DCdumper to do the actuall dump, and CDRWin just helps me to align the laser, this in turn helps DCdumper do its job much better.

I use a custom method with DCdumper, which basically splits the job into three sections, a START, MIDDLE and END.

The start and end are about the same sort of time scale, and the middle is about the same as the stat and end added together.

Thats the basic jist of the method I use, here's exactly how I do it in much more detail.

First you need to download the trap disc, and burn it using CloneCD. Here's my own Tip, Number 1, for the blank disc to use.

From what I have found the best disc I thought of using, and am currently using at this moment in time, is a Verbatim CD-RW 1-4x 80min.

Why I use CD-RW is because the Trap disc tends to get a bit battered as most of your efforts tend to steer towards looking after the GDRom, but you should try to look after both.

Always eject it as carefully as you can, I use a precision screwdriver which is perfect in size and length.

Their is a method, which you will best find out exactly how by doing it. But I push the pin eject in slowly and not to far, then while its in wait a few seconds, you'll feel things happening, as soon as the thing you have pressed in starts to feel a bit slack gently remove the pin, and then straight after the tray should eject. It takes a little getting used to, but I manage to get it to work, no problem every time.

Try not to scratch your Trap Disc aswell, the reason behind the CD-RW is obvious they are a bit better at not getting scratched, as they are meant to be burnt on afetr being used several times. They are also quite scratch resistent when it comes to wiping finger prints of.

Firstly open CDRWin, with your Trap Disc in your drive.

Then set it up like you would if you were using it to do the dump, only I always change the Start-End sector to 50000-549150, everything else I leave the same. And you don't need to worry about CDRWin being registered, as un-registered sets the read speed to 1x, which is what we want anyway, so no worries.

So with CDRWin open, use start stop on your drive.

Create a bat file, if your going to be dumping more than one or two.

______________________

My bat file is like this:

startstop.exe x 1

(x) is my drive letter
______________________

So once it says the drive has stopped spinning you need to carefully eject the trap disc, and insert the GDRom.

***IMPORTANT*** if you don't want the GDRom to get magically scratched on the edge do this.

Push the GDRom in the tray very carefully and gently, when its 99.9% in it wont seem to go any further, just press all parts of the tray hard, you might if your lucky here the magnet picking up the disc, but don't worry if you dont, as long as it has been pressed in really hard, nothing will happen to the GDRom, hopefully.

So now with the GDRom swapped, you are almost ready to begin to dump.

Go to CDRWin, and start the reading from 50000-549150, press start, and as it gets to 1% wait a few seconds longer then cancell the reading.

Now run a DCdumper batch file.
______________________

My bat file is like:

DCdumper.exe x -df -ft

(x) is my drive letter
______________________

I will try to post my log that contains the logs of quite a few dumps I made, if you look through it, it will explain what I might not be able to do so well.

You will either get something like this, which will be just fine.

..................:::::::::::::::: PASS 1 ::::::::::::::::..................
Reading section 1: 044990-055278 - read error.
Fake read. Retry - read error.
Fake read. Retry - Initial dump.
Reading section 2: 055279-065567 - Initial dump.
Reading section 3: 065568-075856 - Initial dump.

If you get something like this,

..................:::::::::::::::: PASS 1 ::::::::::::::::..................
Reading section 1: 044990-055278 - read error.
Fake read. Retry - read error.
Fake read. Retry - read error.
Fake read. Retry - read error.
Reading section 2: 055279-065567

Stop the programme after part of section 2 has read or it completely reads section 2, always remeber when you shut DCdumper by yourself it very often leaves a partial bin fie. You must always delete this file, before you re-run DCdumper.

So when you get DCDumper to start dumping, you must use this method for a perect dump.

We will split DCdumper's job into three parts. Basically what this means is PASS 1 we will stop at section 20, straight afetr section 19 does an initial dump. Like this,

DCdumper.exe DCdumper.exe x -df -ft 

Handle acquired.
Load disc: Done.
Sector map created.

..................:::::::::::::::: PASS 1 ::::::::::::::::..................
Reading section 1: 044990-055278 - Initial dump.
Reading section 2: 055279-065567 - Initial dump.
Reading section 3: 065568-075856 - Initial dump.
Reading section 4: 075857-086145 - Initial dump.
Reading section 5: 086146-096434 - Initial dump.
Reading section 6: 096435-106723 - Initial dump.
Reading section 7: 106724-117012 - Initial dump.
Reading section 8: 117013-127301 - Initial dump.
Reading section 9: 127302-137590 - Initial dump.
Reading section 10: 137591-147879 - Initial dump.
Reading section 11: 147880-158168 - Initial dump.
Reading section 12: 158169-168457 - Initial dump.
Reading section 13: 168458-178746 - Initial dump.
Reading section 14: 178747-189035 - Initial dump.
Reading section 15: 189036-199324 - Initial dump.
Reading section 16: 199325-209613 - Initial dump.
Reading section 17: 209614-219902 - Initial dump.
Reading section 18: 219903-230191 - Initial dump.
Reading section 19: 230192-240480 - Initial dump.
Reading section 20: 240481-250769

dont forget to stop as section 20 begins, then delete 240481-250769.bin

So CDRWin we use to kick start the drive, it avoids dumping with DCdumper and getting fake read errors all the time.

So once you stop it, you can re-run DCdumper, leave CDRwin alone for now. It should match the first 19 sections, perfectly first time. Then after the first 19 matches, leave it running up to section 38 - Initial dump. Stop it at section 39. And delete 435972-446260.bin.

Then with DCdumper still closed at section 39, go to CDRWin, and change the Start sector to 230192-549150 and begin reading, stop it at 2%. Leave CDRwin open all the time.

Then run DCdumper bat file again, and it should do this.

DCdumper.exe DCdumper.exe x -df -ft 

Handle acquired.
Load disc: Done.
Sector map created.

..................:::::::::::::::: PASS 1 ::::::::::::::::..................
Reading section 20: 240481-250769 - MATCH: 6e4207510b72d64f2fdaf3a6e240b78e
Reading section 21: 250770-261058 - MATCH: 571d2edda501a781e5aac9d0c0a103da
Reading section 22: 261059-271347 - MATCH: e524a36ca2c1a9a1882e246caafb0106
Reading section 23: 271348-281636 - MATCH: 6dd29591019be9b77a4ea482ea3a3a4f
Reading section 24: 281637-291925 - MATCH: d72947d92a61f98ebcd8180c44a36e1b
Reading section 25: 291926-302214 - MATCH: cecc5174d242dcf7316203b2c8889f30
Reading section 26: 302215-312503 - MATCH: f1b3d9da4e6cadc9115d78eae4166e50
Reading section 27: 312504-322792 - MATCH: eb3e1326d4caf53f7a1ad95ddcf29bb1
Reading section 28: 322793-333081 - MATCH: 3baebdb7c7efc7df3771473335d08f58
Reading section 29: 333082-343370 - MATCH: dcb0ce8e933f0a6aac6596edb52d231c
Reading section 30: 343371-353659 - MATCH: 498d10ef9a163a1133a507f782f26924
Reading section 31: 353660-363948 - MATCH: 2e8551952fc2fc87a4d3bf14df734ec1
Reading section 32: 363949-374237 - MATCH: a422a968d40389aa90ee3cb74e07feed
Reading section 33: 374238-384526 - MATCH: dbad324d95b0327d836a178b22ad8052
Reading section 34: 384527-394815 - MATCH: f5b2adfc989f017418e7600aa3175f71
Reading section 35: 394816-405104 - MATCH: 0dba290bea3e4e27ecccc241815d634d
Reading section 36: 405105-415393 - MATCH: 1136db01634d836d9c879c5e13c586d3
Reading section 37: 415394-425682 - MATCH: aa51c5c9a86c66931318fa513ff398d1
Reading section 38: 425683-435971 - MATCH: c117f43f7eccd3e8ac5699a17b78811f
Reading section 39: 435972-446260

We stop it again at the same point as last time. Section 38 read, stop it as it starts section 39, like the log above.

Then go to CDRWin and change the Start sector to 425683-549150 and begin reading all the way to 100%, dont cancell. I save my file as dense.bin, but you can call it something elese if you like.

When CDRwin reaches 100% it will create a dense.bin file keep that we may decide to use it, if DCdumper fails to read the third and final section, it does that occasionally.

So then run DCdumper the last time and you should get something like this,

DCdumper.exe DCdumper.exe x -df -ft 

Handle acquired.
Load disc: Done.
Sector map created.

..................:::::::::::::::: PASS 1 ::::::::::::::::..................
Reading section 39: 435972-446260 - Initial dump.
Reading section 40: 446261-456549 - Initial dump.
Reading section 41: 456550-466838 - Initial dump.
Reading section 42: 466839-477127 - Initial dump.
Reading section 43: 477128-487416 - Initial dump.
Reading section 44: 487417-497705 - Initial dump.
Reading section 45: 497706-507994 - Initial dump.
Reading section 46: 507995-518283 - Initial dump.
Reading section 47: 518284-528572 - Initial dump.
Reading section 48: 528573-538861 - Initial dump.
Reading section 49: 538862-549150 - Initial dump.

..................:::::::::::::::: PASS 2 ::::::::::::::::..................
Reading section 39: 435972-446260 - read error.
Fake read. Retry - MATCH: 899e250f800b16efe4ccf92a75576dfd
Reading section 40: 446261-456549 - MATCH: 0df42aad13808f33a33628f8ecbf2b46
Reading section 41: 456550-466838 - MATCH: 13f55fa3c55d65d79dad23b8b096c401
Reading section 42: 466839-477127 - MATCH: 164fd4a642644bd93d30694e0913e519
Reading section 43: 477128-487416 - MATCH: 73101657245c32c04385ad0af7cbdeaf
Reading section 44: 487417-497705 - MATCH: 288dd6170d1fc7313029b9022c972137
Reading section 45: 497706-507994 - MATCH: 060a35de550280bbe873ae5a604cd308
Reading section 46: 507995-518283 - MATCH: f94ba83664c3b7f8bccd54b95d87efd1
Reading section 47: 518284-528572 - MATCH: 1ed6f4c5c9b59b80856b0c5aa3187cc5
Reading section 48: 528573-538861 - MATCH: e77240fc9debbacea49e4d756194ff77
Reading section 49: 538862-549150 - MATCH: 1589948dd455d557747e49880a0b47ab
Creating dense.bin: Done. Pass this to ice.exe

Once the dense.bin has been created, you can extract it with ice.exe. It will also overwrite the CDRwin dense.bin, not a problem we didn't actuially need it. We only create it, to fake read the end of the GDRom, to help DCDumper. And if DCdumper failed you could use the CDRwin dense.bin, with the DCdumper files, especially if its only a verification.

If reading the third section, CDRWin gives a read error, then so will DCdumper, and you must reset the trap disc, and start with the end section again, then it should work.

Its a bit trial and error, but it works very well for me, this method, it takes a little longer than with CDRwin, but its less prone to errors.

Sorry if my guide is poorly written, but read it a few times and it should make sense.

Thanks, I'll check SWS, and see what pessing it is.

KOF yes dump them, you might find yours are different like I did with 94. I'll try to submit my neocd dumps tommorrow, I have three or four not in db. I may branch out with neocd and buy some more, as they clean up really easy.

Checked SWS - looks like its Revision D, from the D on the ring smile

Hopefully someone can answer these questions, I feel I need moderators advice on these particular questions.

Firstly I have dumped King of Fighters 94,95,96 NeoCD.

I got matches on everything, except for Track 1, KOF 94. The audio matches but track 1 does not.

I have cleaned the disc and still get the same, the cleaned disc is as good as new (no scratches and perfectly clean).

So thats stumped me a bit, the obvious answer is its a different version, maybe.

The other disc Im having trouble matching is Sega Saturn Worlwide Soccer 97. All tracks match except Track 03 (1st Audio track). The disc hadn't been cleaned and is as good as new, I have dumped with perfect rip, and eac and get the same results everytime.

I also tried ripping my mini audio cd, Shin Seiki Evangelion - 2nd Impression Mini Audio CD (Japan) ([SS] Shin Seiki Evangelion - 2nd Impression Bundle) thats strange, I get every track a miss match.

Another game thats bugging me is, Mighty Hits Special (PSX) every time I dump it I get the same results, even after I cleaned it. It has one error in CDMage which is fixable. I don't think the error should be their, maybe it has a tiny hole, like a pin prick in the disc, maybe thats why thats causing the error. I will have to look at the disc again, and see if it does have a little pin prick type scratch in it.

I think their are other cds I'm having issues with but these are the main ones I need help with.

Anyhelp will be gratefully appreciated. smile thanks n advance.

One final QQ: Anyone know if PSX/PS2 Datel Discs will ever be dumpable (Properly), any way of dumping them in RAW mode?

144

(7 replies, posted in News)

javidelarosa wrote:

In the end of this year 2012 i want to see 25000 dumps in redump O___O

Im 100% sure we will pass 25000 we only need 900 dumps.

http://i1199.photobucket.com/albums/aa480/tossEAC/ResidentEvil-CDGroupv031vsCDGroupv042.png

http://i1199.photobucket.com/albums/aa480/tossEAC/ResidentEvil4-CDGroupv031vsCDGroupv042.png

http://i1199.photobucket.com/albums/aa480/tossEAC/StarWars-RogueSquadronII-RogueLeader-CDGroupv031vsCDGroupv042.png

http://i1199.photobucket.com/albums/aa480/tossEAC/TigerWoodsPGATour2004-CDGroupv031vsCDGroupv042.png

Note: Tiger Woods PGA Tour 2004, tried to diff, but no diffs were created, and as I expected, my compression on the old set was identical in size, so nothing gained, nothing lost.

http://i1199.photobucket.com/albums/aa480/tossEAC/TalesofSymphonia-CDGroupv031vsCDGroupv042.png

http://i1199.photobucket.com/albums/aa480/tossEAC/StarFoxAdventures.png

http://i1199.photobucket.com/albums/aa480/tossEAC/MarioParty4.png

http://i1199.photobucket.com/albums/aa480/tossEAC/OVERALLSAVINGS.png

Also, zip should not be smaller than 7z, unless maybe zip deals with incompressible material better and the stuff being compressed is mostly incompressible (perhaps xbox padding).

I think your right, but since the Diffing stage, its actually beeter your way, before diffing was introduced your right zip handled the garbage better, in ngc and probably Wii we would have seen this.

Your new way is the best so far, for maximum savings. I am currently re doing all of those ngc to see how much is saved over a larger field.

Resident Evil - CDGroupv0.3.1 vs. CDGroupv0.4.2 - (built-in compression) vs. (my own custom compression)

---------------------------------------------------------------------

6 ngc raw isos = 8.15 GB

6 ngc pakkiso'd = 4.79 GB = 3.36 GB saved over raw iso

6 ngc raw CDGroupv0.3.1 = 4.85 GB = nothing saved over pakkiso

6 ngc compress'd CDGroupv0.3.1 = 3.59 GB = 1.26 GB saved over pakkiso

6 ngc compress'd (built-in compression) CDGroupv0.4.2 = 2.14 GB = 1.45 GB saved over custom compress'd CDGroupv0.3.1

6 ngc raw (uncompress'd) CDGroupv0.4.2 = 2.85 GB = 2.00 GB saved over raw CDGroupv0.3.1

6 ngc compress'd (my own custom compression) CDGroupv0.4.2 = 2.21 GB = nothing saved over built-in compression. You win jamjam. The fact I saved a bit more on TimeSplitters was, it wasn't a good example. I prefer the compression you are using, even if its not the samllest size every single time (bad examples included), it still wins it for me smile

---------------------------------------------------------------------

Biohazard (Japan) (Disc 1) md5 20CB8D4CB322AA503D1B8A49C43CDEBF

Resident Evil (Europe) (En,Fr,De,Es,It) (Disc 2) md5 457944F833FC2F5E8FF394CFDF2E1B7C

Resident Evil (USA) (Disc 2) md5 7DEFD099E98944BC93684D4733BFE68B

Resident Evil (USA) (Disc 1) md5 BDD0FE3848C4AB1441DC6C9EE209426B

Biohazard (Japan) (Disc 2) md5 BFBF8E0F249CF8DD8FCB913793301A8C

Resident Evil (Europe) (En,Fr,De,Es,It) (Disc 1) md5 C581FAB5FD10F55B76188E86194199C1

---------------------------------------------------------------------

CDGroup v0.4.2

CDLibrary v0.4.2


Processing '2048'

 Grouping '2048' (6 files)
  Hashing 'Biohazard (Japan) (Disc 1).iso'
  Hashing 'Biohazard (Japan) (Disc 2).iso'
  Hashing 'Resident Evil (Europe) (En,Fr,De,Es,It) (Disc 1).iso'
  Hashing 'Resident Evil (Europe) (En,Fr,De,Es,It) (Disc 2).iso'
  Hashing 'Resident Evil (USA) (Disc 1).iso'
  Hashing 'Resident Evil (USA) (Disc 2).iso'
  Sorting sectors within images
  Merging image sector hashes
  Counting repeated sectors
  Create map from images to merged files
  Writing 2048.hsn
  Writing '2048.hsm'
  Writing hs1.2048
  Writing hs2.2048
  Writing hs3.2048
  Writing hs4.2048
  Writing hs5.2048
  Writing hs6.2048
 Group of 2048 byte sectors successful

'2048' successfully processed

Doing external diff on 2048 byte/sector files
  Diffing to 'hs2.2048'
  Diffing to 'hs3.2048'
  Diffing to 'hs4.2048'
  Diffing to 'hs5.2048'
  Diffing to 'hs6.2048'
Diff successful

Compressing files


torrent7z_0.9.1beta/Thu Jul 23 03:08:33 2009
using 7-Zip (A) 4.65  Copyright (c) 1999-2009 Igor Pavlov  2009-02-03

Scanning

Creating archive ngc\ngc.7z.tmp

Compressing  ngc\hs1.2048
Compressing  ngc\hs2.diff.2048
Compressing  ngc\hs3.diff.2048
Compressing  ngc\hs4.diff.2048
Compressing  ngc\hs5.diff.2048
Compressing  ngc\hs6.diff.2048
Compressing  ngc\2048.hsm
Compressing  ngc\2048.hsn

Everything is Ok

External compressor seems to have completed successfully

Size of original images: 8759869440 bytes
Size of merged uncompressed files: 5216682706 bytes (~59 % of original images)
Size of merged + diffed files: 3066362234 bytes (~35 % of original images)
Size of merged + diffed + compressed files: 2308632971 bytes (~26 % of original
images)

Time taken to group: 0 hours 10 minutes 0 seconds
Time taken to diff: 0 hours 13 minutes 52 seconds
Time taken to compress: 0 hours 22 minutes 58 seconds

CDGroup completed in 0 hours 46 minutes 51 seconds

Press any key to continue . . .

NOTE:

CDGroupv0.4.2's size of files = CDGroupv0.3.1 before Diffing and before compression (4.85 GB).

CDGroupv0.4.2's size of files after Diffing and before compression = 2.85 GB (42%) smaller after Diffing. smile

I'm going to have fun with custom compression - on those sizes. smile or not sad

I dont understand all that.

I tested Timeslpitters (2 Discs).

When I say I got smaller size with the old version, I meant after packing my old version.

With the new version it made all the files ok, but I was reffering to after your programme packed it into one single 7z.

I guess the reason the old version was smaller was because I used better (more suitable comprssion) torrent7z is know to produce larger files than pakkiso, and I used custom pakkiso compression. I also used torrent zip, as this seemed to get the smallest size on every file except gs0.

I also tested on Metal Gear, the one I chose to leave uncompressed, their was a small saving using the new version as compared to the old version left uncompressed.

I will further test, for sure, If I get the same thing happed on another test old is better than new, I will unpak your single 7z and pakk it using the compression I found worked the best with the old version, and post those findings.

I did some quick tests.

It seemed I was able to get the size smaller with my own compression and the old version, than this new version was able to get.

Will test soon, on something from above to see how it compares to the old format.