I just dumped the PS2 game 'Ultimate Board Game Collection' and almost submitted it as a DVD5 because it has the standard 'silver' CD/DVD color (NOT the usual PS2 blue-green CD color) even though it on CD medium. Evidentially, Sony has stopped requiring the colored CDs. It might be a good idea to change the PS2 dumping tutorial info about how to identify CD versus DVD or someone might make the same mistake I almost did.
27 2010-05-23 20:52:06
Re: Newbie needs some advice for multi-track PSX (4 replies, posted in General discussion)
Thanks velocity, that info is really helpful. I'll check into PerfectRip. So when EAC 'detects gaps' on (for example) a standard three-track disk, the 'gap' listed for track 2 and 3 end up attached to the beginning of those tracks, right? What was confusing me a little: EAC lists 3 gaps for a disk with 2 audio tracks. Does the 'gap' detected for track1 end up attached to the beginning of track1?
PSXtoolz and CDMage didn't detect any errors in Tarzan's track1's dump (using ISOBusrter's 'extract track01' +PSXtools 'fix'). What is the psxtoo1z command to project image filesize?
Is the following method correct for dumping track2? Disk is -12 and drive is +6 (with overread support):
1) Dump track 2 in ISO buster using 'extract from-to' with the preset start address minus 1 (to accommodate -6 combined offset) and leaving preset end address as-is.
2) Delete data equal to one sector minus the combined offset from the beginning of the track (2352-24 bytes = 2328 bytes).
3) Delete data equal to the combined offset from the end of the track (24 bytes).
28 2010-05-21 12:34:27
Topic: Newbie needs some advice for multi-track PSX (4 replies, posted in General discussion)
I'm trying to dump the Collectors' Edition version of the two-track PSX game Tarzan and I've encountered something new to me. So I could use some confirmation from more experienced dumpers that I'm doing it right.
Some info:
Track 2 is blank (all 00s) so I can't see where the gap ends and the actual data begins.
EAC detects the gap on track1 as '2' and on track2 as '0'.
Some things that are happening differently than I'm used to:
When I go to 'sector view' for track 2 in ISOBuster, it opens to the exact end of track1 (IE to the beginning of the 'garbage data' generated by my +667 drive) instead of opening to the end of track2's gap like I'm used to.
Usually, ISOBuster shows the size for the last track to be larger than it ends up dumping in EAC. But, in this case, EAC dumps track 2 at the same size shown in ISObuster.
Does the 'gap' listed by EAC for track1 end up attached to track2's as it's 'pre-gap'. If so, is the 'gap' for the last track just discarded since there's no 'next track' to attach it to? That would explain what I'm experiencing anyways. Any advice about how to dump this correctly would be appreciated.
29 2010-05-21 06:14:09
Topic: Confusing problem dumping multitrack (4 replies, posted in General discussion)
First off, my Black Dawn PSX here should be removed for now, since it seems to be inaccurate.
http://redump.org/disc/7727/
But, I'm clueless as to what went wrong.
I dumped all the audio tracks on two different drives using EAC and got identical results, however someone pointed out that track 19 and 47 appeared to have some data cut off the end compared to other Internet images available.
So I redumped Black Dawn (with EAC) using a third drive and all the tracks came out the same EXCEPT tracks 19 and 47. On this third drive, 19 and 47 now match their European counterparts. On the inaccurate drives, EAC seems to have replaced the last 54127 bytes of data with zeros, but when I look at the raw sector view in ISO buster, the cut-off data is there- meaning the drives are capable of reading it, but EAC is just cutting it off for some reason.
So what in the heck is the problem??!! I redumped again using the two inaccurate drives and got same results as the first time (aka data cut off in those two tracks) but most of the other USA audio tracks matched the Europe versions so I think all my software settings are correct.
Why would two tracks come out wrong?
Now I'm worried about the accuracy of all my other multi-track dumps so any advice would be most welcomed??
30 2010-05-16 06:03:40
Topic: Might a PS2 Action Replay disk have some sort of copy protection? (4 replies, posted in General discussion)
I'm trying to dump an Action Replay cheat code disk [1 track on CD medium] for PS2 but it immediately comes back with read errors in ISOBuster. In Windows explorer, all the files drag off the CD without problem except one named 'BIG.DAT' (likely the file that contains the cheat codes).
I would think the disk was bad but it's not scratched and it works flawlessly in a PS2. I suspect AR used some sort of non standard format to protect their codes from being copied off the disk. If that is the case, anyone have any ideas how to properly dump the disk?
31 2010-05-12 03:43:33
Re: Rhaosody & px_d8 question (22 replies, posted in General discussion)
I'm having similar issues to Specialt1212 so thank you for the great explanation velocity37.
I have multiple copies of several PS1 games and I have found two games so far (Rayman, Darkstone) with identical data but different offsets (+2 and -617?). The end result is that my +6 drive can easily dump the +2 copies and have it match the database, but I have the same problem as Specialt1212 with the -617 copies. In ISO Buster's 'Sector View', the -617 disk's data is identical to the +2, but it's pushed back by about 1 1/4 sectors.
I decided I'm not going to dump a game whose offset doesn't produce the measurable 'garbage' data to assure the total offset because the odds of me making a mistake if I manually extract an audio track is just too high.
32 2010-05-05 01:29:40
Re: Dumping questions (11 replies, posted in General discussion)
Thanks! I got the submission form to work.
33 2010-05-04 06:45:53
Re: Dumping questions (11 replies, posted in General discussion)
I keep getting an "Error parsing datfile" when I try submitting through the New Disk form.
Below is the format I've been trying to submit:
rom ( name track01.bin size 310941456 crc 0x33e54465 md5 0xbcfb31943099884a7b96b25b238c6742 sha1 0x61b8e6e134036806c09fa55d1904a850500c1d0b )
rom ( name track02.bin size 34675536 crc 0x3561d9d7 md5 0x4d9b29532bf6f167fe02bece59baef3b sha1 0xe55d5a6cccd78b87d885c63ff736d300a881af8a )
. . .
rom ( name track57.bin size 35103600 crc 0x7d46743f md5 0xece4ee4bd7df81a2b2fe09926ab9b67f sha1 0x67f6e8792b15f581d256f99eed66cb724dddb329 )
)
What format should the info be in?
Also, EAC created a CUE sheet with a bunch of information that isn't normally in redump's cues. Is there a way to get it to produce a cue that is closer to what it's supposed to be?
34 2010-05-04 02:33:40
Re: Dumping questions (11 replies, posted in General discussion)
Ok, I figured out the issues and think I can get it right now.
For some reason, EAC is not properly dumping the last sector even though my drive does support overread. Tomb Raider has a single 1A byte (rest are all 00s) in the last sector of the last track and EAC dumps it as 00. I'll double check my EAC settings against the tutorial again, but does anyone know of a setting in EAC that could cause this to happen?
I finally got it right using velocity37's method with ISOBuster. I failed the first time because I was trying a new hex editor and it was displaying 18 bytes per line instead of the 16 I was used to- so I was deleting the wrong number of bytes- me stupit 
Thank you everyone (amarok, the comparison file really helped!)
35 2010-05-04 00:54:32
Re: Dumping questions (11 replies, posted in General discussion)
Thanks 
I'll see what I can figure out using it as a reference.
36 2010-05-03 23:39:15
Re: Dumping questions (11 replies, posted in General discussion)
Thank you all for the great help! I understand what I'm dealing with a lot better now.
If the Playstation's drive can accurately read the last sector, I'm surprised there was never a copy protection scheme that put part of the game's code at the end of the CD to make it inaccessible to many PC drives.
I think I found a drive in my 'stockpile' that supports overreading. It can view past the last sector in ISO buster without any problems and it will dump the last track of Tomb Raider in EAC without any errors. BUT, my dump of the last track still doesn't match the CRC listed in the database. This is especially surprising since it appears to be a totally blank track (all 00) and my dump's size matches the database (seems like the CRC would match too if they're both blank). I tried velocity37's method using ISO buster but just ended up with a track identical to EAC's dump (ie doesn't match database's CRC).
If someone has a few extra minutes, could they send me a copy of track 57 (last music track) from any Tomb Raider game (all versions seem to have identical track 57 except the Japanese version) so I can see what I should be dumping? Since it's mostly 00s, it should compress down to practically nothing and be easy to send.
The new version of TR seems to fall in between the (USA) v1.1 and v1.2 based on the dates on it's files and I've successfully dumped all it's tracks except the last. It would be a shame if I can't add it to the database because I can't get the last track dumped correctly.
37 2010-05-03 02:36:56
Topic: Dumping questions (11 replies, posted in General discussion)
I'm trying to figure out how to dump CDs with multiple tracks by dumping a copy of Tomb Raider GH (PS1) and matching my results against the redump's database to ensure I'm doing it right. But I have a few questions.
What does psxtool's "fix" command actually do? (I like to understand what I'm doing rather than just follow the steps.)
Is there any definite way to figure out if my drives supports 'over-reading'?
On one of my drives (SONY CD-RW CRX215E1), if I use ISOBuster to 'view sectors' and go backwards from the beginning of track2 to find the end of tack1, initially I see the correct amount of 'garbage' data at the end of track1 (Tomb Raider is +2, the drive is +6, so I see +8 total 'garbage' aka 32 bytes- if I'm thinking correctly). But, if I go back one more sector (to where I'm looking at the data track1) and then go forward again, ISOBuster shows more that 1 sector of garbage data in the same sector that only had 32 bytes a moment ago. Animation below is actual screen shots. Is this normal?
On Tomb Raider (USA- Greatest Hits v1.2), ISOBuster shows the last track (57) having a size of 34,750,800 however my drive dumps 35,103,600 (and redump's database also lists 35,103,600). Is it normal for ISOBuster to report the last track's size incorrectly?
I tried dumping Tomb Raider on two different drives and all the tracks turn out correctly except the last one. EAC doesn't report any errors and my dump's size matches what Redump's database says it should be, but the crc doesn't match. Could I be doing something wrong that's making only the last track dump wrong?
If the CRC mismatch is likely because my drives don't support overreading, can anyone recommend a DVD drive model currently available (from Amazon/Newegg etc) that does support overreading?
One of my copies of Tomb Raider GH isn't listed in redump's database; if I am having an overread error, is there any way to manually fix the last track so I can catalog the new version?
Thanks
38 2010-04-30 10:58:33
Re: [FIXED] Madden NFL 98 version (2 replies, posted in General discussion)
I should have mentioned, that is the USA NTSC version of Madden 98
39 2010-04-30 09:43:44
Topic: [FIXED] Madden NFL 98 version (2 replies, posted in General discussion)
I have an original Playstation Madden NFL 98 game with a verified CRC-32 of c14db6d4 as opposed to the one in the database with a CRC-32 of 5595848f.
My copy's "DATA" folder has a date stamp of 7/7/97 10:09:12 as opposed to 27/7/1997 11:16:46 listed by redump's database (as remarked in the listing).
I'm not dumping anymore, but I though people with a Madden98 image that matches mine (CRC-32 c14db6d4) would like to know it is not a bad image, just a different version.
40 2009-07-08 22:24:45
Re: Region and language tags (49 replies, posted in General discussion)
I've always hated no-intro's names. The language tags aren't really necessary to include in the names; I would equate them to including a genre tag like 'RPG/FPS' etc in the name. And the missing serials are a serious hindrance- bad choice.
For example, if I have a slightly corrupted dump that I'm trying to fix to match the appropriate copy in the dat file, is it v1.0, v1.1, v1,.2? Without the serial in the name, who knows? Also with PSP images Redump's dumping method pads more 0s on the end of the ISO compared to the easier 'UMD to USB' dumping method; without a serial to match, there's no way to know how many 0s to add to the end of the ISO to get it to match Redump's file size. Translation patches that only work on a certain serial ISO- it's a mystery!!!
NoIntro doesn't handle a lot of systems that Redump does so why try to cram Redump's broad scope into NoIntro's simple name mold? Redump has an opportunity to do much better. Why not apply different naming conventions to each system as needed. The serials should absolutely be included in PSX/PS2 names because they are so vital to identifying and working with the disk images. NoIntro doesn't even handle those systems.
On the other Europe vs England topic: If English-only games that were not exclusively distributed in Great Britain should be tagged 'Europe', then why are NTSC games tagged USA when they're distributed in other North and South American countries? Redump's names seem to be an example of too many kooks spoiling the soup. Nobody knows the 'official distribution' region for every game ever released and it's ridiculous to try to base names on that. The only time that's really important is for region protected systems. If someone wants to include a 'Countries Distributed To' section in the database- fine, but why stick that info in the name? For instance, some Japanese PSP games were distributed in mainland Asia with different packaging, but Japanese UMD disks; does that mean those Japanese games should be listed as Asia region?
Not that it has a snowball's chance in Hades of ever happening here, but I think the region tags like 'Europe/USA' should be dropped from the name (but retained as info in the database) and be replaced with a region tag like NTSC/PAL/NTSCJ on the systems where those regions apply. If there's more than one language version for a region then add a language tags to differentiate
i.e.
The World Is Not Enough (PAL) (En)
The World Is Not Enough (PAL) (Sp)
The World Is Not Enough (NTSC)
41 2009-06-18 21:03:35
Re: Title screen name fixes . . . (6 replies, posted in General discussion)
That sounds like an improvement for the names listed in the online database, but it's the names in the dat file that worry me. Those names will trickle out into the general population even if they're wrong and there doesn't seem to be any accurate method for determining a game's name here.
I live in the US and I've been a PSX collector almost since the system came to America. I buy sell and trade games all the time and I handle and talk about games with other collectors regularly. I know what most PSX games are commonly called here and that's almost always the name on the spine. People only tack on something extra (ie A Collection of 30 Games for the Atari 2600) if there are two titles that can be easily confused.
Maybe people don't know, but Playstation spines in the US are extremely standardized. They have the name and the disk's serial# on a black background. They don't have a bunch or art work or logo's like games for other systems or regions do.
Wild Arms 2 is NOT called Wild Arms 2nd Ignition by anyone in the US because that's not its name here. I have serious misgivings about participating in any database that lets a name like that stand; it's like a dictionary that gives the wrong definitions. That's worse than no dictionary at all.
'Activision Classics' is that game's real and full name as seen on the game's package and the maker's (Activision) web site:
http://web.archive.org/web/200008152351 … llivision/
http://www.mobygames.com/game/playstati … rId,13289/
'Wild Arms 2' is that game's real and full name as seen the games package and the maker's (Sony) web site:
http://www.us.playstation.com/PSone/Games/Wild_Arms_2
http://www.mobygames.com/game/playstati … Id,132013/
Why are we calling them a name that their makers don't? I REALLY belive that all PSX (NTSC at least) games should be named exactly what is on the spine. At very least, the names should begin with exactly what's on the spinecard.
42 2009-06-18 07:29:10
Re: Title screen name fixes . . . (6 replies, posted in General discussion)
I actually agree with Haldrie, and don't think title screens should be used as a verbatim name source, but I thought that was redump's policy. I have a proposal: how about we give the name in Sony's Official Playstation Game List precedence over title screen names? Not all games are listed there, but I seriously doubt Sony got the names that are there wrong or incomplete.
Barbie: Gotta Have Games
http://www.us.playstation.com/PSone/Gam … Have_Games
Armorines: Project Swarm
http://www.us.playstation.com/PSone/Gam … ject_Swarm
Wild Arms 2
http://www.us.playstation.com/PSone/Games/Wild_Arms_2
Apocalypse
http://www.us.playstation.com/PSone/Games/Apocalypse
Backstreet Billiards
http://www.us.playstation.com/PSone/Gam … _Billiards
Metal Slug X
http://www.us.playstation.com/PSone/Games/Metal_Slug_X
43 2009-06-18 02:06:19
Topic: Title screen name fixes . . . (6 replies, posted in General discussion)
Since redump uses the title screen names to list games, I'm checking through my collection to compare the names in the database to their title screens. I'm up to 'B' so far and have found several games whose name's in the databse don't match their title screens. If anyone wants to fix them . . .
'Armorines: Project S.W.A.R.M.' http://redump.org/disc/1851/ should be 'Armorines'
'Activision Classics' http://redump.org/disc/7168/ should be 'Activision Classics: A Collection of 30 Games for the Atari 2600'
'Apocalypse' http://redump.org/disc/768/ should be 'Plague Beast Death War Apocalypse'
'Barbie: Gotta Have Games' http://redump.org/disc/7190/ should be 'Gotta Have Games'
'Backstreet Billiards' http://redump.org/disc/6488/ should maybe be 'Backstreet BB Billiards' or 'BB: Backstreet Billiards'
44 2009-06-17 07:27:32
Re: [Poll] PS2 Bond game names! (2 replies, posted in General discussion)
I think I'm in the minority but my opinion is- list them by the name on the spine card because I believe that's the full 'legal' name. If I understand you correctly, that's 'James Bond 007' in this case.
I don't think it's too bad if a 'subtitle' is added to the end, but I really think it's a bad idea to tack something onto the beginning of a name thus changing its alphabetical order- just makes it a bloody pain to find in the list and alienates the database from the rest of the world.
Also, using title screens to name games can NOT be standardized because there's often tons of extra 'junk words' on those screens. Using the spine card name is easily standardized and invariable. Even if the spine name is not what people commonly call a game, at least it people will know how it works.
There are a lot of game 'sets' that are separated because names were changed in different regions; I don't think every James Bond game should have '007' at the beginning just to keep them together alphabetically.
45 2009-06-16 06:38:07
Topic: Anyone else here use RomCenter to scan their images? (0 replies, posted in General discussion)
I figured out RomCenter had an issue with using the dat files here to scan game images that are over 4GB.
Turns out that the utility that imports redump's dat's into RomCenter format didn't support size references
over 32bit (aka4GB). Anyways, the fix is available here from the link "DatUtil v2.46":
http://www.logiqx.com/Tools/DatUtil/
Just replace the datutil.exe in RomCenter with the one in the zip!
46 2009-06-13 19:42:16
Re: Cataloguing game packaging versions? (19 replies, posted in General discussion)
RetroGamer, there are already UPC codes and Ring info in the database; I don't see a difference between that info and 'game contents'. I'm all for a site's purpose staying focused, but preserving package content info seems right in line with preserving hash value info. They are both about checking the integrity of a game compared to it's original condition.
Can you give a little more info on why you think it doesn't fit in here? Like "it goes against redump's purpose statement' or 'it would take up too much of people's time and they wouldn't have any left to dump'.
47 2009-06-12 03:26:21
Re: Cataloguing game packaging versions? (19 replies, posted in General discussion)
Good points 
48 2009-06-11 19:30:43
Re: Cataloguing game packaging versions? (19 replies, posted in General discussion)
Yes, good scans would be wonderful; it just takes a lot of effort to get a good scan so people might be less willing/able to contribute. I'd say making scan 'preferences' would be good (resolution alignment etc), but still accept anything that serves the purpose. If anyone ever submits a better scan, just replace the old one.
There are quite a few free photo hosts available (photobucket etc) so it might be doable without increasing the database site's bandwidth.
49 2009-06-10 18:12:30
Re: Cataloguing game packaging versions? (19 replies, posted in General discussion)
pepsidrinker wrote:
What do you mean like list in the contents this game with a pendant in a pouch like Lunar 2...
Yes, exactly. List the contents and provide scans/pictures that are detailed enough to identify variants, then link the packaging to the dump data for the disks that came in the package.
The purpose being, I see used games sold as 'complete' all the time that are actually missing original contents like maps, registration cards, mini walkthrough books etc. People often have no idea what actually came with games and it gets harder to remember as time goes by.
It could be set up just like dumping: a minimal submission would be a text list of the package contents. A picture or scan of the game's individual parts could be added if the submitter wanted. Once a content list was in the database, people could 'vote' that their copy of the game matched the database's entry, or submit a new variety.
50 2009-06-10 04:12:26
Topic: Cataloguing game packaging versions? (19 replies, posted in General discussion)
I was just wondering if anyone here has ever considered creating/extending a database to catalogue game package contents, manual/cover versions etc? Not for the purpose of replacement documents, but solely to record existing versions.
It's hard to figure out what originally came with a game and it will just get harder as time goes by so I think such a database would be helpful.