DC2CD

First I was like: what a dick; then I was like, hm, that doesn't sound like him, he's probably joking. Then I was like: xD

Great opportunity to brush up on my C++

 

The TOSEC collection I own has all the games in .cdi format not .gdi.

Is there any automatic tool to convert it?

 

Hmmm... TOSEC is in gdi format afaik. Anyway, this tool is acutally to do the oppposite... It takes a gdi and makes a selfboot cdi out of it... Doing the opposite manually could be possible, but you could not get back the same exact GDI as before it was turned into a cdi... Though i don't get why you would want to convert a cdi to a gdi...

It's like taking a mp3 and converting it to wav, sure it can be done, but it's kinda useless and rather silly, except in specific cases (i.e. burn an audio-cd)...

@iNub, I assumed you'd get it when reading the code

 

Oh, sorry! my bad. I was looking at some old files and I was thinking that they were in cdi format. Tosec is actually in .GDI format.

Crazy Taxi v1.004 (1999)(Sega)(NTSC)(US)[!][10S 51035] (folder)
track01.bin
track02.raw
track03.bin
Crazy Taxi v1.004 (1999)(Sega)(NTSC)(US)[!][10S 51035].gdi

You are right

Could some open source video and audio decoders be added to this tool to down sample some large DC games?
Which software are you using to burn the resulting .cdi?

 

For sfd files demultiplexing (separating audio/video) I don't think there's open source tools, there's certainly not for multiplexing, nor for resampling the adx audio. That said, you can use ffmpeg (newly changed name to avconv) to encode high quality vbr mpeg1 video files that it will be possible to re-mux into a working sfd, using proprietary tools...

It'd be a cool project though to reverse this format (shouldn't be too hard for a programmer used to a/v stuff) and to make a completely open source alternative.

For afs, there's open source tools to mess with them, but to re-encode/re-sample the files you got to use proprietary tools.

FG

 

