First the good ones. The complete pack I released before "quitting" are still available in several places, and this is awesome. Also, I found references of DCRES in several forums with different languages, and that's very satisfying.
Now the bad ones. I found comments of different people saying that I copied work from others and did not give credit, and that's a lie.
Before answering to that, I would like to present some facts:
- I NEVER USED WORK FROM OTHERS WITHOUT MENTIONING IT IN THE README FILE. Of course there is a chance I forgot to mention someone by mistake, but I doubt it.
- ALL the game hacking in my releases were done using one or more of these:
- Famous dahack/binhack method.
- Hacking recipes for known protections found on the internet.
- 45000 LBA trick.
- Hex edit ISO to change size of protection files.
- Simple search/replace hacking of binaries (e.g.: changing sample rate of raw music files).
- Binary comparisson of other groups' releases, and in these cases THE GROUPS WERE CREDITED IN THE README FILE.
- Use of other groups' releases binaries, and in these cases THE GROUPS WERE CREDITED IN THE README FILE.
I never hacked binaries and protections in the assembly level, AND NEVER CLAIMED TO HAVE DONE IT. I have neither the knowledge, nor the patience to do that.
- DCRES work was not a simple applying dummy files in games. I had an obsession for quality. I encoded things with the highest quality I could, reverse engineered game formats, wrote tools, optimized file order the most I could (many hours, hundreds of CD-Rs...). The result for most games was great, and much better than the releases of the time.
Facts presented, I would like to show you some comments I found (from other forums!), and some proofs that they are lies.
According the ReviveDC guys, Tux actually lied about some of his rips and stole work from others. Check out the NFOs on their releases for more info.
This is true. I'll go into some more detail here. I'm the head of the ReviveDC Project.
Basically, Tux's claims of sourcing GDIs and always doing his own work were very much…not true 99% of the time. Occasionally in his NFOs he would admit to taking Echelon's files, but most of the time he didn't.
Off the top of my head, here's releases he took work from:
Dino Crisis: The scene release downsampled video in order to fit a 75 minute CD-R. CRCs match between the scene release and Tux's. Dino Crisis fits perfectly to a 700mb CD-R with no downsampling. Claimed to have downsampled himself.
These steps can be reproduced by anyone (commands done in cygwin). Extract GDI files ("Dino Crisis v1.000 (2000)(Capcom)(NTSC)(US)[!]"), and my release files. Comparing both:
Code: Select all
$ md5sum gdifiles/* | sed 's/gdifiles//' > /tmp/1.txt; md5sum myfiles/* | sed 's/myfiles//' > /tmp/2.txt; diff /tmp/1.txt /tmp/2.txt
1c1
< 0afd6cd9661d8c3234520862c3dd4837 */1ST_READ.BIN
---
> 0a680e840abd79eebe2ffc80d418f597 */1ST_READ.BIN
4c4
< 766faa6524d687009517a2eb9b463198 */BGM_22.AFS
---
> c5c68b4366130c39cadf4a1d3171b21c */BGM_22.AFS
95a96
> 52ac0cfdc5f941275baa6bb8b0fb0103 */DUMMY.DAT
113a115
> 434bc3ef129883aae2d27e1f029bac25 */IP.BIN
146c148
< f14dc3ac94d066a6c7f799bd009911eb */ST_ROLL.SFD
---
> 52ce6194cbc50eea7098830415512a0c */ST_ROLL.SFD
299c301
< 9d7dac6758726c41eee8b2af1c5a093b */XA.AFS
---
> 2543ec3a047fd0b52cc86c549e89b78e */XA.AFS
Deleting my dummy file, and applying Echelon's dc_afsshrink.exe:
Code: Select all
$ md5sum gdifiles/* | sed 's/gdifiles//' > /tmp/1.txt; md5sum myfiles/* | sed 's/myfiles//' > /tmp/2.txt; diff /tmp/1.txt /tmp/2.txt
1c1
< 0afd6cd9661d8c3234520862c3dd4837 */1ST_READ.BIN
---
> 0a680e840abd79eebe2ffc80d418f597 */1ST_READ.BIN
146c146
< f14dc3ac94d066a6c7f799bd009911eb */ST_ROLL.SFD
---
> 52ce6194cbc50eea7098830415512a0c */ST_ROLL.SFD
All videos except ST_ROLL.SFD are equal, so CRCs MATCHES WITH CRCs OF SCENE RELEASE BECAUSE THEY ARE THE SAME FILES OF GDI!
ST_ROLL.SFD was NOT downsampled for 75min CD-R! It was downsampled so it could be played in the inner part of the disc! As a rule of thumb, all streaming
data goes in the beggining of the disc, so data that actually impacts on loading time goes to the end of the disc. If a video has a bitrate too high, reading speed at the inner part of the disc is not enough for the streaming, and video will keep freezing. THIS IS STATED IN MY README FILE.
I don't keep oRARs anymore, so if someone could md5sum Kalisto's ST_ROLL.SFD please post here. MD5SUM WILL BE DIFFERENT BECAUSE I DOWNSAMPLED THE VIDEO MYSELF.
As a last point, please check the binary diffs of GDI's main binary and my release's:
Code: Select all
$ cmp -l gdifiles/1st_read.bin myfiles/1st_read.bin | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
0014EFA1 5E 96
0014EFA2 B0 00
0014F36D 5E 96
0014F36E B0 00
0019956D 6E 5C
0019956E B0 2E
This is dahack.exe and binhack.exe for 11702 LBA, something that anyone can do without having to copy any releases' binaries.
Record of Lodoss War: This was outright thievery. This game has some seriously mean copy protection in it. We missed it on the ReviveDC release and had to nuke it and we still haven't cracked it. He claimed that the PAL version didn't have the protection and that he took his files from GDI, but he really took the files from another scene release and just said it was his.
Nope, PAL release really doesn't have protection.
Please check the diff of GDI's ("Record of Lodoss War v1.001 (2000)(ESP - Swing!)(PAL)[!]") main binary (1NOSDC.BIN) and my releases':
Code: Select all
$ cmp -l gdi.bin mine.bin | gawk '{printf "%08X %02X %02X\n", $1, strtonum(0$2), strtonum(0$3)}'
0019F9C1 5E 96
0019F9C2 B0 00
001BBC65 5E 96
001BBC66 B0 00
001BBC71 5E 96
001BBC72 B0 00
001BBC7D 5E 96
001BBC7E B0 00
00298BAD 5E 96
00298BAE B0 00
00298F79 5E 96
00298F7A B0 00
0033CF21 6E 05
0033CF22 B0 27
0033CF23 00 01
This is dahack.exe and binhack.exe for whatever LBA the second session starts. Please check it yourself!
Resident Evil 3: Nemesis: This was just sloppy work. He took all of Echelon's audio (and didn't mention he did), then dummied the game out by 85mb. He could've easily spread the downsample over the audio and done better than Echelon's audio. We also have better audio encoders now.
This is his opinion of my work, and I respect it. RE3 was not a very good release... in my complete pack, I marked some releases as high quality, and RE3 is not one of them.
But about not giving credits on Echelon's work, I will just copy/paste a piece of DCRES release file:
Code: Select all
---------------------------------
Resident Evil 3: Nemesis (NTSC-U)
---------------------------------
Ripped: Nothing.
Downsampled: Ambient sounds monoized; videos re-encoded.
Source: Echelon's release (oRARs) and european GD dump.
After finally getting the european GDI of this game, I spent a lot of time trying to make it work.
Unfortunately I couldn't because this game has some kind of protection. Even the LBA 45000 trick
didn't work. Well, so I got Echelon's release. Their release is of the american version, but
fortunately the files are pratically the same of the european. So, using their release as base, I
restaured the original media (stereo song and untouched video), and shrinking the AFS files space
was enough.
Did I try to hide I took the files from Echelon?
Silver: Same story as Dino Crisis. Scene was done for 75, the game fits fine on 80.
If his theory was correct, than the size of my release's files would be 650mb. And if you check:
Code: Select all
$ du -ch | grep total
684M total
The movies were downsampled because they had to. I don't have the oRARs, but if anyone could md5sum them for me...
The downsampled videos are:
Code: Select all
$ md5sum gdifiles/MOVIES/* | sed 's/gdifiles//' > /tmp/1.txt; md5sum myfiles/MOVIES/* | sed 's/myfiles//' > /tmp/2.txt; diff /tmp/1.txt /tmp/2.txt
6,7c6,7
< 15c70b974e9bffe863ba766bc048f37e */MOVIES/OUT2.SFD
< 5b01c766e88fe35209e66a410adac904 */MOVIES/OUTCOMP.SFD
---
> 003d585f57744c81ac6fd377b9e95993 */MOVIES/OUT2.SFD
> 0116055e3d350e9706a19463d6fb5eda */MOVIES/OUTCOMP.SFD
My releases's md5sum are the last ones.
I know there's some other games we've caught him on. His optimizing was sometimes… not so optimized as well. For example, Resident Evil 2 is a WinCE game so
it has an EXE file it runs. Somehow Tux missed this, and the EXE file was in the innermost portion of the disc. He said he was having trouble optimizing it because the laser kept returning to the inner area of the disc… but he could've just moved out the EXE.
I did not... look at the LBA in the screenshot attached to this topic...
atreyu187 told me his Crazy Taxi was also taken from another scene group, which is kind of ironic considering all of his selfbooting guides focus on Crazy Taxi.
Yeap, that's correct. It was taken from Kalisto, as stated in the readme file. This was my first release, and it was made in a time I didn't even know how to extract a GDI!
I thought about re-releasing it later using GDI files, but it wouldn't bring any benefit! The only difference would be gaining like 2mb shrinking AFS files, and that's not a good reason.
He did some other pointless things like downsampling just because he thought the video bitrate was too high. I have no idea why the hell this would be done.
He did this to several games when the video plays without lagging as it is and would have fit the disc.
I already explained the reason for that. And I didn't *think*, I *tested* it. I could always put the videos with high bitrates at the end of the disc, but it would impact the loading times. I always tried to find the most balanced option.
If you don't believe me, try SW: Jedi Power Battles. Try putting the .SFD at the beggining of the disc and playing the game.
For ReviveDC we only source from GDIs and we dump from GD-ROMs where possible. We don't do any pointless downsampling, and we really dig into the games to save room where we can. For example, on our Resident Evil 3 release we found we could kill 100mb of data from the game by hardlinking. This let us leave the audio untouched and putting the video into VBR there was no noticeable quality loss, versus the DCRes version where the audio was monoed and videos downsampled. We're basically what DCRes claimed to be, but we're actually doing it.
That's nice. I didn't know how to re-link redundant files at the time.
Fun fact: I originally started ReviveDC on SOR in May of 2008, before DCRes. DCRes came along a few months after with kind of a similar name.
Ehhh... I didn't... copy... your name... LOL
Oh, one other thing we've got on DCRes; 45000 data/data format. This mimics the LBA of the original GD-ROM and is generally a more reliable selfboot format.
Some Dreamcasts don't play audio/data 11702, which is what the DCRes releases are.
The most recent releases had the second session starting as far as I could, sometimes after dummy data or streaming data. The reason is that I found that some games made the reader go back to the start of second session, even if there was no data there. So putting the second session near the not-streaming files would make the reader move less.
The only advantage on using 45000 LBA is making hacking easier. Really.
For the information (taken http://dcemulation.org/?title=A_History ... _Dreamcast <- see, I give credit :p):
"Some rare, late-model US Dreamcasts and some special edition Japanese Dreamcasts are crippled and have the code for booting MIL-CDs removed from their BIOS, meaning that there is no way to play backups or unofficial software on the system without some sort of hardware modification (or an as-of-yet undiscovered additional backdoor). No PAL Dreamcasts are crippled in this manner. It commonly believed that changing the track type of the first session of a MIL-CD (from the typical audio/data to data/data) will allow it to be played on these crippled Dreamcasts, but this is a myth--the code for booting MIL-CDs is completely not present in the hardware. "
------------
I wasted A LOT of hours on DCRES, trying to make the best for Dreamcast fans like me, and it's really sad to see these lies being spread around.
I would happy to answer / prove any other "accusation". Please just let me know.
And sorry for the long message. I know this kind of stuff is useless now that we have GDEMU and USB-GD, but I really felt like defending myself.
