Hard to say really. But I suppose best bet is Sonic Stage. Though I am testing somthing I found. Tell you what the results are.

Though Strobe might do this I will find a utility. I thought it was for the PS2 format but was really PSP audio conversion I was looking at. So I'm trying to find that. Alright! I got somthing you might like. :) ATRAC3 Audio Codec This is a codec that would allow the conversion from and to the PSP s...

Likely because it exceeds 256kbs. There's a 256kb limit.

Too bad unlike the TrID tool it isn't extendable. Jaeder Naub is with it's custom plugin support of which I'm trying to figure out for a few formats that I intend to test.

It has been confirmed to be a compression. Also, there exists a debugging version of DosBox that lists the commands and exact files being accessed. It is available on VOGONs. Could this be used to find the means of decompression or does it not? Here's an example dump I made. Would this be useful? Or...

Well I can't write tools myself and I'm only new to disassembling and as for debugging...not sure. Doesn't seem it'd work on things ran under DosBox (I have two games that require this that have compression schemes) so I wouldn't know at my level. Hence partially why I am going to college. Oh wait. ...

I use megaupload now.

Well, it doesn't have to be re-encrypted/encoded to work. :) This "j^i" stuff marks both ends of the files cause each file has thos 7 0xCDs at its end. So this must be a suffix that is added after encryption. That seems to me that it is "END" marking the end of the datafile. But ...

Awsome. I figured it wouldn't be difficult, but hm... now comes the tricky part, if it works ingame. I guess there is only one way to figure that. Edit: It looks very structured like I'd expect. Everything is understandable to me in these files. The last bytes though do seem confusing. Like... "...

Obviously I'm not. Just got a disassembler a few days ago.

Near the Bottom is Two Demos]

There are a couple of demos there.

Hm? Specify what you mean, I don't speak the full language yet.

Yes, the files are encoded. I looked through the executable and discovered this (see image). Is that an alogarithm for decodeing the files (right above it)?

Am I on the right track? Any ideas?

Here they are, these are the two datafiles that are not encrypted/encoded.

As I said, the "**ENC**" could be a tag telling the program that it is encoded/encrypted.

If it was not it would have looked much like it's relative DAT files which were plain text.

In looking through my games I noted that Return Fire 2 makes no effort to use datafles but instead encrypts the script files objfxscr.dat and RFIREII.dat I know they are encrypted because... well... gee... it kinda says it in the header XD "**ENC**" dead giveaway. This is in both files. Ap...