What about the CDTV? I've seen some really strange EXE dates for that system... Is it even worth to preserve the EXE date in this case? Surely neither the disc nor the program was created in 1978
Re: Some news concerning EXE dates for older systems (3 replies, posted in News)
Yes, please add them We don't really care what people do with the images; as long as it's game-related we add it. You could probably play it illegally on a private server with the image, or buy a subscription without having to buy the actual game discs and so on... It doesn't matter
I'm 90% sure it doesn't have any copy protection. You can't play the game without a subscription anyway, so why would they waste money on protecting the disc? But you should always check with BurnOut or PiD to be 100% sure.
In any case you can dump it like any other DVD with IsoBuster, no additional steps required.
Yes, technically these are normal DVD-V. Just with interactive content, but still playable on any standard DVD player. Personally, I don't think they deserve their own section on redump. There's no such system as "DVDPG"... These discs are really just plain Video-DVDs and should therefore be treated as a subset of the DVD-V section
I haven't figured it out completely yet, but the last letter before the -UKV or -EUR seems much more important. There seems to be a pattern: P is for Europe, D for Germany, E for USA, J for Japan, F for France, U for Australia and so on. Haven't figured out X and Y yet... Anyway, it would be wrong to assume that UKV means UK-only.
Well afaik that's only true for discs with a large positive combined offset (larger than 1 sector = 588 samples). But again, I've never tried to dump discs with a negative combined offset
I have Pioneer DVD drive with a combined offset of +48, but I don't intend to dump any PSX titles. Also, shouldn't reading into the Lead-In solve the problem?
Sorry, no idea ^^ I've never tried anything else than my +667 drive for these discs. I just remember that years ago, many dumpers had drives with large positive offsets so they could dump discs with large negative factory offsets.
The bigger problem I think is that you won't be able to detect a negative offset larger than your drive's positive offset with IsoBuster ^^ If you've read the guide you maybe know that you have to go back 150 sectors (in case of a 2 sec pregap) and count how many rows of junk data you see (because the end of the junk data marks the beginning of track 2). However, if the disc's negative factory offset is too large, you won't see said junk but only 00s, so there's no way to determine the start of track 2, respectively the combined read offset.
In any case your +48 should be enough for most PC discs. Common PC offsets are -22, -12 and 0. Tendentially, the older the disc, the more obscure the factory offset
There is an offset for data tracks, too. Drives recognize and correct it automatically. For an audio disc it doesn't really matter if your music is shifted by 1 or 2 hundredth of a second, at least from a pure listening point of view ^^ But non-audio data usually needs to be bit-accurate, so the drive has to adjust to both the factory and the drive's write offset.
And no, there's no overlap for discs with a negative offset. If the disc has a factory write offset of -647, for example, all data and audio tracks are shifted by those -647 sectors. But, as I mentioned before, the data tracks get adjusted properly, while the audio tracks don't, that's why we have to do that manually ^^
That said, it's possible that EAC loses samples at the beginning of the 1st audio track if the combined offset is negative. It's an annoying EAC quirk. You'll have to make sure that your drive's offset "outweighs" the negative factory offset. I have an LG with +667 which I use to dump -647 (a common PSX factory offset) or similar. If you're lucky, you have a Plextor. In this case you can use PlexTools, which doesn't seem to be affected by that problem
As for IsoBuster, it does know where the data track ends, but it appends the pregap of the 2nd track to it. The reason we need to cut that off is because redump handles the gaps differently. IsoBuster appends a track's gap to the end of the previous track (so the Track 2 pregap is put at the end of Track 1), while redump prepends the gap to the track it actually belongs to (pregap, as per cue specification ^^).
Appending the gap to the previous track is kind of a hackish solution to allow people to listen to their audio tracks without having the (mostly silent) pregap at the beginning.
I hope that answers all your questions
Sorry, but yes, it is mandatory. Using the combined offset corrects not only your drive's offset, but also minor inaccuracies the mastering plant made when pressing the disc, so to say. So why do we correct these inaccuracies? Well, it's possible that different pressings of the same game have different factory write offsets, but are otherwise 100% identical. It'd be stupid to have duplicate entries for these, so we remove (i.e. correct) said factory write offset.
Don't worry, even though we "modify" it, the dump is still accurate, but more in a sense of how the disc was intended to be mastered if it wasn't for these inavoidable accuracies, and not how the disc actually came out of the mastering plant. I hope this makes sense to you
Besides, your dumps would be incompatible to all the other dumps in the DB. You wouldn't be able to match anyone's dumps, and neither could anyone match your dumps.
That's exactly it It's a cheap ass thing but it gets the job done.
The biggest problem is that IsoBuster has no option to limit the extraction speed. I use CD-Bremse for that, but it only goes down to 4x. So I extract everything twice (usually in chunks of 50,000 or 100,000 sectors), or more often if I get inconsistent results. Worked pretty well so far, but it does take time
Yes, a bunch All my DC dumps were made that way. Why do you think IsoBuster wouldn't do it right? ^^
Nope, I'm using IsoBuster (+CD-Bremse to slow down the drive). Works pretty well. I could never get CDRWin to work...
No idea about that thing's name, the packaging is long gone All I can say is that it's by a company named DeLock, and on bottom side there's a sticker that says "Ver:108B0".
Drive: Samsung TSSTCorp SH-D162D w/ Kreon Firmware (through an IDE-to-USB connector)
MB: MSI MS-7358
OS: Vista64, up-to-date
besides when it comes to dvds do you have the slightest idea the millions of movies and varations out there?
ghost, lemme fix that for you: "besides when it comes to PC games do you have the slightest idea the millions of different versions, editions and varations out there?" I hope you understand what I mean... If anything, the complexity of the task or the number of discs out there should be an incentive, not a reason against it ^^
Audio could be popular but video is so large that it probably wont be of too much interest to random people; average joe will ignore redump and stick to h264/xvid avi/mkv etc.
I think neither will be of interest to many people. As I've said, there already is AccurateRip for Audio CDs, which does *exactly* this, except for "advanced" things such as overreading etc. Average Joe still thinks that 128 kbit/s sounds great (the more audiophile Average Joes might prefer iTunes ^^). A FLAC rip is already overkill to most people, even if it's not offset-corrected, or no overreading or gap detection was used. Redump dumps would definitely be way too clumsy for most people. You couldn't even tag them without altering the checksums
All that being said, I still don't understand why a games DB - especially one containing Wii, Xbox 360 and PS3 would be any less dangerous than one with movies or music... The games industry isn't any less fierce when it comes to persecuting filesharers ^^ quite the contrary.
Mmh, take AccurateRip, for example. They do exactly the same thing for audio discs, just not accurate enough for me (without overreading, gaps etc). They've been doing it for years, have tens of thousands of discs in their database and afaik never got into trouble. I doubt anyone could possibly sue redump or any other project for providing checksums ^^
Wii, 360 and PS3 actually are hidden for guests, so that could be done for regular DVDs/Audio CDs, too, if you prefer to keep it silent ^^
Because we're lazy and incompetent. That's what you wanna hear, isn't it?
Seriously, the mods are little more than adding/fixing slaves you'd have to speak to the admins about such general questions regarding the project's direction. As far as I know, redump only wants games or gaming-related discs, so these discs - as rare and interesting as they might be - won't get added.
That being said, I've repeatedly said that - personally - I'd love to have all kinds of discs in the database, even if they're not gaming-related. Video-UMDs and Video-DVDs in general, maybe even Audio-CDs. I'm not only interested in games, and I'd love to have bit-perfect DVD-V and CDA dumps (and even CDi movies ^^) just as much as PSX or PS2 ^^ But I doubt that'll ever happen... Besides, this project has bigger problems than that
Cool indeed ^^ Finally the wiki is being put to use. Anyone willing to do a full IBM PC list?
@r09: But weren't all our current PCE CD dumps "bad" anyway? I believe there was some dispute about the gaps... Was that ever resolved?
You needn't use CMP. Just calculate CRC, MD5 and SHA-1 as you would with any DVD game (via HashCalc or whatever you use).
When adding the disc, put the following in the "ClrMamePro data" field:
size 12345678 crc aa11bb22 md5 736528356283765235 sha1 634587648561287563287546
Just replace my random numbers with your image's values. Size is the image size in bytes (as always, real size, not size on disk). CRC, MD5 and SHA1 should be self explanatory
Then you need to supply a cuesheet. PS2 CDs are MODE2, so you can always use the following:
FILE "Track01.bin" BINARY TRACK 01 MODE2/2352 INDEX 01 00:00:00
What does "locked" mean?
No idea. As I've said I'm not familiar with Hashcheck. My guess would be that it cannot access the file because it's already opened elsewhere.
And for resume, If the HASH of my ISOS fits with those that are on the web, that means that my dumps were correctly done, Am I right?
That's absolutely correct. You don't actually need the .sfv or .md5 files. As long as all the checksums on the website match your local file, you can be sure it's 100% identical (and correct)!
Strange, if you open the .md5 in a text editor you'll see that it contains the exact same hash as on the website:
.md5 file: c92fcaaa3b8e6edb377c9573be67ae03 *God Hand (Europe) (En,Fr,De,Es,It).iso website: c92fcaaa3b8e6edb377c9573be67ae03
I'm not familiar with Hashcheck but maybe it needs you to rename your file according to the .md5 filename in order to verify it. Try to rename your file to God Hand (Europe) (En,Fr,De,Es,It).iso
Or better yet, use clrmamepro It can both check and rename your files automatically ^^
Okay, I knew they did this for patches, but I've never heard of a physical release with a cracked exe before I mean, I can't even imagine why they wouldn't just use the original exe. Who if not them would have access to it?
The real irony here is that this is UbiSoft, one of the main protagonists in the ridiculously-restrictive-DRM circus ^^
I know it's a bit off-topic, but I just have to share that with you
During the usual pre-dumping examination of my original copy of Rainbow Six (Gold Pack Edition), I found the following:
I couldn't believe my eyes when PiD said "RAZOR 1911". Seriously, what were they (UbiSoft, to be exact) thinking? Using a cracked .exe in an official release of their own game? That's the first time I've ever seen something like this. Or is this common practice?
In any case, way to go, UbiSoft. You sure are great role models I'm sure that finally convinces people that piracy is bad