Recently the issue of prototypes in various disc formats has come up and this is something that has been bothering for a long while now: what Sega disc prototypes do we have rips of and in what format? I know drx used BIN/CUE for the Sonic CD 920 prototype but that's about it... Do we know the source of some of these dumps, or if they were altered in any way? This request is not limited to consoles: disc-based arcade prototypes are also welcome (it'd be interesting to see a Laserdisc prototype =P ). Thanks.
I'll list what I know. Sonic CD Prototype 510 ripped by "Sega Extreme" (from Brazil?) format: ISO + 128kbps Xing MP3 [Xing is a rather bad encoder which makes this all the worse.] Prototype 712 ripped by: I don't know for sure. According to SOST it could be Stealth, and SonAR says it could be Borisz. (I checked on Underground-Gamer and did not find useful identification.) A BIN/CUE exists, but for a long time ISO/MP3 was tossed around. Prototype 806 ripped by: drx BIN/CUE Prototype 920 ripped by: recently by drx (or his associates), previously see 712 drx gave us BIN/CUE, but before that see 712. Anything else This is a quick search of my personal collection: Saturn - Earthworm Jim 2 (Beta) (U) BIN/CUE Saturn - NiGHTS into Dreams 1996 E3 Beta BIN/CUE Saturn - Duke Nukem 3D (Review Prototype - Sep 18, 1997) BIN/CUE Saturn - Judgement Force [SoR4] (Prototype - Nov 26, 1996) (hidden-palace.org) BIN/CUE Shade released some Sega CD protos in ISO/MP3. I'm fairly certain all the Mega CD and Saturn protos that Hidden-Palace has released are in BIN/CUE. It would be worthwhile to look into the TOSEC and redump.org collections to see if any protos are included in their databases.
Tosec-iso can't have prototypes because of the "every disc must be ripped twice" rule. These discs are unique copies, it's rare enough to get one of them, let alone two exactly same copies. Redump.org may have some, but they probably also have a bunch of demo discs labeled as alpha. You shouldn't trust them, they are only in it for the glory. A copy of Sonic cd 712 was owned by both Pachuka and Stealth, Pachuka ripped his copy in bin/cue, twice. Both had some small problems in the cd audio, the latter rerip had more. It's the first rip that gets around on the net (I hope). There are DOZENS more sega cd prototypes. Pachuka used to collect them, both discs and stuff from the net. I'm sure that most of them are easily available, but finding out who ripped what would be a challenge at the least, but more likely impossible. Old as heck list of some: http://www.sonic-cult.org/genesite/beta/index.html A lot more may have been dumped since. I dunno. The stuff released by drx are all bin/cue I think. Except for a huge bunch of saturn protos released in 2010 May, which were all dumped with the redump.org method and they are full of errors (go figure). There's a list of released Saturn prototypes here: http://www.satakore.com/forum/viewtopic.php?f=11&t=21 A bunch of discs were released but turned out as retail copies, and Yakumo at assemblergames keeps uploading 5$ demo discs as SUPER RARE ALPHA discs... Dreamcast stuff is less common. I think we have Fighting Vipers 2, Shenmue (almost-finished US localization), Rez, Propeller Arena, and Half-life, plus the Sonic Advance 1-2 trials.
I'm not a fan of "fixing" prototypes, but in this case the audio rip could be just compared with the final version's to see if the only differences are those errors that happened during ripping, in which case they could be fixed. Because the data track has been verified to be correct, right?
IDK; all we know is that the games work =P I don't feel bad for the prototypes from days long gone that were uploaded as ISO/MP3 though — in the 56k days anything else was unrealistic :/ What exactly is the redump method?
This can't necessarily be done for 712 because it does not match the final's audio. The tracks do not fade out, and it still has the 510 title screen theme (used in Megamix).
In that case something might be possible to do with the other existant 712 rip, if the errors don't happen to be in the same places.
Using 26 different applications and a dozen manual fixes to correct a 4-byte shift in the audio data. I'm exaggerating of course, but the instructions are stupid and confusing enough that people can make mistakes or just misinterpret them, which drx did, and now we have some bad dumps of one-of-a-kind discs. The correct solution would've been writing a ripping application that can do all the redump crap on full auto, but actual programming is way beyond the scope of the redump crew - they are just a bunch of balding middle age manchildren living in their moms basement, making a name for themselves on the internet, sort of like a current-decade Cowering. I'm fairly sure the bad dumps by drx are repairable with some skill, but we'd end up with a bunch of doctored images instead of the real deal - all because a bunch of kids who think they are internet hot shots. What he said. If it was possible, I would've done it long time ago anyway. And it's, like, three barely audible pops in the audio.... it may be possible to inject data from the final discs into the identical parts in the music, but again we'd just end up with doctored disc images the "sound like what we THINK they ought to sound as". Who owns these discs today though? I think Pachuka sold his copy, but I don't know what happened with Stealths one.
Unless the rest of the tracks (besides the fade) are byte-per-byte identical. Out of curiosity, what's wrong about those dumps you've mentioned, and which are affected?
Yeah, assuming that the rest of the tracks are identical and don't have something as trivial as a 0.1db difference in volume. And assuming that there are no errors on the other parts which are not identical. And assuming that we can correctly find the first point of difference down to the same byte. So yeah. Errors in the data track. Probably repairable, but I'd rather have a proper bin/cue rip.
Just put both tracks in Hex Workshop and do a file comparison. That will tell if there's any serious difference, and it can also tell when data is the same but has been moved around. I have tried this with other stuff before =P On the dumping method shenanigans: stupid question, but shouldn't dumps also be done with several drives, just in case the firmware of some drive decides to be an asshole with reporting subcodes or something like that, or there's some unusual bug between it and the ripping software, etc.? Also there's the fact some light damage could be such that depending on the quality of the laser it could affect the outcome in some drives but not in others.
Normally yes, but a lot of drives have weaker feature sets so not all of them can rip equally good. Original Plextors are the best though. Multiple reading from different users is/was needed to weed out possible errors and to confirm that a rip is good, but this is only required because there aren't/weren't any ripping applications that specialize in what tosec/redump do. So you need multiple rippers to confirm correct rips, instead of a single proper rip with a proper drive (true Plextor drive) and an accompanying log file that details the ripping process. Most drives can read normal cd data in my experience. Subcodes can be iffy but they can be different even between two passes on the same disc by the same drive: people usually forget that they are there to provide another layer of error correction. Even the smallest scratch or speck of dust can affect that. The main problem is/was the lack or proper ripping application. redump.org is fast becoming obsolete, though.
The point stands though, you'd need different drives to prove the rip is perfect. Which drives are used is a different matter. Normal CD data may work most of the time, but this doesn't work for CD+G since there the subcodes are used to store the graphics data (which is why they're so prone to corruption). If you want to rip the CD+G data then you need to do a perfect rip of the subcodes. Also I recall there was some PC game that used subcodes as a DRM mechanism (can't remember the name though). Eventually became obsolete when users got access to software to rip the entire disc image instead of just copying the files, although at least it had the advantage of being effective (while it lasted) without installing a rootkit (since the subcodes could be read with some functions in the Windows API it seems).
What's replacing redump — Hyperspin? TOSEC? See my idea was to create BIN/CUE 1:1 images of all the discs and post their checksums using something along the lines of no-intro naming — for instance, "Keiou Yuugekitai (Japan) (Rev B)", "Frog Feast (USA) (Unl)", "WWF Rage in the Cage (Europe)" — using multiple drives and copies of the game for verification...
No, you need 1 drive that can rip properly, which would be a true Plextor drive (PX-704 to PX-716, PX-755, PX-760). Other drives are simply inferior when it comes to reading. Yes, and this is already possible. In fact all drives can read subcodes, some just have the read commands not implemented or blocked in firmware. Plextors have the advantage of the D8 read command, which from what I gather is "do whatever the fuck you want", or pretty close. Most just used unrecoverable ECC errors, either in the data track or on a lower level (c1/c2). Normal ripping apps just corrected those with the parity data on the fly, or wrote zeroed out data... so the sectors were readable when ripped, and if the game code queried that sector, it knew that it was running a copy or an original. The PSX used that system too on some games. There may have been a subcode based DRM method as well, though I don't see the point: if some drives can't read subcode, the entire thing wouldn't work! Bin/cue won't work for that because no apps doing bin/cue will apply audio offset correction or mastering offset correction. For your idea of posting 1:1 full-cd rips and collecting their name + checksum: it is already being done, but it's coming along slowly because it needs a lot of testing, and there are thousands of stuff to rip.
They were audio-related subcodes, if I recall correctly. It used an audio API to retrieve the data in the subcodes. Take into account this was back when CD copying was still in early stages - the only thing most people knew to do was just to copy all the files. Of course, when burning a new CD this meant not only a completely new filesystem was generated, but all the subcodes were lost. When users learned to do image rips instead of just copying the files it became effectively useless.
Still doesn't make sense, but I suppose that's because you are going on about something "you recall maybe sorta you've heard somewhere twelve years ago". Edit: nevermind, it makes sense. Q subcodes are CIRC encoded every 16 bytes.
Just need to say that the naming they're using is quite incorrect, because different versions of Mega-CD games aren't called "A" or "B", and they're not even called "revisions", either (although GoodGen is the one to blame here). Also, that game has a different name outside Japan, so that "(Japan)" wouldn't be needed for clarification. =P
