76

(8 replies, posted in General discussion)

How would I do that? Would  I have to dump the whole disc with clonecd, then a track by eac with no pregaps, to find the eac dump in the clonecd dump?

77

(8 replies, posted in General discussion)

Thanks.

78

(8 replies, posted in General discussion)

Would it be safe to rip audio with no pregaps, then detect the pregaps with a different drive and prepend the pregap?

I ask because I finally have a drive with a big enough offset to rip -647 write offset discs, but it seems to be having trouble detecting pregaps on some discs with all 3 methods.

For example. Trying to verify Actua Soccer 3, but the detected pregap for track 2 is either 0, or some non 2.00 value. Track 2 definitely has a 2.00 pregap, because I've searched there for scrambled data and came up with a -647 write offset (and indeed matched the db by prepending a 2.00 pregap). With a different drive, the proper pregap is detected.

Note: This is for psx discs, so no data in the pregap as far as I am aware if that makes a difference.

Hello again, I have more issues as I dump different discs. The drive I am using has a read offset of +48.

http://img209.imageshack.us/img209/7607/fapremleaguefootmanage2.png
One release I am trying to copy has a track 2 pregap of 0. So I open track 2 in sector view and it is as shown above, with zeros in the sector until the text you can see. What should I do here?

http://img830.imageshack.us/img830/4655/checkmate.png
Another release. Sector 6004 has zeros where there should be scrambled data. This corresponds to note 1 of the guide, which says to use a drive with bigger offset. Is this the only solution? I'm quickly running out of drives  tongue

Reload the images in a different window to get them fullsize.

Thanks. Just my luck to get annoying drives. I think I have another somewhere, will try that too. Anything for an easy life.

edit: Third time's the charm. An oldish pioneer worked when a newish freecom and new samsung didn't.

Thanks for the quick reply. I've tried a different drive but it has the same problem, how common are drives that can't over-read into lead out, and am I right in thinking that it doesn't affect my ability to copy single track releases?

I've dumped stuff before but not releases with audio tracks. Anyway, I have dumped a psx game with audio tracks following the guide, with no problems except the last track says there was a sync error. I've re-ripped it multiple times, with the same sync error warning and the same hash each time.

Should I add everything to the database, or just the files with no sync error, or not at all?

RiMMER wrote:
Jackal wrote:

so we should switch to a proprietary and closed format.. and for what?  roll

That's a good point and I fully agree with that, but then again, by claiming this, you go against yourself.
The ECM thing you people use in the pakkiso thing is something similar. There is no way I can work with that in linux. But yes, I am the only one who uses linux, so you have no reason to care, I know smile

http://www.neillcorlett.com/ecm/
ECM comes with the source code on the main website, and has a GPL license. Does that solve your problem?

iR0b0t wrote:
jamjam wrote:

I guess larger games end up having a smaller filesize

How is that meant?

By that I mean that for games with more game data (as opposed to random padding), a higher % of the 7433027584 bytes an xbox image takes up will have a chance of being compressed well. I hope that makes sense.

I've compared the compressed filesizes of some games released on ps2 and xbox, the difference is astounding. I can see why this is such an issue, and hope that someone can pull a miracle out of the bag. I guess larger games end up having a smaller filesize, because there's a lower % of random padding?

If the data is truly random, then by necessity no compressor will compress it. If you want to 'compress' it, the only hope there is is to find out how the random padding was generated, and emulate it if possible (severe longshot). One way I can think of where this might be possible is if they used a pseudo-random number generator (the entire sequence is determined by an initial 'seed' number), then brute force it. Maybe if microsoft has developed a random number generator you might have somewhere to start from, but anyway, good luck with that.

I have a few questions, just out of curiosity:
1/ How much padding would an average game have, does the amount vary from game to game?
2/ Would 2 copies of the same game have the same padding?
3/ Is the padding common to different games (maybe a particular developer has their own)?
4/ Is the entire padding for a game contiguous?
5/ Is the padding referenced in any way (maybe a hash check to ensure it's there), or is it properly just padding?

If padding is the same across many games, you've got the simplest answer. Distribute the games with the random padding zeroed, and distribute the padding seperately as a patch (which works for all the games with that padding). Couldn't use imageDiff, but a simple patch format could be made.

tossEAC, sorry man but the safe-cracker idea seems dubious. What would this constantly shifting random file do exactly? There's nothing to say that 4 consecutive bytes at location X can't be identical to 4 consecutive bytes at location Y, all we know about the data is that it is random. Hex is base 16, so there is something wrong with how you've converted the numbers, but what are you trying to do with converting between bases? Computers store data in base 2, there is no way around that. When you say that the binary ended up bigger, I'm guessing you are saving the codes in a text file? Each written character of binary then consumes 8 bits to describe (or 16 depending on format), instead of the intended 1 (and written hex takes up 8 or 16 bits instead of 4). Does that make sense?

Thank you. At some point in the future I plan to scan the covers of all of these, that will have to do instead of adding comments I think, I don't want to be doing this all day  big_smile

Just want to double check I'm filling the form in right before submitting them all, 50 is alot to submit wrong  big_smile

I've submitted one how I think it should be done (Official PlayStation 2 Magazine Demo 6, although I forgot to put the version in, it is 1.00, will post in fixes and additions if it isn't picked up here). I've left the editions section blank, and the disc number/disc title blank as I assume it's only for multi-disc games, and the DOL md5 blank.

Is that all correct?

89

(8 replies, posted in General discussion)

There's no problem, I was just being an idiot.

90

(8 replies, posted in General discussion)

1. I still have the discs and images, I dumped them previously
2. I checked the images and recorded the info recently
3. I'm not sure if I used the right setting previously for the date, but as I didn't record the exe date then it is irrelevant

Hope that clears things up, and I hope there is no problem as I have already submitted the 3 new dumps I have.

91

(8 replies, posted in General discussion)

Thank you both for clearing that up. Sorry for the wrong forum, it can get deleted now  smile

92

(8 replies, posted in General discussion)

By reformatted since, I mean I wiped the Os partition, which had the isobuster install, so I can't remember if I changed the settings.

I haven't submitted any of the dumps yet, I copied from the discs but didn't compile the data required until now. Am I right in thinking that the setting doesn't affect the dump itself, just the format of the dates of files in isobuster (to get the .exe date)? If that's the case there is no problem, just a noob being noobish big_smile

93

(8 replies, posted in General discussion)

Hi,
I dumped some ps2 games awhile back (reformatted since), and can't remember if I changed the date settings in isobuster according to the ps2 dumping guide:
"Download and install IsoBuster 2.1. Launch the program, select Options -> File system settings menu item, in Display time stamp options group select Local time stamp option."

I've checked one of my dumps against one in the DB, the checksums and size match. My question is, if I didn't set the date does it matter, and if it does, how do I find out if I have?

Thanks.