You are not logged in. Please login or register.
Redump Forum → Posts by Jackal
lol, Dremora can't manage to write such a tool in 3 years time and you do it in 1 day (and you both live in Latvia? 
)
So the sbi format is missing relevant data that cannot be generated again? How about a tool which loads the libcrypt sectors from the database instead of using the sbi file? 
Some dumps have spaces between numbers and some don't.. isn't it time we choose a standard? I vote for barcodes without spaces. Besides, we have to make a distinction between 13-digit EAN codes (Europe dumps, and maybe others..?) and 12-digit UPC codes (USA dumps, and maybe others...?).. UPC can be turned into EAN by adding a zero in front, but I think it's better to leave it as 12-digit UPC.
Therefore, maybe if we could have some sort of "form" with fields that the user could complete it might encourage more people to contribute dump info - or some sort of standard layout that needs to be followed when submitting release info to the forum (everyone seems to have their own ways and inclusion of supplied reports such as LC1/LC2 info and EAC/psxt001z logs).
When you obtain dumper status you can use the 'New Disc' function which has exactly that 
ps. could anyone tell me what this topic is about? I seem to have missed something.
I don't see any logic in your answers.. nobody makes their .cue's manually because of the filenames etc... and .sbi only contains the libcrypt sectors, so it wouldn't be difficult to implement this in psxt001z using the fast option (if that's what you're aiming at) and then it would be possible to dump .sbi files. The point is that the dump is useless in emulators without this file. It would be the same as having to download a .cue file each time they wanted to play a game.
Then again, it's not even real dump data, and there's no such thing as a .sbi burn tool, so it doesn't make much sense to only include it for emulators. I don't think we'll ever get a way to generate these subs (it's possible, but Dremora clearly has no time).
He's talking about .sbi.. they can be downloaded from the site, so I think he means why don't we add those to the .dat if they are needed anyway?
Nope, because you won't be able to read them from the CD again with the same checksum, so the checksums for these files are useless.
What do you mean?
I hope iR0b0t can tell.. you could try using the xbox1 dumping method, it might work (the discs are similar afaik) 
Nah, Original edition was already dumped also.. but you're right that the Comments only apply to the other version.
Hi,
some of us already had a closed discussion about DVD-video last week or so.. the bottom line is that CSS/CPPM and other copy protections can't really be 'preserved', so it's not possible to make real 1:1 copies (keys are hidden in the lead-in area, etc.). Some tools claim they can do "perfect 1:1 bit-to-bit" copies of video DVD's, but we don't think this is true because the data would still be decrypted before it is saved.
Another thing is that some staff members think that Redump wouldn't be the right place for these dumps (because it's not game-related and because it would be a impossible task because there are so many DVD's). I disagree with this myself, because we're already dumping game-related audio cd's and video dvd's.
I also have about 150 movie DVD's that I would like to store the checksums of, but we'd have to come up with a proper dumping method and then also find a place to post them (maybe if more people like you show their support for the idea then we can think of forking the project or just change our policy and allow these 'systems' after all).
Should we fix norman's Euro Demo dump names so that alternative name gets the date and the primary name a number?.. someone would have to check the images to obtain the correct number (I no longer have these dumps).
The amount of dumps in the database has doubled in less than a year. Good job dumpers!
IBM games usually have differences in data and audio between versions, so everything's correct.
Looks like subs aren't "clean" on CDs themselves...
Who says they should be? PR + cdreader output should be reliable... have you tried selecting ASPI instead of SPTI in cdreader? anyway, just use the latest perfectrip with 'keep sony pregap' disabled.
PR never alters subs as long as the 'keep sony pregap' checkbox is unchecked (always leave this unchecked when doing 1:1 sub dumps!).. if it's unchecked then any errors are from the drive and not from PerfectRip.
If the checkbox was already unchecked, then either the original output is wrong or there's a bug in PR.
ps. clonecd is known to jump over gaps sometimes and autogenerate them, so if you want to be 100% sure that the .sub output is correct, I think it's best to use PR with the proper settings.
I already heard people say before that clonecd/alcohol sometimes alter the subs.. so you should always try to use Perfectrip in CCD mode.. I also don't think that the drives are causing this.
Use the latest perfectrip in .ccd mode with 100b mode and a low speed (cdreader can't extract a full images of mixed mode cd's afaik).
ps. of the 52 saturn games that you dumped, 12 are verified.. also, I don't see how subchannel reading can go wrong?
PX760A not able to read subs correctly? 
you must be dreaming..
A wikipedia article would be nice also who has time?
We only have to remove the serials from PSX/PS2/PSP.. then all systems will have the same filenames
You should discuss this with Dremora, because he's still the only person who can change anything.
I also think that for v1.1 etc. dumps that perhaps it would be good to have the # or whatever's printed behind it on the disc in the filename (if such characters are possible in filenames)..
For JAP games with different printed serials for a same version maybe it's best to use the internal serial in the filename?
The current logic is that it only uses the first serial that is entered in the db (for easy identification), so if you put a different serial first it will use that one. I'm not sure what's the point of having 4 serials in a filename. It would be the same as having the barcode or publisher or languages or whatever imho. For this information we have the db.
IMHO we should either:
- only use internal serials in filenames and put any other 'external' information in the db.
- switch to the No-Intro naming convention and have new issues (like too long filenames) to keep us busy
Your other drives have a different read offset, so you'll have to calculate a different offset value in EAC for each drive (depending on the amount of garbage that you see in that sector).
As for the crc of the data track not matching: make sure that you do 'psxt001z --fix' after removing the pregap. Then they should all match.
The data track is correct now.. if you already have the offset value needed for EAC, then you should just extract Track02 in EAC (with the pregap of 0 seconds)..
after that is done, you'll have to add the pregap manually by adding 352800 bytes of zeroes to the beginning of Track02. If you don't know how to do this, just do the following: get this file, put it in the same folder as the track02 file.. then in Command Prompt, do 'copy /b pregap.bin+Track02.bin newtrack02.bin' (replace Track02.bin with the correct Track02 filename).
You'll probably end up with a dump that matches this one (at least the size of each track will be the same): http://redump.org/disc/3379/
Wow! I just tested with ElbyECC.dll 3.1.0.0 and Vigilante 8: Second Offense and it works perfect (all checksums match db)! You're the man.. I've added it to the guide (hopefully all data is included on discs with negative offset). The only thing that's incorrect is the combined offset (but it's not really important I guess):
Combined offset (samples) : -23813975
from only gd-rom i could test it looks like gap preceding last data track is 3sec long:
75audio/150data, a lot like PCE (from sector content - i haven't checked subcode)
in database currently ther's either 2 or 0 sec gaps at this position.
this program will go for 2 and will freak out if ther's less than 150 data sectors there.
I don't know about this.. perhaps you could check the subchannels.. it's propably just a postgap and not really part of the last data track.
but in db every game has different size, hmm
Don't forget that the total size in db also includes track 1 and 2 
ps. I added the elbyecc.dll to the download in the dumping guide.. I hope that doesn't get us into trouble?
I can't find any documentation on it.. anyway, here's the TOC (0100-02FF) of Mortal Kombat Gold.. maybe it is of some use: http://www.speedyshare.com/432639791.html
And thanks for trying!
Redump Forum → Posts by Jackal
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.