Thank you VB2RIP

Vb2rip is a program that was developed many years ago by a guy named Neill Corlett, and can rip from Playstation 1 and 2 games various audio files, including .xa, and the vb2 format, which is used in pre-SuperNOVA DDR mixes.

This matters in my hacking research for one important reason:  It is open source.

Why does this matter:

A brief story:

I was trying to extract audio with this program one night, unfortunately the Chinese food I ate for dinner wasn't agreeing with me.  Whilst in the bathroom, where it seems a lot of good ideas come from funily enough, it struck me.

If the tool can extract .vb2 files from Dance Dance Revolution games, and convert them to .WAV format... then the reverse can be done too!

That means being able to convert an audio file in the same .wav format as what would be extracted into a vb2 format audio piece and inserting it over another file of the same size.

This also means that with some tweaks the program can be modified to output actual file locations, and file sizes for the vb2 format files... and even modified further to do an "export for editing" / "replace audio" [of the same size, of course]deal - such capabilities already possible when working with PSX TIM format images... or at least uncompressed TIM images.

Oh god, now I got another project I want to do.  >_<

That rating does not belong there...

As previously discovered by members of the AIJ community, the song wheel foot rating definitions are by default listed Standard/Light/Oni/Heavy, with 4 bits [1 nybble] per value like so:
[S][L][O][H][0][0] - though it wasn't previously known that each set of foot ratings, singles and doubles, are stored in 32 bit words - with the last 2 nybbles empty for each set [altering them does nothing].

For songs without Oni charts, and Oni-only songs, you can in fact fill in the nybbles for the "missing" ratings with data - doing so will allow you to change to that foot rating/difficulty on the song wheel.

What happens when you select your song w/ the nonexistent Oni steps?

Well, this:

 

The game does not crash.  The song starts playing, and the background video script plays normally.

Because of the lack of steps, however, your grade is dismal. 

[Get it?  Dismal?  D letter grade at the end?  Oh forget it.]

Now to decypher the info...

It is very strongly looking like, at this time, the information I found in my previous post, in the DDRMAX2 JP ELF is correct, and this is a symbol table.

Now to see if SONY deviated from ELF standards or not at all, and then figure out how to use the data, get addresses, etc.

Big screenshots below of the data being looked at.

Debugging information left behind?

Looking at the stuff I posted yesterday, I noticed that around 0x17f5f8 in the SLPM652.77 file are the following strings:

shstrtab debug line strtab symtab comment reginfo

I can only assume debug is just that, debug information, strtab has to do with a string table of some sort, and symtab is something rather exciting, that is, a symbol table.

If that is the case, call me excited - as this would change everything in my progress.

Symbol tables, for those of you who don't know, are created when an assembly file is actually assembled into a functioning executable. Basically, it consists of where a label occurs - for a function OR variable - and the address where it is located. During the assembly process, as the assembler parses the file[s], it will find the first instance of a symbol, record that and its address, and then as it parses further replace every occurrence of the name with the recorded address. 

It isn't too often, if ever, that this information is retained... but when it is, it makes reverse-engineering much easier.

I noticed that every version of DDR from MAX to EXTREME, JP OR US, has this information tacked on at the end of the executable [SLUS###.##, SLPM###.##, etc] - I would bet that includes Dancing Stage mixes from that era. 

Variable labels? Variable lables really?

I was searching through the ISO image of MAX2JP when I was curious to see if, like the other songwheel slots, there was a definition for the roulette slot.

I saw all sorts of labels that looked at first glance like variable names at what I later figured out was the bottom of the SLPM file.  I was too lazy to figure out how to copy just the ASCII from FRHed, as opposed to the bytes of data, so I opened the file in wordpad, collaged together a couple of screenshots from sections of these labels, saved it as a png file:

If these are what I think they are - and there are A LOT more than this - I am hoping there is a way to retroactively apply them to my disassemble, and USE them, as this would go a very long way to being able to decode the game.  Doesn't seem to be all too often that variable names, etc are left in the compiled program.

Not dead... just busy.

I've been busy working on an inventory database for my 'rents' business - which has been nothing short of a pain in the ass between pressure to get it done, the changing deadlines, the changing requirements forcing me to go back and add stuff in every piece of code I made.... ON TOP OF the designing, coding, bug testing/fixing, etc... ugh.

I have found references to sound file data for DDRMAX2JP, and not just the ASCII strings - but what I think is where those strings are used to load the data.  I will hopefully explore that sooner than later.  I am very excited to see these references to the sound data files in the disassembly I'm using, as that means pretty soon I may be able to figure out how to make games load data from others - PARTY COLLECTION loading data from MAX, MAX2 loading EXTREME, etc.

Stay tuned!