POP1 Music extraction thread

ChrML · Post by **ChrML** » May 26th, 2003, 7:47 pm

I'm ChrML, only that I couldn't get logged into this forum.
Finally (after 30 min more researching) I got the midi files in MIDISND1.DAT extracted. Actually, it was really simple. Getting them back into the file is not hard either. Just paste it back over the file in a hex editor, and change the filesize DWORD on the top to the new size. Here are all midi files in MIDISND1.DAT:

[url]http:\\www.thps3cu.com\files\MIDISND1.zip[/url]

I'll create an editor for it later. Enjoy these files in the mean time.

Post by **poirot** » May 26th, 2003, 10:38 pm

Really cool! If you do an editor, please use pascal or c, so we can make a TPU or LIB unit and include them in both: the PV4 editor and the Sound editor (I'll find the way).

Had you studied the internal MID format to find the way to convert them into .MID?

That's really cool!!!

tammojan · Post by **tammojan** » May 27th, 2003, 9:31 am

Oh, maybe I should have mentioned this earlier: I got a mail, stating how to crack the "digisnd.dat". It is at least readable as raw data (for example in coolplayer). It shouldn't be too hard to crack this one too

Post by **poirot** » May 27th, 2003, 6:04 pm

Cool! so

Digisnd?.dat are wav
Midisnd?.dat are mid

Can you explain a bit more about the file separators?

ChrML · Post by **ChrML** » May 28th, 2003, 7:39 am

Actually, it was real simple to extract them, since all mid files starts with the same two bytes. That makes it easy as hell. I'll make an editor, but shall I compile it as a DLL? I think a DLL is best. Are you able to get a DLL into the princed.exe file?

tammojan · Post by **tammojan** » May 28th, 2003, 9:37 am

Well, I think Princed will eventually be open source, so it'd be nice if you could just send the C++ - source.

But one question: how are the midi-files separated? Are the two bytes you were talking about the real separators? And is the file size indicated in the beginning of the file, or are there other checksums? I'm asking this because I'm cracking the DISISND*.DAT files, and there may be some same mechanisms.

Post by **poirot** » May 28th, 2003, 1:53 pm

For Tammo Jan: He said DLL because he uses Delphi.

For ChrML: If you make a dll, please send the sources also, so we can translate the language into C.

ChrML · Post by **ChrML** » May 28th, 2003, 3:20 pm

I checked, and there aren't any similar file seperators in DIGISND1.DAT. Why not just make a wav file, and search for the first bytes in it?

TRIDENT · Post by **TRIDENT** » May 28th, 2003, 3:38 pm

Within midisnd1.dat & midisnd2.dat
the individual midi's start the the letters
MThd
so all you need to do is use a program like ultra edit
and select from the first MThd through till JUST BEFORE the next midi begins (before the next MThd) and put it in a separate file
and rename it *.mid.

MThd**********CODE******MThd************
...........................................|separate here
..........................................*next midi starts*
and so on

OH and thanks ChrML for letting us know.
I extracted the midi's from midisnd2.dat for my amusment

ChrML · Post by **ChrML** » May 28th, 2003, 7:45 pm

That's just what I did on MIDISND1.DAT. Extract MIDISND2.DAT you, since I'm to lazy, lol. I'll code an extractor, and a rebuilder later.

Guest · Post by **Guest** » May 29th, 2003, 1:18 pm

Mt32snd?.dat are also midi's

Post by **poirot** » May 29th, 2003, 2:32 pm

what game are you talking about?

tammojan · Post by **tammojan** » May 29th, 2003, 7:11 pm

I think he's talking about Prince of Persia

In some newer versions, there are special midi's included for the Roland MT.

ChrML · Post by **ChrML** » May 30th, 2003, 6:53 pm

OK, now I've created a .DAT compiler for midi files, but...
Now I have a biiiig problem. The new files that get's into the .DAT must be at the same filesize. The solutions are:
1) Must me kept at the same size (nearly impossible)
2)We must find a way to change the pointer (the pointer isn't in the .dat)

Post by **poirot** » May 30th, 2003, 9:08 pm

You are ignoring the first 8 bytes in the file, they are very important, and the validation is there.

The first 2 bytes are a dword value x
The second 2 bytes are allways 0
The third group of 2 bytes in a dword value y

where x+y=size of the file!!!!

Take a look:
midisnd2:
B6 47 00 00 32 00 8F 02
x= (B6 47) = 18358
y= (32 00) = 50
x+y=18408

midisnd1:
16 24 00 00 82 00 34 02
x= (16 24) = 9238
y= (82 00) = 130
x+y=9368

I have to study a bit more about the fourth group of 2 bytes, but I think the dword value it has something to do with the next mid size.

Knowing that you can keep on working in the compressor with out any problem