psy_commando

Yeah, I specified those particular cases because they completely threw me off ! The cursor16.wan has a different image format, or maybe its cursor.wan.. I mix them up all the time.. What do you mean data wise ? You mean like the report from my tool running on that sprite ? I'm also pm-ing you the images I've extracted from that. AFAIK the frames are really "chopped" that way.. EDIT: Here's what I got for Vaporeon: https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/temp/file_0146_0x2d2e70.log And here's what I got for cursor.wan and cursor16.wan : https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/temp/cursor.log https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/temp/cursor16.log ( Just a word of caution: never trust the "average" values in those reports, there's something freaky going on with that.. Probably some implicit signed/unsigned conversion messing the result up.. ) Also, I'll have to sign off for a few hours, so it will take some time before I can reply.

Oh, so you cross-referenced DBG,DBH,DBI with DBS ? That looks pretty solid to me! Nicely done! I can't believe I didn't try to do that.. Even though I'm hardly surprised I didn't given my track record ^^; You should try it on "FONT/cursor.wan" and "FONT/cursor16.wan", and then on a sprite file with a lot of randomly sized frames, like vaporeon's, its file number 146 or something really close in "MONSTER/m_ground.bin" (eevee is 145).

Yep, they most likely contain animation data. There are 4 places I know of that could actually contain those though. But DBS is a pretty good candidate. Datablock F was pretty high on my list, because in the UI sprites and anything that wasn't a pokemon, the entire block isn't even there at all.. But the data is too short and random to be a sequence of frames... And you might not want to call those SIR0, because SIR0 is a generic container. Like, it can contain PKDPX files and literally anything you want. Most loose files that have the SIR0 header and contain sprites, in the FONT and GROUND folders, have a .wan file extension. Some have another extension though. I'd speculate that they possibly might use 2 nybbles to indicate the amount of vertical and horizontal tiles, given at 40x40 we're not yet past the nybble's max value in terms of tiles. And if you want to take a look, here's a detailed report on Bulbasaur's sprite: https://dl.dropboxusercontent.com/u/13343993/my_pmd_research_files/file_0000_0x1300.log It kinda structures/organizes the data a little. Maybe it will help.

Well, that's all good. But I'm just saying that it might be better not to burn yourself out on things like that before getting to the core of the problem! I mean, I'm probably stuck in a way of thinking that keeps me to see the very obvious solution to the issue basically. And maybe that anyone else looking 5 minutes at it could find out what I missed ^^; Its not the first time.. Remember those signed values I mistook for something else in the smd files?

You didn't have to do all that though ^^; Pack files are well known by now. I've had the extractor and re-packer tool coded and on the front page for months now. SIR0 also has been figured out for a long while, its all in the common format notes on the first page of the thread. You might want to check those out, and go from there. The sprite analyser I posted a few post ago is all based on that knowledge. EDIT: And, we've already got a tool to extract sprites to indexed pngs.(I had bmp support, but its just redundant at this point given png does exactly the same thing and has good compatibility) But the thing is, right now we have to guess the resolution of each frames in the sprite, given they can all have different dimensions. 16x32, 32x32, 8x16, name it.. And they can be laid out on the width or on the height.. So there must be something in the sprite file that we didn't see that indicates the proper image resolution.. Maybe something indicating the amount of tiles on the width and height, or simply indicating the resolution in pixels ? Plus, we also found out that some sprite can be in another format than 4bpp... And so far the only obvious differences I spotted using my tool were a couple of 16bits integer. If we can figure resolution out, and then the way animations are stored, we'll be pretty much able to rebuild a sprite from scratch !

Ok, so after looking at a ton of sprites, I think I might have found a few correlations here and there between the format of the sprite and the value of the 9 boolean values spread around the 3 parts of the sprite header. But, I think that, I might need the opinion of others to definitely find out what it is exactly that I've found.. So lets compare 3 sprite files. First a regular character sprite, then a sprite for some UI element, then another sprite for some UI element but with some difference. Character sprite "/MONSTER/m_ground.bin/file_0001": Sprite Sub-Header : ------------------------ Offset img data.........: 0x00004004 Offset unk data.........: 0x00003FEC Unknown value0..........: 0x0001 Unknown value1..........: 0x0000 Sprite Info Block : ------------------------ Offset table E..........: 0x00003968 Offset table F..........: 0x00003A68 Offset table G..........: 0x00003F0C NbEntries table G.......: 13 Unknown.................: 4 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0000 Unknown #4..............: 0x0000 Sprite Frame Data Block : ------------------------ Offset frame ptr table..: 0x00003F74 Offset palette end......: 0x00003958 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0001 Nb frames...............: 30 The UI sprite ("/FONT/cursor.wan"): Sprite Sub-Header : ------------------------ Offset img data.........: 0x00000958 Offset unk data.........: 0x00000940 Unknown value0..........: 0x0000 Unknown value1..........: 0x0000 Sprite Info Block : ------------------------ Offset table E..........: 0x00000908 Offset table F..........: 0x00000000 Offset table G..........: 0x00000928 NbEntries table G.......: 1 Unknown.................: 8 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0001 Unknown #4..............: 0x0000 Sprite Frame Data Block : ------------------------ Offset frame ptr table..: 0x00000930 Offset palette end......: 0x000008F8 Unknown #1..............: 0x0001 Unknown #2..............: 0x0001 Unknown #3..............: 0x0001 Nb frames...............: 4 And an alternate version version of it ("/FONT/cursor16.wan"): Sprite Sub-Header : ------------------------ Offset img data.........: 0x00000398 Offset unk data.........: 0x00000380 Unknown value0..........: 0x0000 Unknown value1..........: 0x0000 Sprite Info Block : ------------------------ Offset table E..........: 0x00000348 Offset table F..........: 0x00000000 Offset table G..........: 0x00000368 NbEntries table G.......: 1 Unknown.................: 4 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0000 Unknown #4..............: 0x0000 Sprite Frame Data Block : ------------------------ Offset frame ptr table..: 0x00000370 Offset palette end......: 0x00000338 Unknown #1..............: 0x0001 Unknown #2..............: 0x0000 Unknown #3..............: 0x0001 Nb frames...............: 4 Just compare the values that aren't pointers/offset or 32bits integers. Its a pretty odd way of indicating the format of the file no ? I mean, in those 20 bytes they could have fitted a lot more details about the sprite data.. Which kinda makes me doubt a little of what I found here.. Could these be only coincidences ? Or are those really indicating details about the format ? EDIT: Here are a few more that differ: "/GROUND/d01p11b2.wan" Sprite Sub-Header : ------------------------ Offset img data.........: 0x00005D4C Offset unk data.........: 0x00005D34 Unknown value0..........: 0x0000 Unknown value1..........: 0x0000 Sprite Info Block : ------------------------ Offset table E..........: 0x00005854 Offset table F..........: 0x00000000 Offset table G..........: 0x00005CE0 NbEntries table G.......: 1 Unknown.................: 6 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0000 Unknown #4..............: 0x0000 Sprite Frame Data Block : ------------------------ Offset frame ptr table..: 0x00005CE8 Offset palette end......: 0x00005844 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0001 Nb frames...............: 19 "/GROUND/d79p41a.wan" Sprite Sub-Header : ------------------------ Offset img data.........: 0x00002050 Offset unk data.........: 0x00002038 Unknown value0..........: 0x0000 Unknown value1..........: 0x0000 Sprite Info Block : ------------------------ Offset table E..........: 0x00001F8C Offset table F..........: 0x00000000 Offset table G..........: 0x00001FCC NbEntries table G.......: 1 Unknown.................: 15 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0000 Unknown #4..............: 0x0000 Sprite Frame Data Block : ------------------------ Offset frame ptr table..: 0x00001FD4 Offset palette end......: 0x00001F7C Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0003 Nb frames...............: 25 "/GROUND/as001.wan" Sprite Sub-Header : ------------------------ Offset img data.........: 0x00000A48 Offset unk data.........: 0x00000A30 Unknown value0..........: 0x0000 Unknown value1..........: 0x0000 Sprite Info Block : ------------------------ Offset table E..........: 0x00000A10 Offset table F..........: 0x00000000 Offset table G..........: 0x00000A18 NbEntries table G.......: 1 Unknown.................: 16 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0000 Unknown #4..............: 0x0000 Sprite Frame Data Block : ------------------------ Offset frame ptr table..: 0x00000A20 Offset palette end......: 0x00000A00 Unknown #1..............: 0x0000 Unknown #2..............: 0x0000 Unknown #3..............: 0x0004 Nb frames...............: 4 There are a lot more unusual values here !

I'd say its just an unwanted/unneeded feature of the toolset they've used. There are really no need for meaningful filenames in there, given its the final copy that they ship to production. Also, I've been discovering a few interesting things about sprites.. I still don't have a clue of where to find the actual resolution, but I think I might be close to figuring it out. For those interested, I made myself a little program to analyze sprite files in depth, and fill a report on them : It only works on uncompressed sprites right now, and is still kinda glitchy, but the reports are really useful ! I'm just too slow at drawing parallels based on the data I found in those.. So if anyone wanna run it on a bunch of sprites and try to figure out what is what, that could help ! There are no readme, but the program can print its own detailed readme, if ran without arguments. And the source code was commited to the codeplex page for the library. ppmd_spranalyser_alpha.zip

Sounds good! You might want to take a look at the Wav format. Given it can contain loop points info as well, and would give you a good idea of how its commonly done, and what data needs to be stored! On my side, I've been writing a sprite analyser tool. It might just help figure out the format! At least I hope.. ^^;

Update: I made another commit of my code, this time with working code for the unpacker/packer. I also improved it a lot, its even faster now! For some reasons though, packing is faster than unpacking.. 200ms to pack vs 450ms and up to unpack. I don't know why I'm so obsessed with performances ^^; I also fixed a couple of dumb things I did, like in a few loops I was using a "for( auto curentry : m_structure )" kind of loop, and I forgot to put a "&" between auto and the variable name.. The result was a mess of unneeded copies which I didn't even notice until now ^^; Sounds good! That explains everything Honestly, I never even used wonder mail before.. I didn't even attempt a friend rescue So I wasn't too sure what those were. What do those do in particular though ?

Oh, I got that part. Its just that I was wondering if there wasn't a link somewhere with what we were talking about that I'd have missed. Its interesting to see they actually store 3d models inside SIR0 files though And, I don't know how you can say its bs, when I don't even know what those codes are for.. Are they file ids or hashes or AR codes or something like that ? And then, what do they do? You should definitely try. Though, better extract the files first, and then pack them back into a rom, because of the nitrofs's FAT. EoS is pretty straightforward when you edit things. It usually black screen or crashes when you screw something up.

Sorry, but I'm not sure I understand what you're trying to say. ^^; What are those codes ? @TruePikachu: Well, technically we're all romhacking here, no ? Do you mean you'd rather stick with only the smds ? Also, I'm guessing you meant swd, because swf are flash "movies"

Sounds good. And the internal names are unrecoverable AFAIK. I'm not sure why they even bothered to put them inside those files at all.. Its possible they're refered to as those names in the scripting system however.. But you'd have to ask Nerketur about that.. I looked at the vgmstream lib code, and its hard-coded for SADL files from Professor Layton.. The ADPCM decoding code however might just be very useful, if we can isolate it and re-use it.. But its some very messy C code, with some not very intuitive structure and variable naming.. Its going to take a while to figure it out.. Also, I'll admit I kinda feel useless with everyone making that much progress, and me not doing much right now ^^;

IMA ADPCM has a LOT of variants.. If you want to hear some of the sound effects, try to load the BGM.swd or any SWD that has something in their pcmd chunk as raw data into Audacity. Then select VOX ADPCM, little endian, mono, and the sample rate is indicated inside the corresponding wavi chunk entry, but you can usually go for 22050hz if you're not sure. Ideally, you'd only want to feed audacity the data in the pcmd chunk, given ADPCM is "incremental" in the way it decompresses stuff, and any extra data before will change the sound a little.. (If anyone ever stumble on ADPCM decoding libs for the NDS, I'd appreciate hearing about those !) @TruePikachu: I believe that what's in the ME folder has a very similar structure to everything in BGM. So that might work too. EDIT: Speaking of which. SED files are highly similar to SMD files. Except they seem to have several new chunks. EDIT2: Kr3nshaw That link you gave me about the Procyon sequencer and stuff, it has some nice little tidbits of information even when quickly translated: http://www.procyon-studio.co.jp/dse/spec.html EDIT3: And if anyone is wondering what is IMA ADPCM its a standard, its not a "specific" format. http://wiki.multimedia.cx/index.php?title=IMA_ADPCM And I was able to find out that the vgmstream lib Kode54 maintains has support for Procyon studio NDS ADPCM : https://github.com/kode54/vgmstream I'm looking at the code and I suggest people interested to look within the source code for the enum constant named "coding_NDS_PROCYON" as a starting point.

That's funny.. The readme mentioned C++.. I guess its one of these person who codes in C in C++ Also, I don't even know if C support Unicode, or the JIS character set Also, what disassembler are you using, just by curiosity ? ^^; EDIT: Wait.. The C++ compiler removes literally everything about classes when it compiles stuff.. So I guess its normal that it looks like there aren't any.. Unless I'm missing something..

Someone pm-ed me the link to an utility that extracts the tracks from PMD2 perfectly as midi: http://pan.baidu.com/wap/shareview?&shareid=878289138&uk=1829041001&dir=%2F%E6%88%91%E7%9A%84%E6%96%87%E6%A1%A3%2F%E6%B8%B8%E6%88%8F%E8%B5%84%E6%BA%90%E6%8F%90%E5%8F%96%E7%A8%8B%E5%BA%8F&page=1&num=20&fsid=1084154235148743&third=0 To use it simply put as parameter the path to the BGM folder, with no trailing slash at the end. Then as second parameter the path to the folder to output midis to, with no trailling slash at the end. You can also put options before those two paths. "-l" is to set the loop count. and "-d" for outputting debug input I guess. In the folder there are 2 files used to map instruments, and they're very small.. And it seriously seems to get absolutely everything 100% right.. Its seriously impressive... Just play the BGM0004.mid to see what I mean.. The flute just sounds exactly the same way.. Its scary.. EDIT: I'm having feels attack listening to these ;_; EDIT2: One thing to note is that, there's an issue where the in Chasm Cave and etc, the French Horn is replaced with an Oboe for some reasons.. And the trumpet in "The Power of Darkness" is replaced with an Alto Sax..

That's all good. If you want my opinion, you should wait before getting into making proper mapping until we're more familiar with everything. Because if we find out an easy way to do it, you'd have wasted a lot of time on doing that. But that's just my opinion. And at this point, I'd suggest a good old brute force approach to try to get some more results. Directly editing values in the SWDs and etc.. That's what I'm planning to do with the sprite pretty soon. It usually gives great results. That's how I figured half of what I wrote in my notes on the SMDs !

I never seen those used anywhere else than the beginning of a track. With the exception of maybe right after a 0x90 event, given some events you only see at the beginning of a track seem to be repeated right after a 0x90.. I gotta double check though, I'm still trying to find where I saw a 0x90 event the last time.. But those two being about priority makes a lot of sense ! Given the game seamlessly change songs constantly. If those are enums, maybe we could find those values in the game executable, one after another ? That sounds pretty likely, or maybe its just a coincidence with the software they've used to compose the tracks using 15 instead of 10 or something? I'll try setting a drum track to another track number just for fun! EDIT: I changed the drum track in Northern Desert from 0x0D and 0x0F to 0x01 and 0x01, and it stills plays like it should! So, I'd say its mainly a coincidence that all drum tracks are 0x0F. EDIT2: Ok, now I completely agree with you that 0x90 is probably a repeated silence.

No offense, but it kind of makes it hard to discuss when your replies are half changelogs.. I think I see it now how they could be signed integer.. Its funny how much stuff you can miss when you're stuck thinking on your own about problems.. ^^; And, about the medley.. Its quite possible they imported those from the older games, and thus that they'd use the commands differently.. While Northern Desert was written for EoS/D/T.. I'd rely more on examples straight from this game, rather than based on stuff that might just come from an older system/toolset.. I mean, In northern desert, 0xE3 is expression. While in your example from the medley, its 0xE0.. There's a pretty big contradiction here.. Most likely because the GBA only handled channel volume, and not expression.. And about the drums, from looking at things quickly, they seems to possibly be assigned to notes within one of the SWD files (either the accompanying SWD, or the bgm.swd). To simulate GM MIDI drums probably.. I think the way it works is transparent to the SMD and handled in the SWD. Like, there are no different commands for the end-user to use drums, and its the drums that are twisted around to work like a regular instrument..

I rarely saw anything else that was limited between 0 and 127.. I think they hate signed integers.. For example, I just re-confirmed that 0xE8 was track panning, and it ranges from 0x0 to 0x80, with 0x40 being the middle. They're not doing things conventionally it seems.. And its not just SSEQ that's different, PMD uses a entirely different development toolset apparently. Most of its file formats were found in other games as well. But strangely very little tools have surfaced to deal with those.. I also found some more details on Expression and Volume in the MIDI guidelines on page 10 : So maybe its actually the opposite ? 0xE0 is the volume, and 0xE3 is the expression parameter ? Or maybe they didn't read this when they made the music Also, you didn't say anything about the fade-in and fade-out effect that I mentioned, that appeared on the drum when you lower 0xE3 to 0x1F and keep 0xE0 at 0x50. That is a significant difference from the other recording of 0xE3 at 0x73 and 0xE0 at 1F.. And its an effect that is used a lot in music, if we neglect subtleties like that, it will make a significant difference in how the tracks come out. Maybe finding out what's going on here could help prevent future headaches ? You probably wouldn't have to resort to this if we could map the link between the individual SWDs for each SMDs and the bgm.swd file. The actual "static" instrument samples are stored inside "bgm.swd", and those have probably a static ID value. But for the IDs used in each track of an smd file, the "sample ids" seems to vary from one song to another. The ID used inside the smd files are referred in the accompanying swd file, and each swd files that accompanies a smd seems to actually define "instruments" sometimes made up of references to several samples. If you look at the structure, it defines a lot of information seemingly on how to playback the samples most likely from the bgm.swd file, and it maps them to an ID which can be found when looking at the swd file and comparing with the IDs used in the smd file. For examples, I've seen the same string sample mapped to a different instrument ID several times. Not to mention that some samples, like square waves and noise seems to be generated at runtime based on the content of swd files. Of course, I can't say this and be 100% sure of it, given I made many epic fails in my notes in the past.. But given I heard all the instrument samples in the bgm.swd, its a pretty safe bet that its possible to guess instruments that way.

Alright. That's pretty much what I had in mind actually. Do a little like that "GBA Music Ripper" program someone made that also export the samples and all. And I'd really appreciate it if you'd ask him ! After re-testing with a fresh track, 0xE0 seems to have an impact on the volume, but it sounds as if it was an Attack / Release parameter.. You should try it yourself with several tracks using different samples to see what I mean. I got those values : 0x32 ( 0011 0010 ) //Slow release cello string 0x3C ( 0011 1100 ) //Slow release vibraphone like 0x64 ( 0110 0100 ) So I guess its possible that like you've said, its always divisible by 10 perfectly, which is very odd IMO... At first I thought the high nybble and low nybble each contained a value for a different purpose, given a value of 0xFF produces no sounds at all, while 0xF0 does for example.. I've also tried a couple of values for 0xE0 on a drum track from bgm0034 and here are the results (0xE3 is at the default value 0x73): - 0x01 (Completely silent, even from looking at the waveform) - 0x1F - 0x50 (default) - 0x8F - 0xF0 And as for 0xE3 being the channel volume, here is the same track with 2 values of 0xE3 (0xE0 is at the default value 0x50 !): - 0x1F - 0xFF It odd because it seems that unlike 0xE0, when its set at 0x1F, the sound isn't mostly at around the same loudness, but its as if it would "fade-in" and "fade-out" just like the attack / release parameters usually do.. But then again, its impossible to entirely bypass the effect of either 0xE3 or 0xE0, so what we're hearing is probably both combined.. I'll run more tests later, changing both values this time.. I also stumbled on this track from bgm0034, the music for Northern Desert, which happens to make everything even more messed up! There is this cello part that plays and its loudness slowly decays. When looking at the events, we see that after and before each play note events, there are several 0xE3 events in a row, and the value of their parameter increases and decreases in a linear or maybe even sinusoidal fashion : Maybe it simulates some kind of vibrato like effect ? Its worth nothing that, here is only a single 0xE0 event at the beginning of this track. Thanks ! I'm just asking anyways, out of politeness. Some people might find it rude, so I'm not taking chances Well, considering MIDI is everywhere, in the keyboards musician uses, in the DAW they use, and in music notation software, and also how this console is post 2000s, its highly likely the data was either stored as a MIDI clone, or as a MIDI file itself before being converted. Its just way too practical not to go for it. But I guess some devs might still use trackers. I doubt its really all that common on the NDS though, given how they need to train their staff to use new software everytime. While with MIDI they can use anything they're accustomed with.. It just makes sense to me, that's all. I don't claim its necessarily the case either though. That's actually a good guess! I wasn't sure of the exact frequency of the ticks or how many there were per beat, but that could really make sense! Speaking of which, there are 2 values that I thought could be linked to timing in the songs. They're at offset 0xE and 0xF in each smd, and their exact value is repeated in every single tracks preceded with an event code 0xAA and 0xA9 respectively.. I'd guess it might be the duration of the track, but it doesn't make much sense, given the duration could be obtained from the longest track anyways Those two values have been really puzzling.. I don't know if you've found out what they do yet, since I haven't had the time to sit down and look at your notes in-depth yet. So sorry if you've already documented those. Well, I guess that works too! That reminds me I should really switch completely to GCC one of these days.. MSVC2012 has an absolutely horrible support for C++ 11.. There are actually some serious and breaking issues in their implementation of the STL.. Like std::packaged_tasks can't take functions with a void return type for some reasons.. And there are even worst than that.. It doesn't even seems like most of those were fixed in VS2013.. And they don't make any patches for those things..

Also, I cleaned up and organized everything and put it on Codeplex : https://ppmd2utilslib.codeplex.com/ I'm don't know how much work I'll be able to put on that page, given I'm not entirely trusting any web-services like that fully.. I've heard waaay too many horror stories.. And the fact that they've initialized my repo at revision "35230" doesn't really reassure me..

Nice work ! I was going to write a little something to attempt converting to midi. But, I was busy with the sprites (Which I still have no ideas how to guess the resolution from those..) Ironically though, yesterday I got some enlightenment on what a few messages codes meant, and on the delay between notes, and updated a little my notes, which were not very accurate ^^; I'm under the impression that, the delay that can optionally be prefixed to events is probably dependent on the tempo. So that might be one of the issue you're having. Also, if you want, we could probably split tasks, so we wouldn't all work on the same thing! Since you got smd well on its way, I could probably focus on the swd that contain the samples? I made some nice finds on those recently ! Speaking of which, you wouldn't happen to know of a good library of re-usable code for decoding whatever format of ADPCM the NDS is using ? I tried writing my own algorithm, but, it only gives static.. I had some success exporting samples using Audacity's Dialogic/VOX ADPCM decoder to read the samples in PMD:EoS, but, I can't find code for any of that, and I'm pretty sure they didn't use Dialogic's specification for encoding those.. Probably something close, but not the same.. Yeah, I knew about it not guessing it just like that, but I didn't bother updating the notes until yesterday ironically ^^; I noticed that the ( 0100 ) bit in the high nybble was always 1 when there were two parameters. Really sorry about that At one point I was pretty much convinced nobody besides me would use those notes What do you mean though ? 0xE3 is for the channel's volume. While 0xE0 seems to have some echo/reverb-like effect on the notes. I'm just asking, just to make sure I'm not missing something. And would you mind if I'd update my notes with your findings, and your own notes ? I'd mention that you contributed of course ! No problems And if you try the PX extractor, you might be able to extract those BGs! You just need to find them in the game files first ^^; Though, I think Nerketur could probably figure out what is the id for the scripts related to sharpedo buff, and in turn make it easy to find the associated BG. Also, I don't recommend using a disassembler to figure out this stuff, well at least with PMD2. It would have been way more trouble than it would be worth it What I did was simply look at the midi format, and think, "what do I need to play music in a sequencer?", basically.. I just looked at the features that midi offered, and looked for values that would fall within the same range in the smd file. And since most sequencers are event based, it was easy to guess it would be the same thing here ! Especially since they probably wrote the song in midi first before transferring it to the game. Which meant they'd logically want something that supports all common midi features! And, if you want to guess what all events do, I strongly suggest taking an existing song in the game, removing all tracks but track 0 and another one. And just replace the content of the track that isn't track 0 (unless you really want to) manually with what you want to try, set the file length in the header, and set the track length in the track chunk, properly set the end padding of the track. And there you go, your own poor man's sequencer ! I'd have tried everything out myself, but I wanted to focus on sprites, and other file format first. But its probably the best way to do, even though its a little time consuming. I'll also say that, plugging in my midi keyboard and just looking at the events and trying to play what notes the track seemed to contain along with the actual music revealed a lot ! And I transcribed a few of them by ear, so it made things easier https://dl.dropboxusercontent.com/u/13343993/MyMidis/idwtsg_49.ogg https://dl.dropboxusercontent.com/u/13343993/MyMidis/otbad_6.mp3 https://dl.dropboxusercontent.com/u/13343993/MyMidis/Main%20Menu.ogg Those are probably not 100% accurate, but if it can help, I could probably share the midis for those !

I should have included the ".pdb" before to make debugging easier I guess ^^; Here's the version with the pdb / symbol file (its a zipped 7z, because zip couldn't make it small enough, and the forums doesn't like 7z files): Its kinda odd you'd get a division by zero error like that.. It should crash way before it does any divisions.. D: I'll have to look into it.. And yes, its more or less up to date. But I mean, with the new findings, the meaning of a bunch of things in there could change radically ! So take anything in there not as the absolute truth. EDIT: Its funny, I can't find the file you've mentionned "GROUND/v21p05a1.wan" I can only see "/GROUND/v21p02a1.wan". Are you using Explorers of Time / Darkness ? EDIT2: I traced back where it crashes. It was actually something I left in there to notice any unusual total image size.. Its because it stumbles on a 256 pixels image, and I never saw one of those inside a sprite file before.. So, we got another discovery EDIT3: I made a more graceful error handling: https://dl.dropboxusercontent.com/u/13343993/my_pmd_utilities/tmp/Debug_SpriteEx.7z Its compiled in debug currently, so its noticeably slower. It shouldn't die on 256 pixels sprites anymore with the changes I made. It will throw an exception on never seen before images sizes ! ppmd_sprex_broken_debug.zip

Thanks, and yeah, those are most likely the ones that are wider than their height, and that's the reason why I named the thing "broken" because I currently have no way of figuring out the resolution, other than guessing from the total amount of pixels. That's an interesting find! That means that maybe comparing those with the others sprite files that works might reveal what part of the file mentions format specific info ! EDIT: I just thought about it, but, is there any particular error messages that pops up when the program stops midway ?

Anyways, here's a not fully working version of the sprite extractor for those interested. Once we find out a sure fire way of telling the images' resolution, I'll make an "official" non-broken release and put it in the first post ! It works just like the last utility I posted here. Pass an input path, and optionally an output folder. Or just drag and drop a sprite file contained inside an SIR0 (Those are currently extracted with the extension ".sir0" by my extractor(but a lot of non-sprite files can get a ".sir0" extension!), but elsewhere in the rom's file, they have a ".wan" file extension, and I think I even saw another with a different file extension.. But the utility will extract frames from those as well !) Oh, and the images are exported as indexed 8bpp PNGs. And the palette is included in every resulting PNGs! There you go: If there are any bugs, and if anybody finds anything about the sprite files, please lets us know ! ppmd_sprex_broken.zip