Automatic downsampling will be added soon-ish, manual downsampling is possible right now (except of course that the tool is NOT COMPLETE and can't build ISOs/BINs/CDIs right now, I can't stress this enough, read my bigger post on the last page for more details). That post was just there to notify people that the project was not dead (or died once, but then was revived under a new name with new code).
Also I am looking for people to test the track extraction part (= the part that's supposed to be working right now) so I can file that part under "done".

I'm not planning on having it output .cdi files, instead I use .bin and .cue that can be burnt with the free ImgBurn under any current Windows version and, using Wine, Linux. I might perhaps add an option for that at a later date but actually I don't see any reason to stick to the old .cdi format; if someone knows of one, let me know!

If you want to try it out for yourself, get either DC2CD (which can output .bin and .cue files but is buggy and won't be continued) or Dreamcatcher (which can NOT output anything yet but isn't/won't be as buggy and will offer far more possibilites).

Oh yeah, as for CDI=>GDI... I don't quite see the point in that, but it should be possible.
Something I've been thinking of adding is a tool to make non-selfbooting old rips into selfbooting rips, I guess that's what you're looking for, but that's about it in regard to old rips.

@-=FamilyGuy=-: took me a sec, but had a good laugh then I'm not much of a coder so it might take me a while to figure out all that C++ gibberish

@atreyu187: Forgot to mention, I took your suggestion about user filelist.txts to heart and added it to my todolist; in the future, you'll be able to just replace the filelist.txt Dreamcatcher creates in <gamedir>\Dreamcatcher\track03 and it'll use that one, maybe I'll add a button or something.

 

As long as you're using MULTISESSION bin/cue it's ok. Though I think only imgburn supports the special cue with multisession data, aka it's not standard in the bin/cue definition. Historically cdi was use because it preserved multisession in a single file, making a lot less of complaints about "How in hell to burn this disc???!?!?!?!!" from leechers.

What tools are you using to downsample? Your own?

FG

 

Yeah, ImgBurn supports those but I too don't know of any other burning tool that would... but since it's free and a great multi purpose tool that most people should have installed anway I think that should do for now.
I might think about adding .cdi support but I had nothing but problems with burning that format under 7 x64 a while ago IIRC, so I decided to not look into it but use .bin/.cue instead.
That has the added benefit that it's pretty easy to create once the .iso is done, only the parity data needs to be added and I even found source code for that on the net. Maybe .cdi is easy like that too, I don't know.
Ah well, maybe I will look into it later but as it stands I'm pretty sure the first "real" release of Dreamcatcher won't have that capability, who cares as long as it works and everyone can use it

As for the downsampling, that's still an unknown; I plan on writing my own tools, but if that proves to be too much of a problem I might resort to just starting external .exes to do that, maybe even use some tools from the SDK.

EDIT: nvm, -=FamiliGuy=-'s post below somehow didn't load.

 

The downside I see is that it can't be tested on an emulator, then people won't know if their disc will work or not once burnt... I actually almost never burn discs, when I do it's only to make sure it works on the real deal prior to letting other people play with it...

For downsampling, if you use the sdk tools don't include them in the released format, ask people to put them in "that" folder. This is for legal issues, the same as why emulators don't have bios pre-included. For downsampling SFD I suggest reading the very good SFD downsampling pack by OVERRiDE. However, it's prettier (and can save some space) to use ffmpeg/avconv to downsample the m1v files with maximum compression at minimum loss.

FG

 

Yeah, the emu thing is a problem... however I think it'd probably be much easier to allow the .bin/.cue format in instead of switching to CDI again, which would (afair) lead to problems burning again... I'm just not sure yet, but thanks for your input! I'll keep thinking about it.

I'll see if I can find that downsampling pack, maybe I already have it lying around somewhere in an unsorted folder... I lost oversight of those a long time ago

Also I've been looking at your code a little now and I think it's pretty similar (except I don't do the VGA/JUE/LBA hacking stuff there but somewhere else), but a few things I don't understand, like why don't you just use the byte @ ip.bin 0x3E to determine whether it's WinCE or not? That is the WinCE flag after all, isn't it?!
And somehow your echelon hack data block is 252 (?) bytes longer than mine, those bytes are at the start of the hack data block; no time to analyze that any further right now, I'll look into it more once iso creation is back in.
The rest seems to be pretty much the same, I haven't checked all of the offsets because I don't use the offsets in the file but those of the echelon hack data block, but I think we're doing the same stuff.

By the way, have you rewritten any of the other binhacking tools (hack3, dahack etc.) or do you have sources for those?
I'm rather confident my implementations are ok but comparing them with other people's would surely help.

 

AFAIK hack# are pretty simple, simple integer replacement, like 45150 -> LBA+150 or a known copy protection command replaced by a "do nothing" 0x0009 0009 iirc. I usually do that stuff by hand, so I haven't made any program for it, but a simple search and replace function with 2 parameters should do the trick. CDDA.exe is a tad more complex, I think I sent you a link explaining it though, I'm not quite sure what it does exactly and it seems to works differently depending on the games, it might have something to do with how game handle GDDA tracks, I usually test wether I need it or not to get rid of the 2 dummy audio tracks but it doesn't always works...

Here's bincon source (in C obviously):

Found it somewhere in the asshole of the internet one and a half eternity ago, I never really understood how in hell that's supposed to make WinCe games work, but I'm no expert in WinCe games either.

I use the first bytes for WinCe recognition because I noticed the first bytes were different, it's equivalent to looking in the bootsector for the flag, except that you can now use a katana bootsector to binhack a WinCe binary. This is an unplanned "feature" though.

My hacked bootstraps are simply dumped from binhack.exe without really caring for trailling or preceding zeroes, this can explain the size difference.

I hope we're doing the same stuff, both our code works at mimicking another one!

Also keep in mind I'm no programmer, I just binhacked a bunch of different stuff and figured out what binhack does then implemented it in C++, kinda learning how to get beyond "Hello world"' in the process, Sizious helped me making it pretty for a sourcecode release (the library mainly). Might not be the best way to do stuff but it works pretty well!

Cheers,

FG

[edit]
It's quite easy to burn cdi, just get padus discjuggler and you're good! Burning it with something else would be problematic. But anybody with half a brain can follow directions to mount it in daemon tools and make an image with any software after...

 

Lol, well where else would you find the good stuff

Alright, if the hack# tools do nothing else I think I'm good.

I actually did it the same way you seem to have done it, just use the original tools and compare output and input, rinse and repeat for 20 games and that was that.

The bincon stuff looks like mine too, I have no idea why but it does seem to work

As for that "learning to program" thing, that's the same for me too, this is one of my first projects... I just figured, why should I waste time writing stupid example progs from C# books when I can (try to) write an AIO selfbooting tool instead...

The only thing that baffles me is the cdda.exe link you sent me (?), I can't find it, do you still have it on hand?
The weird thing is, I believe cdda.exe just replaces 92 bytes, 8 of which were variable per game iirc - however every game I do without cdda.exe works (with or without CDDA on the disc, doesn't seem to matter), but every game I use it with doesn't work...

And what is it with those 2 dummy audio tracks you keep mentioning? I have no idea what you mean.
Wait, I think I got it, do you mean in a 5 track game track02.raw and track04.raw?

Again: thanks for your help!

EDIT: I completely overlooked your post about Sizious releasing the sources for mds4dc and cdi4dc, apparently he uses iso files as a starting point too so maybe it's easier to implement than I thought, thanks to both of you!

 

hey iNub, I was reading your previews posts.
Where did you find 90-100min CD-R to order?

They just don't exist here in Brazil.

 

@veggav Check this: http://www.dealextreme.com/p/ris-99...gh-capacity-cd-r-50-pack-spindle-4478?item=10 ; shipping is slow but they'll arrive eventually and they're good qualitya nd cheap price. It's the pack i got and it works well for me. Some people got mixed results, but even if 1 out of 2 wouldn't works it'd still be cheap for 25 99min cd-r from where I stand. Be careful though as not every burner, at all, are compatible with that.

@iNub
By the asshole of the internet I just meant I really don't know where I found this, maybe IRC? it was over 10 years ago so I don't quite know now.

Of course you won't make any kind of cd image without starting with an iso file... every cd image format is base on iso. CDDA.exe is used to remove the requirement for two dummy audio tracks at the beggining of a cdda/data selfboot game. The way most games works for playing GDDA tracks is, like a cd-player, using track numbers. But a GDDA gd-rom structure is usually like:

Session1:
- Track01 : Data (release/extra files)
- Track02 : Audio ("This disc is for Sega Dreamcast", or other witty stuff)

Session2:
- Track03 : Data (HD TOC + files if not a gdda disc)
- Track04 to Track(N-1) : Audio (GD-DA music for the game)
- TrackN : The actual game data referenced in the Track03 TOC (merged with Track03 is there's no GD-DA)

So you see that in order to make a game play the right songs, you need 3 tracks before the music tracks, if the game references the tracks by their number. CDDA.exe is supposed to shift the track reference (or equivalent) so the first or second track is read instead of Track04 and so on. I'm not quite sure if you still require a dummy 1st track, for selfboot it's useless, but maybe the first track can't be considered GD-DA by design. If you don't apply cdda.exe and still use one dummy track, everything should works, except the right songs won't play at the right time, and maybe (?) it could create a problem if it can't find a track (track# > N), but I've yet to find a DC game that has problem if stripped of GD-DA tracks.

Here's the info I talked about: http://www.dreamwell.pwp.blueyonder.co.uk/dcselfboot/cdmage/ipbin/dclinux/Romloader/Makenx/cdda.htm

Usage exemple: http://www.dreamwell.pwp.blueyonder.co.uk/dcselfboot/cdmage/ipbin/dclinux/Romloader/Makenx/kcdda.htm


This guy's website is a goldmine just found back the "null" command to be rather "0x9600 0000".

FG

[edit]
After re-reading the usage exemple, it seems like cdda.exe makes it so you don't need any dummy tracks, you just use the GD-DA tracks as the 1st session for mil-cd exploit, and cdda.exe shifts the references so you don't need to start the music at track04, but at track01 instead. If i understand correctly, but it's been 7 years (God now I feel oldschool) since I've made a game with cdda (Toy Commander FTW! which is also a fucking WinCe iirc).

 

That's very strange...

It's been a while since I've actually burnt any games but I'd swear I've compared the audio tracks played on the originals with those that were played on the copies, and I'm sure they were the same without using cdda.exe... weird.

I'll have to look into this again, you're a great resource for this stuff

As for the iso format being used as the base for all other disc image format, didn't know that, that might make all of this a lot easier and give me (and by that the users) more options for the output. Good to know.

EDIT: I even once used Q3 like in the example you posted and I remember using the "change audio track" option in the game until I've heard all tracks, and all of them were alright. WTF...

The only thing I could think of is that maybe that "fix hd toc" thing that I enabled by default might have made enough changes to get it to work, IIRC I wrote that to fix the track offsets including audio tracks... again, I'll have to check into that some time.

 

You're sure the track numbers and titles weren't shifted? Like it's supposed to be TrackX but it's rather Track((X+4) modulo(N))?

If you followed a tutorial at the time telling you to put 3 dummy tracks, then it sure played the right tracks, cdda.exe is to save space by removing the dummies.

FG

 

No I used DC2CD.
Weird, but figuring that out is just one more addition to my todolist

 

You should do the same game three times: one plain without cdda.exe, one with your hd toc fix, one with cdda.exe. Then you could eliminate what works and what don't works!

Can you explain what is your HD toc fix? (Rebuilding the hd toc from ip.bin to match audio tracks data?) And why you're doing it? AFAIK this hd toc int he ip.bin isn't really used in mil-cd, but I could be wrong, maybe you acheived the same result as cdda.exe with a simpler approach!

 

That would be sorta cool

fixHdToc does the following:

It just fixes the start of the second session, and IIRC (it's been a while) the other offsets (for the audio tracks) are calculated as <audio track position> - <datasessionstart>, i.e. if it begins at 100000 it would be 55000 here for original games.

Plus, it sets the rest of the HDTOC to 0xFF because the audio tracks are not in the HD session anymore... or so I think I reasoned.

I'll definitely have to test this again, right now I'm a little occupied with other stuff but I'll make sure to check this asap.

Who knows, maybe DC2CD did fuck up the audio tracks, but it's strange that I seem to remember it worked for me an atreyu187 also said it worked for him... oh well, we'll see

I'll be releasing the complete sources sooner or later, and if needed, my notes as well. But until then there's still a lot of work to be done, mainly because I forgot half of what I once knew in the meantime.

 

I can't stress how much I hate C# syntax and readability. Python for the win, or c++ if you want compiled stuff but seriously, even bat files/bash are more readable than C#...