- Status
Since the (E) version has some IE2 assets, maybe someone can do a Menu/Item/Skill translation like what happened with Pokemon. Just transfer everything over that has a match in the sequel and do a translation of any new items/Skills/Names. Anybody whose interested in translating the story can use the menu translation as a base.
- Joined
- Oct 13, 2007
- Messages
- 1,008
- Trophies
- 1
- Age
- 37
- Location
- Chile
- Website
- www.power-ups.net
- XP
- 596
- Country
Now the problem is the script.
Reading in the older translation thread of IE Jp, they said that the script is compressed and that's the reason that mcht.pkb and evet.pkb are so weird inside with a hex editor.
We need a way to uncompress that files, maybe with a LZ77 compressor or something like that.
Edit: CrystalTile2 can, but i cannot uncompress all files, i need somebody that will give me a help in this case.
Reading in the older translation thread of IE Jp, they said that the script is compressed and that's the reason that mcht.pkb and evet.pkb are so weird inside with a hex editor.
We need a way to uncompress that files, maybe with a LZ77 compressor or something like that.
Edit: CrystalTile2 can, but i cannot uncompress all files, i need somebody that will give me a help in this case.
- Joined
- Mar 15, 2009
- Messages
- 373
- Trophies
- 0
- Age
- 37
- Location
- Greece, Thessaloniki
- Website
- Visit site
- XP
- 261
- Country
GeekyGuy said:
Now-days even a single Save is considered as Copyright by Nintendo....
So yeah, a lot of us are illigal :/
To save this getting buried in PMs I will post it here. Apologies for my "thought process" type pulling apart of the file rather than a straight up format assessment.
If you have the rom evet.pkb and mcht.pkb seem to be the files of choice.
10 at the start of the file usually indicates type 10 compression (one of the traditional DS compression schemes), I fired it through http://code.google.com/p/dsdecmp/ and it spat out the header sections of each file in something resembling a traditional DS header
It started out with the true length of the header in the case of mcht it had 78 which was the end of the last name in the small sub entry.
Decoding from the next 10 marking did little (I think it might have been a coincidence) other than stall the program.
Decoding from the one after that netted a more complete file map (the first value is 6801 or read as the DS would 0168 which is the end of the section again.
Decoding from the one after that gained me a small text 13 kb dump (largely in ASCII- no unicode which is odd for a game like this unless it uses proper unicode and not the U16 (forced 16 bit) most of us see) and it ends with something similar to that old header.
J04.SAD gmdn_v00 and the like. The text itself seems to be a flawless dump (only the new line marker and what appear to be variable (you have X money and the like) the text might be using prevent it from being a standard text file- not traces of a bad decompression (if you force it most LZ decompressors will decode any other LZ but it will not be a nice result). No text pointers though and it starts with 2430 (3024 as the DS might read it) which is the end of the whole decompressed section (including the odd header thing). I sense I am not here to pull apart a text format and as the table is simple enough so that is left for others to ponder.
Some of the things at the end of the initial mcht.pkb file are seemingly not compressed as well.
Looking at some of the headers more closely, between the names exists other data. Looking my second successful decompression
0000 5401 0200 1400 0000 comes before J04.SAD and
0000 5701 0200 1400 0000 comes before gmdn_v00
Traditionally it seems lengths and the like come before names. There are also some 0000's before and after each of those, you can usually ignore them but occasionally if you are dealing with big files they are important to keep proper locations and file sizes* and some things use them for other useful bits of data (a flag to say whether a file is compressed for instance).
0154 and 0157 are fairly obvious guesses for things although what there are is up in the air at this point (sizes maybe)
*kind of like how I reversed 6801 when just starting to pull things apart. A minute ago- a bigger file might have actually used a later byte or two and thus I would have got it wrong and if something like 6801 1000 was written I would have mistakenly decoded it as 0168 0010 when I needed to write 0010 0168
The 0200 1400 part appears to be repeated throughout the header part although as they are all the same sort of filename (and presumably format) that is not surprising. They might be compression flags or flags to tell the decompressor or game where to look for choice bits of data on the file- the only part in which they change is for the Kicker= %d and "GK " (four spaces maybe used as padding- a 6 character limit/fixed length string perhaps?) part in which they are 0100 1400. This is less important for translation though if you are making a game enhancement or using the engine to build another game you will almost certainly need to figure it out.
In order from the start the "size" values list as
EE00
F000
5701
5901
6201
6501
6d01
7001
8001
8301
8E01
9101
9901
9C01
A701
AA01
B101
B401
The "counting up in 3" parts some of that list seems to enjoy I can not ignore- it makes it considerably less likely to be a size value (file sizes neatly going up in values of 3- not likely unless it is a simple padded/restricted affair) and it only going up 3 at a time makes it less likely to be a direct pointer value (file sizes of 3- equally unlikely if not pointless- you would make a whole file and 3 is not a nice length to feed a processor) so it is more likely a reference value (games do not need nice ASCII names- short numbers will do just as well if not better) or a pointer to a pointer (there might be some other table somewhere with. and the other thing I do not like about calling it size is that
J04.SAD is repeated a few times and then J05.SAD is used. Not sure what this means although each instance of J04.SAD has its own "reference" value.
Now this 13K dump makes life a bit more difficult as I can no longer just scroll down and pick out the next file and just searching for 10 again is not likely to be that effective. Compressing the file (using codec LZSS- http://gbatemp.net/index.php?showtopic=274472&hl= ) compresses the file down to about 6KB (not bad for an ASCII file) or more importantly 17CB long.
17CB in the mcht has nothing much but on the screen at about 1500 is fluff.y (obviously a compressed version of fluffy), scrolling through the script and keeping an eye on the new compressed script that is right near the end though.
Sure enough at 188B there is a g.mdn part (remember the odd header like thing at the end of the text dump)
At 18B0 is another 10 flag, deleting all that came before it and firing the new file through the dsdecmp again
A nice 7KB file results. ASCII like before, starts with 8419, ends at 1988 and the 1984 part is the tail end of the %d (it is another repeat of the header part at the end by the way).
On the header repeats though this file has header like data interspersed through the file (more towards the end though but it starts with a file name like thing)- these extractions have subfiles as well - the initial pkb files are archives, these contain files which are also archives?
Far from unheard of in the DS world (NARC files do it all the time, SDAT or more accurately the sample files are built for it) and there are entire roms that layer custom file systems on top of the nitrofs (the thing all known roms use and we use stuff like nstool/ndsts/nitro explorer/crystaltile2 to pull apart). Speaking of crystaltile2 I should really fire these files through the compression search of that program.
Also our old friend 0200 1400 returns.
10D0 marks what I want to call the second subfile (or more accurately the start of the "J04.SAD" string. 114C the next. 11EC the one after that. 1418 the one after that. I would not place too much stock in their actual values/locations (if nothing else because we still do not know if they are indeed true file starts - they do however appear at fixed points relative to others- how many times do you latch onto 00 as the end of a line where in fact the line ends a fixed distance away) but the differences between the numbers (or indeed simple rough order of magnitude between points) have cracked more that a few obtuse pointer systems for people over the years. I am way too lazy to make a spreadsheet right now. 114C- 10D0 = 7C , EC-4C= A0 and 1418 take 11EC is 22C
You would also want to look at amount of files and try to find a location with a similar amount of pointers (no point trying to find 2000 pointers in a 10 byte file for instance).
Feeding it back into the compression tool I get the file back as E13 in length.
Sure enough at E20 (it seems this game opts of for a bit of padding/alignment) is another 10 and the start of some more compression (it gets partway readable again and deteriorates). There are far too many instances of 10 to try a simple search. The section of what appear to be uncompressed files (or at least files small enough to render compression ineffective- there still appears to be a few hallmarks of compression in them) starts at 0003 BB90 (hex obviously, from my editor so no need to flip).
It should also be noted when DSdecmp errors out it provides a point at which it errors out. Given I have fed it sliced up files it is not immediately useful but
INPOS = 83c (this made the intial header)
INPOS = 50 (this might be the
In between this is where I got the stall.
INPOS = 90 (this made the slightly bigger header)
INPOS = 17d0 (this made the text dump)- this matches exactly with the next compressed file.
Obviously all this has ignored the evet.pkb file- it appears to be the same format for the most part. However it is now 3:30am so I am going to pass on pulling it apart more for now. Likewise I have other commitments (I probably could have done some hacks I have had hanging over me in the time I just spent on this- no worries though as pulling something apart is far more fun that repointing/tweaking yet another SDAT file) so I am not sure if I will be able to return to this any time soon. Hopefully this is enough to dump the text and start work on reversing the file format so as to put it back in. Your first real challenge is to figure out pointers for the format- exception handling is not really done in programs like this (self contained programs with no user input so to speak- pressing A a few times is nothing compared to user entered data like a database or something) so it will probably be done with pointers. That is far from 100% though and there may be a simple "trick" of compression or end of file flag (or padding abused as a flag) I am overlooking- this might mean digging around in ASM but as long as you are following what goes and not needing to make a entirely new routine or alter an existing one beyond sticking a new pointer in there somewhere it should not be that bad.
If you have the rom evet.pkb and mcht.pkb seem to be the files of choice.
10 at the start of the file usually indicates type 10 compression (one of the traditional DS compression schemes), I fired it through http://code.google.com/p/dsdecmp/ and it spat out the header sections of each file in something resembling a traditional DS header
It started out with the true length of the header in the case of mcht it had 78 which was the end of the last name in the small sub entry.
Decoding from the next 10 marking did little (I think it might have been a coincidence) other than stall the program.
Decoding from the one after that netted a more complete file map (the first value is 6801 or read as the DS would 0168 which is the end of the section again.
Decoding from the one after that gained me a small text 13 kb dump (largely in ASCII- no unicode which is odd for a game like this unless it uses proper unicode and not the U16 (forced 16 bit) most of us see) and it ends with something similar to that old header.
J04.SAD gmdn_v00 and the like. The text itself seems to be a flawless dump (only the new line marker and what appear to be variable (you have X money and the like) the text might be using prevent it from being a standard text file- not traces of a bad decompression (if you force it most LZ decompressors will decode any other LZ but it will not be a nice result). No text pointers though and it starts with 2430 (3024 as the DS might read it) which is the end of the whole decompressed section (including the odd header thing). I sense I am not here to pull apart a text format and as the table is simple enough so that is left for others to ponder.
Some of the things at the end of the initial mcht.pkb file are seemingly not compressed as well.
Looking at some of the headers more closely, between the names exists other data. Looking my second successful decompression
0000 5401 0200 1400 0000 comes before J04.SAD and
0000 5701 0200 1400 0000 comes before gmdn_v00
Traditionally it seems lengths and the like come before names. There are also some 0000's before and after each of those, you can usually ignore them but occasionally if you are dealing with big files they are important to keep proper locations and file sizes* and some things use them for other useful bits of data (a flag to say whether a file is compressed for instance).
0154 and 0157 are fairly obvious guesses for things although what there are is up in the air at this point (sizes maybe)
*kind of like how I reversed 6801 when just starting to pull things apart. A minute ago- a bigger file might have actually used a later byte or two and thus I would have got it wrong and if something like 6801 1000 was written I would have mistakenly decoded it as 0168 0010 when I needed to write 0010 0168
The 0200 1400 part appears to be repeated throughout the header part although as they are all the same sort of filename (and presumably format) that is not surprising. They might be compression flags or flags to tell the decompressor or game where to look for choice bits of data on the file- the only part in which they change is for the Kicker= %d and "GK " (four spaces maybe used as padding- a 6 character limit/fixed length string perhaps?) part in which they are 0100 1400. This is less important for translation though if you are making a game enhancement or using the engine to build another game you will almost certainly need to figure it out.
In order from the start the "size" values list as
EE00
F000
5701
5901
6201
6501
6d01
7001
8001
8301
8E01
9101
9901
9C01
A701
AA01
B101
B401
The "counting up in 3" parts some of that list seems to enjoy I can not ignore- it makes it considerably less likely to be a size value (file sizes neatly going up in values of 3- not likely unless it is a simple padded/restricted affair) and it only going up 3 at a time makes it less likely to be a direct pointer value (file sizes of 3- equally unlikely if not pointless- you would make a whole file and 3 is not a nice length to feed a processor) so it is more likely a reference value (games do not need nice ASCII names- short numbers will do just as well if not better) or a pointer to a pointer (there might be some other table somewhere with. and the other thing I do not like about calling it size is that
J04.SAD is repeated a few times and then J05.SAD is used. Not sure what this means although each instance of J04.SAD has its own "reference" value.
Now this 13K dump makes life a bit more difficult as I can no longer just scroll down and pick out the next file and just searching for 10 again is not likely to be that effective. Compressing the file (using codec LZSS- http://gbatemp.net/index.php?showtopic=274472&hl= ) compresses the file down to about 6KB (not bad for an ASCII file) or more importantly 17CB long.
17CB in the mcht has nothing much but on the screen at about 1500 is fluff.y (obviously a compressed version of fluffy), scrolling through the script and keeping an eye on the new compressed script that is right near the end though.
Sure enough at 188B there is a g.mdn part (remember the odd header like thing at the end of the text dump)
At 18B0 is another 10 flag, deleting all that came before it and firing the new file through the dsdecmp again
A nice 7KB file results. ASCII like before, starts with 8419, ends at 1988 and the 1984 part is the tail end of the %d (it is another repeat of the header part at the end by the way).
On the header repeats though this file has header like data interspersed through the file (more towards the end though but it starts with a file name like thing)- these extractions have subfiles as well - the initial pkb files are archives, these contain files which are also archives?
Far from unheard of in the DS world (NARC files do it all the time, SDAT or more accurately the sample files are built for it) and there are entire roms that layer custom file systems on top of the nitrofs (the thing all known roms use and we use stuff like nstool/ndsts/nitro explorer/crystaltile2 to pull apart). Speaking of crystaltile2 I should really fire these files through the compression search of that program.
Also our old friend 0200 1400 returns.
10D0 marks what I want to call the second subfile (or more accurately the start of the "J04.SAD" string. 114C the next. 11EC the one after that. 1418 the one after that. I would not place too much stock in their actual values/locations (if nothing else because we still do not know if they are indeed true file starts - they do however appear at fixed points relative to others- how many times do you latch onto 00 as the end of a line where in fact the line ends a fixed distance away) but the differences between the numbers (or indeed simple rough order of magnitude between points) have cracked more that a few obtuse pointer systems for people over the years. I am way too lazy to make a spreadsheet right now. 114C- 10D0 = 7C , EC-4C= A0 and 1418 take 11EC is 22C
You would also want to look at amount of files and try to find a location with a similar amount of pointers (no point trying to find 2000 pointers in a 10 byte file for instance).
Feeding it back into the compression tool I get the file back as E13 in length.
Sure enough at E20 (it seems this game opts of for a bit of padding/alignment) is another 10 and the start of some more compression (it gets partway readable again and deteriorates). There are far too many instances of 10 to try a simple search. The section of what appear to be uncompressed files (or at least files small enough to render compression ineffective- there still appears to be a few hallmarks of compression in them) starts at 0003 BB90 (hex obviously, from my editor so no need to flip).
It should also be noted when DSdecmp errors out it provides a point at which it errors out. Given I have fed it sliced up files it is not immediately useful but
INPOS = 83c (this made the intial header)
INPOS = 50 (this might be the
In between this is where I got the stall.
INPOS = 90 (this made the slightly bigger header)
INPOS = 17d0 (this made the text dump)- this matches exactly with the next compressed file.
Obviously all this has ignored the evet.pkb file- it appears to be the same format for the most part. However it is now 3:30am so I am going to pass on pulling it apart more for now. Likewise I have other commitments (I probably could have done some hacks I have had hanging over me in the time I just spent on this- no worries though as pulling something apart is far more fun that repointing/tweaking yet another SDAT file) so I am not sure if I will be able to return to this any time soon. Hopefully this is enough to dump the text and start work on reversing the file format so as to put it back in. Your first real challenge is to figure out pointers for the format- exception handling is not really done in programs like this (self contained programs with no user input so to speak- pressing A a few times is nothing compared to user entered data like a database or something) so it will probably be done with pointers. That is far from 100% though and there may be a simple "trick" of compression or end of file flag (or padding abused as a flag) I am overlooking- this might mean digging around in ASM but as long as you are following what goes and not needing to make a entirely new routine or alter an existing one beyond sticking a new pointer in there somewhere it should not be that bad.
I lied, I did a bit more in the end. Again to save it being buried in PMs I will post it here. Bigs thanks again to TyRaNtM for pointing me at files. This will have to be my last stab at it for a while (I can not really be sitting here pulling apart a rom when I have reviews I have repeatedly had delays finishing).
All it takes to do it is feeding them into dsdecmp, figuring out where the next file starts (it will start with a 10 if it is compressed) and then deleting everything that came before it in the file.
More interestingly I just tried a bit of the evet.pkb file- the third and fourth files are nearly identical (it is mainly the surrounding text data that changes- the text portion is identical as far as I can see). Also the dsdecmp program matches up perfectly with the end of the subfiles for evet.pkb - try extracting it, take the "Too many data in file; current INPOS = b08" (that was an example but naturally it will differ a bit for each message) and go there. Delete everything that comes before it (so you are starting with a "10") and try extracting it again. Rinse and repeat for all the files of which there are likely to be many (you might want to automate that somehow- I tried with crystaltile2 just now but it crashed after some 310 files for the bigger file but it appeared to work on the smaller file- open the file (you might have to select all files), go to the hex editor window, press search pulldown menu)-> LZ77/Huffman compression, the stock options should work. Press find and it will say x hundred hits. Under file on this subwindow will be an option called batch unzip and the rest is basic windows stuff. Watch your machine grind to a halt and probably see crystaltile2 crash (it is a horrific thing you are asking it to do- the tool was only designed for things of about 20 files at most) [TyRaNtM says an older version of crystaltile2 did not crash]. It should net you a bunch of files to look at though.
Personally I would grab dsdecmp source and take the error message and use it as a variable (if it can not already), make a start address option (another thing I am supposed to be helping on has a compressed file with an uncompressed header so that probably wants to be done at some point anyway) and use it to recursively extract every single file. My C# and/or Java skills are not up to this though.
If you are feeling brave though you might even add compression scanning to dsdecmp- a handful of tools for this exist (crystaltile2 being the main general purpose one I know of- most others are aimed at GBA graphics).
On the other hand you might grab file numbers, locations and sizes from the crystaltile2 output and couple it with a file trimmer ( filecutter from http://crackerscrap.com/ under projects is my usual call here). Sadly it does not allow simple dumping or copying and pasting and my text copying tools (stuff like the autoit active window info program- best I could do is double click to set hex editor location and snatch data from the title bar/hidden section when it does it) are not playing ball today. I need to find another one though and if you have one do share or even do the hack. Looking at http://www.autoitscript.com/autoit3/docs/intro/au3spy.htm though I appear to have an inferior old version, my only problem with upgrading though is I lose the decompiler for autoIT which I enjoy although it appears there are a few standalones I can try so that might be worth a punt.
After this you can make it into a batch file (probably via a spreadsheet to clean a few things up and convert the odd thing) and also go looking for a few headers/pointer tables for the subfiles.
I also took on the sound files for a bit.
A non SDAT file and one I have not seen before on the DS, very interesting. However as the undub and slight tweak is all that is called for I will leave decoding the files for now (undubs and tweaks are filesystem level hacks)- if I had to guess what goes it would be based on some of the magic stamps in the file and the history of DS audio it is likely some form of close to hardware decoding wave/PCM/IMA-ADPCM. If a straight undub did not work try making the file names the same and fiddling there.
It appears to be one of the simplest packing formats I have seen on the DS. I have seen several things like it
First line is file name
First 14 bytes appear to be size (although flipping them gets a bit odd for really big numbers)
In the second line BC08 flips to 08BC which is the start of a file (0000 in the first line indicates the file starts at the start of the file so that is not much use for reversing).
The next line is 7CD3, looking back for a second you have BC08 C0CA 0100 or more accurately 08BC and 0001 CAC0, adding them rather nicely produces 0001 D37C. This is quite nice in rom hacking*- you saw the rest of the rom where things had 16byte alignment.
*other roms/files like alignment so file start + length does not always equal next file start location.
0001 D37C is where the next file starts.
All names appeared to be filename.S?? so searching for .S yields 852 files. Add one as there is a file called Makefile which is detailed at 66C0 in the .ph file. Odd little files like this can make or break a rom hack so I looked at that.
E875 4D02
translates as
024D75E8
050B long
024D 7AF3 is the end which is rather nicely also the next file still (means things probably did not change as the file went on)
It appears to do as it says on the tin, perhaps not quite as nice as princess maker, zoids saga stuff for sound or some of the other interesting things that have been dug out of roms over the years.
All it takes to do it is feeding them into dsdecmp, figuring out where the next file starts (it will start with a 10 if it is compressed) and then deleting everything that came before it in the file.
More interestingly I just tried a bit of the evet.pkb file- the third and fourth files are nearly identical (it is mainly the surrounding text data that changes- the text portion is identical as far as I can see). Also the dsdecmp program matches up perfectly with the end of the subfiles for evet.pkb - try extracting it, take the "Too many data in file; current INPOS = b08" (that was an example but naturally it will differ a bit for each message) and go there. Delete everything that comes before it (so you are starting with a "10") and try extracting it again. Rinse and repeat for all the files of which there are likely to be many (you might want to automate that somehow- I tried with crystaltile2 just now but it crashed after some 310 files for the bigger file but it appeared to work on the smaller file- open the file (you might have to select all files), go to the hex editor window, press search pulldown menu)-> LZ77/Huffman compression, the stock options should work. Press find and it will say x hundred hits. Under file on this subwindow will be an option called batch unzip and the rest is basic windows stuff. Watch your machine grind to a halt and probably see crystaltile2 crash (it is a horrific thing you are asking it to do- the tool was only designed for things of about 20 files at most) [TyRaNtM says an older version of crystaltile2 did not crash]. It should net you a bunch of files to look at though.
Personally I would grab dsdecmp source and take the error message and use it as a variable (if it can not already), make a start address option (another thing I am supposed to be helping on has a compressed file with an uncompressed header so that probably wants to be done at some point anyway) and use it to recursively extract every single file. My C# and/or Java skills are not up to this though.
If you are feeling brave though you might even add compression scanning to dsdecmp- a handful of tools for this exist (crystaltile2 being the main general purpose one I know of- most others are aimed at GBA graphics).
On the other hand you might grab file numbers, locations and sizes from the crystaltile2 output and couple it with a file trimmer ( filecutter from http://crackerscrap.com/ under projects is my usual call here). Sadly it does not allow simple dumping or copying and pasting and my text copying tools (stuff like the autoit active window info program- best I could do is double click to set hex editor location and snatch data from the title bar/hidden section when it does it) are not playing ball today. I need to find another one though and if you have one do share or even do the hack. Looking at http://www.autoitscript.com/autoit3/docs/intro/au3spy.htm though I appear to have an inferior old version, my only problem with upgrading though is I lose the decompiler for autoIT which I enjoy although it appears there are a few standalones I can try so that might be worth a punt.
After this you can make it into a batch file (probably via a spreadsheet to clean a few things up and convert the odd thing) and also go looking for a few headers/pointer tables for the subfiles.
I also took on the sound files for a bit.
A non SDAT file and one I have not seen before on the DS, very interesting. However as the undub and slight tweak is all that is called for I will leave decoding the files for now (undubs and tweaks are filesystem level hacks)- if I had to guess what goes it would be based on some of the magic stamps in the file and the history of DS audio it is likely some form of close to hardware decoding wave/PCM/IMA-ADPCM. If a straight undub did not work try making the file names the same and fiddling there.
It appears to be one of the simplest packing formats I have seen on the DS. I have seen several things like it
Code:
00000000 | 3244 5F30 3030 2E53 4544 0000 0000 0000 | 2D_000.SED......
00000010 | 0000 0000 0000 0000 0000 0000 BC08 0000 | ................
00000020 |3244 5F30 3030 2E53 5744 0000 0000 0000 | 2D_000.SWD......
00000030 | 0000 0000 0000 0000 BC08 0000 C0CA 0100 | ................First line is file name
First 14 bytes appear to be size (although flipping them gets a bit odd for really big numbers)
In the second line BC08 flips to 08BC which is the start of a file (0000 in the first line indicates the file starts at the start of the file so that is not much use for reversing).
The next line is 7CD3, looking back for a second you have BC08 C0CA 0100 or more accurately 08BC and 0001 CAC0, adding them rather nicely produces 0001 D37C. This is quite nice in rom hacking*- you saw the rest of the rom where things had 16byte alignment.
*other roms/files like alignment so file start + length does not always equal next file start location.
0001 D37C is where the next file starts.
All names appeared to be filename.S?? so searching for .S yields 852 files. Add one as there is a file called Makefile which is detailed at 66C0 in the .ph file. Odd little files like this can make or break a rom hack so I looked at that.
E875 4D02
translates as
024D75E8
050B long
024D 7AF3 is the end which is rather nicely also the next file still (means things probably did not change as the file went on)
It appears to do as it says on the tin, perhaps not quite as nice as princess maker, zoids saga stuff for sound or some of the other interesting things that have been dug out of roms over the years.
Code:
#
#-------------------------------------------------------------------------------
# author : nozuru
# memoÂÂ : ???????????????clean????
#-------------------------------------------------------------------------------
NULÂÂÂÂÂÂÂÂÂÂÂÂ=ÂÂÂÂ/dev/null
TOOLPATHÂÂÂÂ=ÂÂÂÂ../../Tool/packer
PACKERÂÂÂÂÂÂÂÂ=ÂÂÂÂ$(TOOLPATH)/packer
BINDIRÂÂÂÂÂÂÂÂ=ÂÂÂÂbin
INSTALLDIRÂÂÂÂ=ÂÂÂÂ../../../ina_main/data_iz/sound/ge
SRCSÂÂÂÂÂÂÂÂ:=ÂÂÂÂ$(wildcard *.SED *.SMD *.SWD)
vpath %.pb $(BINDIR)
#-------------------------------------------------------------------------------
#packer???????????????????????????????????
#????????????????????????
#??????????'\'????????????
all: makedir ge.pb
ge.pb: $(SRCS)
ÂÂÂÂ@$(PACKER) ..\\ge
ÂÂÂÂ@mv ../ge.pb $(BINDIR)/sound.pb
ÂÂÂÂ@mv ../ge.ph $(BINDIR)/sound.ph
#-------------------------------------------------------------------------------
makedir:
ÂÂÂÂ@mkdir -p $(BINDIR)
#-------------------------------------------------------------------------------
install: all
ÂÂÂÂ@cp $(BINDIR)/sound.p* $(INSTALLDIR)
#-------------------------------------------------------------------------------
clean:
ÂÂÂÂ@-$(RM) -R $(BINDIR)
#-------------------------------------------------------------------------------I lied once more (so much for not liking football much less football games), as a rule if a file has the same name but a different extension look at both of them together. My fault for not pressing the issue/using the entire rom really but that is in the past now so on with the hacking.
I took a look at the pkh files of the same names as the files I was looking at for the text- looks vital and has the compression locations/start locations (compared that against crystaltile2 compression search- matched it exactly).
mcht.pkh
Each line/entry into the table is "C" long (12 bytes)
The initial header just appears to be a magic stamp, a date and the length of the whole pkh file. I have not determined what the other parts are yet (probably number of entries and other good stuff like that)
If you leave the header on it makes it a bit harder to read but not that bad.
I am not sure what the first 4 bytes are about. The second 4 bytes are the locations (these match with crystaltile2) and the last bytes are obviously size related- same sizes in crystaltile2 same value and same changes corresponding to the relative changes in the size of the resulting files. I have yet to determine what goes. It says C where crystaltile2 says 4 (remember crystaltile2 is in decimal but 4 is 4 whether you are in hex or decimal).
36 decimal in crystaltile2 comes up as 24 in hex.
288 decimal comes up as AC
264 decimal comes up as 98
AC -98 =14 (all hex) or 20 decimal. Not the same as the 288-264
Looking back at the first part again it appears to be counting in places although there are jumps. These jumps correspond to file size changes (counting when the same "compression size" but jump when it changes). Looking at the evet.pkh it fails to jump where it might jump in the mcht and does, other than that it is more or less the same bar a curious lack of a line in the header before the start of the pointers- most headers are effectively pre defined affairs or have pointers/lengths buried in them (and are probably still fixed length).
I am tempted to call these unknowns file labels (missing files or files that were numbered but did not make the final cut- looking at that makefile from this morning that is not stretching much).
Anyhow now you have pointers you can make a batch file to pull it apart (I already mentioned a couple of tools I would use to do the deed), you could make a programming style one if you want but I would opt to dump the pointers to a spreadsheet for use in making a batch file, extract one to a name (perhaps take the "name" values- for one it keeps the order which is vital), delete the "old" file, repeat the extraction.
This might make it a bit easier to extract the files but rebuilding them could then end up a pain (pointers are nice but you have to change them) and you will have to figure out what the seemingly size related value actually is and confirm the naming value I used was not useful for anything else.
A quick sample of mcht.pkh (pointer section having been subject to a 32bit unsigned long byte flip).
A snap of some of the crystaltile2 results.
I took a look at the pkh files of the same names as the files I was looking at for the text- looks vital and has the compression locations/start locations (compared that against crystaltile2 compression search- matched it exactly).
mcht.pkh
Each line/entry into the table is "C" long (12 bytes)
The initial header just appears to be a magic stamp, a date and the length of the whole pkh file. I have not determined what the other parts are yet (probably number of entries and other good stuff like that)
If you leave the header on it makes it a bit harder to read but not that bad.
I am not sure what the first 4 bytes are about. The second 4 bytes are the locations (these match with crystaltile2) and the last bytes are obviously size related- same sizes in crystaltile2 same value and same changes corresponding to the relative changes in the size of the resulting files. I have yet to determine what goes. It says C where crystaltile2 says 4 (remember crystaltile2 is in decimal but 4 is 4 whether you are in hex or decimal).
36 decimal in crystaltile2 comes up as 24 in hex.
288 decimal comes up as AC
264 decimal comes up as 98
AC -98 =14 (all hex) or 20 decimal. Not the same as the 288-264
Looking back at the first part again it appears to be counting in places although there are jumps. These jumps correspond to file size changes (counting when the same "compression size" but jump when it changes). Looking at the evet.pkh it fails to jump where it might jump in the mcht and does, other than that it is more or less the same bar a curious lack of a line in the header before the start of the pointers- most headers are effectively pre defined affairs or have pointers/lengths buried in them (and are probably still fixed length).
I am tempted to call these unknowns file labels (missing files or files that were numbered but did not make the final cut- looking at that makefile from this morning that is not stretching much).
Anyhow now you have pointers you can make a batch file to pull it apart (I already mentioned a couple of tools I would use to do the deed), you could make a programming style one if you want but I would opt to dump the pointers to a spreadsheet for use in making a batch file, extract one to a name (perhaps take the "name" values- for one it keeps the order which is vital), delete the "old" file, repeat the extraction.
This might make it a bit easier to extract the files but rebuilding them could then end up a pain (pointers are nice but you have to change them) and you will have to figure out what the seemingly size related value actually is and confirm the naming value I used was not useful for anything else.
A quick sample of mcht.pkh (pointer section having been subject to a 32bit unsigned long byte flip).
Code:
00000000 5061 636B 4E75 6D20 3230 3038 PackNum 2008
0000000C 3036 3236 D00C 0000 0100 0D01 0626........
00000018 1000 0000 0018 0000 0000 0000 ............
00000024 0000 0000 0000 0000 0000 0000 ............
00000030 0000 0000 0000 0000 0000 0050 ...........P
0000003C 055D 4A83 0000 0050 0000 0090 .]J....P....
00000048 055D 4A88 0000 00E0 0000 17D0 .]J.........
00000054 059A 53A2 0000 18B0 0000 0E18 ..S.........
00000060 059A 53A3 0000 26D0 0000 0D40 ..S...&....@
0000006C 059A 53A4 0000 3410 0000 0D20 ..S...4....
00000078 059A 53A5 0000 4130 0000 0D68 ..S...A0...h
00000084 059A 53A6 0000 4EA0 0000 0DCC ..S...N.....
00000090 059A 53A7 0000 5C70 0000 0CC8 ..S...\p....
0000009C 059A 53A8 0000 6940 0000 0E40 ..S...i@...@
000000A8 059A 53A9 0000 7780 0000 0E48 ..S...w....H
000000B4 059A 53AA 0000 85D0 0000 0E80 ..S.........
000000C0 059A 53AB 0000 9450 0000 0E7C ..S....P...|
000000CC 059A 53AC 0000 A2D0 0000 0C90 ..S.........
000000D8 059A 53AD 0000 AF60 0000 0D0C ..S....`....
000000E4 059A 53AE 0000 BC70 0000 0E80 ..S....p....
000000F0 059A 53B5 0000 CAF0 0000 0D14 ..S.........
000000FC 059A 53B6 0000 D810 0000 0C10 ..S.........
00000108 059A 53B7 0000 E420 0000 0C10 ..S.... ....
00000114 059A 53B8 0000 F030 0000 0C10 ..S....0....
00000120 059A 53B9 0000 FC40 0000 0C10 ..S....@....
0000012C 059A 53BA 0001 0850 0000 0C10 ..S....P....
00000138 059A 53BB 0001 1460 0000 0C10 ..S....`....
00000144 059A 53BC 0001 2070 0000 0C10 ..S... p....
00000150 059A 53BD 0001 2C80 0000 0C10 ..S...,.....A snap of some of the crystaltile2 results.
- Joined
- Oct 13, 2007
- Messages
- 1,008
- Trophies
- 1
- Age
- 37
- Location
- Chile
- Website
- www.power-ups.net
- XP
- 596
- Country
So, the .pkh files were vital too..
Edit: For the people that is following this project, this is a image showing that we able to modify all names, what we really need to finish, is the script part, isnt too easy.
........................IE EUR Name.........................................Original Name
Edit: For the people that is following this project, this is a image showing that we able to modify all names, what we really need to finish, is the script part, isnt too easy.
........................IE EUR Name.........................................Original Name
What changes to the script do you mean? Just editing the names when they are spoken as part of dialogue? Anyways, I'm surprised you were able to make so much progress so quickly, good job and keep up the great work.
I'm impressed you were able to already figure out a way to get the names implemented at all. I was curious to see if you'd have to make any compromises to the names since typically the japanese names have more characters than the american names and they might not have fit.
I'm actually quite happy to see this project being done for Inazuma, I was really looking forward to the European version when I first saw the Japanese one being release.
But man what shock did I get when I noticed the changes in names and the English voices..again no options for Japanese voices and Japanese Name for players...
I would be more than happy to give a hand on translation of names if help is still needed, I can translate mostly any Japanese names, except for a few very obscures ones.
I'm not sure how to proceed, but if I had a list of the names in Japanese I would gladly translate it in English.
On a side note my preference would be a Excel spreadsheet although a text files with the names would do as well.
The one one from the OP seems to not be working so I can download it.
[email protected]
If anyone can mail me the list of names I will start working on it. Just let me know what part is being done and I will work on the ones that haven't been touched yet.
But man what shock did I get when I noticed the changes in names and the English voices..again no options for Japanese voices and Japanese Name for players...
I would be more than happy to give a hand on translation of names if help is still needed, I can translate mostly any Japanese names, except for a few very obscures ones.
I'm not sure how to proceed, but if I had a list of the names in Japanese I would gladly translate it in English.
On a side note my preference would be a Excel spreadsheet although a text files with the names would do as well.
The one one from the OP seems to not be working so I can download it.
[email protected]
If anyone can mail me the list of names I will start working on it. Just let me know what part is being done and I will work on the ones that haven't been touched yet.
- Joined
- Oct 13, 2007
- Messages
- 1,008
- Trophies
- 1
- Age
- 37
- Location
- Chile
- Website
- www.power-ups.net
- XP
- 596
- Country
Kanjutsu said:
Thanks, but japanese names are finished (all 1957 names).
We are about 90% of the project, and we need to finish the most difficult part: the script.
- Joined
- Oct 13, 2007
- Messages
- 1,008
- Trophies
- 1
- Age
- 37
- Location
- Chile
- Website
- www.power-ups.net
- XP
- 596
- Country
More screens:
........................IE EUR Name.........................................Original Name
........................IE EUR Name.........................................Original Name
EDIT:
........................IE EUR Name.........................................Original Name
........................IE EUR Name.........................................Original Name
EDIT:
It's funny how they apparently tried to translate some names literally into something that sounded like the original name like Mamoru Endo into Mark Evans and that random guy Miyasaka Ryou into Miles Ryan and other are completely different like Gouenji into fuking Blaze lol.
Keep up the good work guys, looking great.
Keep up the good work guys, looking great.
wow seems to be going quite well.
I will be looking forward to the completion of this project, if there is anything you'd need help with beside translation of name, I'm up for it.
As long as it concern translation, I'm not really good with anything else
I will be looking forward to the completion of this project, if there is anything you'd need help with beside translation of name, I'm up for it.
As long as it concern translation, I'm not really good with anything else
- Status
Similar threads
- No one is chatting at the moment.
-
-
-
-
-
-
-
-
-
@
Xdqwerty:
@BakerMan, iirc it was about a news article about princess peach showtime using the word "sus" unironically -
-
-
-
-
-
-
-
-
-
-
-
-
@
realtimesave:
Nintendo needs to release a new console, switch is getting such shitty little games lately lol it's pathetic -
-
-
