The DDR Research Master Thread - UPDATED 2023-04-15 - Minor Addition - SOME DDR GB1 Memory Addresses

n Konami's LZ77 format, periodic "control bytes" are inserted every eight bytes or so

You're quite welcome, travelsonic! Thanks, in turn, to root670 on github, and to the comments they added to their version of the decompression code (https://github.com/root670/ddr-tools).

Not really. I've seen structures like those pretty much only from what I've read in this thread. In fact, I did try compiling and running Dwarf2CPP on some of the games' ELF files, but it kept crashing when trying to write the second file (which always happens to be les_sel_lv.c). I also gave Ghidra a try to decompile the ELFs and/or arcade binaries, but no such luck at the moment.

On the plus side, I have finally figured out how the video filenames are encoded at the end of the scripts. First, since the system reads 32-bit values like these in little-endian, we will need to reverse the byte order before converting the video's hex code to binary (using jrlova/MAX1.avi as an example):


Once we have our binary string, split it up into groups of 5 bits each. There will be two spare bits left over; these can be ignored. It is important to remember that bits are read from right to left, so start from the right end, like so:


Now that we have our binary string cut up like so, we can translate it into letters. Simply convert each binary slice into a decimal number -- again, starting from the right -- and convert that number into a letter, starting with 0=a, 1=b, and so on through 25=z.


And there you have it!

If you're asking about just extracted the data itself from the PS2 DDR discs, I used the filedata-tool.py Python script from https://github.com/root670/ddr-tools.

I should probably make a fork of that repository sometime, and add in the scripts I created myself. I'll let y'all know once I get to that.

Jumping back to the topic of debugging and the DWARF headers, I was able to compile that DWARF-to-CPP program (once I downloaded a newer fork of that repository) and generate all the DWARF C files from some games. Having done so, does anyone know how to use them, or the debug symbol files posted by root676 a while back (https://zenius-i-vanisher.com/v5.2/thread?threadid=7564&page=16#p436618), in Ghidra? And when I import the games' ELF files, what language should I read them as? I'm pretty sure it's one of the MIPS 32-bit languages, but I'm still fuzzy about little/big-endian and other options. Pardon my questions; I'm still kind of a total noob when it comes to Ghidra.

The first byte contains a bunch of flags which affect timing.
- If the lower half of the byte is 3, (i.e., the byte ends in a 3), pause the clip.
- If the lower half is 5, play the clip normally.
- If the lower half is 6, play the clip normally, then in reverse, and so on.
- If the lower half is 9, play the clip in reverse.
- If the lower half is A, play the clip in reverse, then normally, and so on (opposite of 0x_6).

- If the upper half is 1 (i.e., the byte starts with a 2), play the clip at normal speed.
- If the upper half is 2, play the clip at 0.75x speed.
- If the upper half is 3, play the clip at half speed.
- If the upper half is 4 and the third byte is 0x00, play the clip at 1.5x speed.
- If the upper half is 4 and the third byte is not 0x00, play the clip from start to finish for a given length of beats specified in the third byte, adjusting the speed as necessary. In this example, a value of 0x04 means the clip will play start-to-finish within 4 beats at the song's current tempo, while 0x08 will make the clip last for 8 beats, or at half the speed of 0x04.
- If the upper half is 5, play the clip upon finishing the previous one. Used when the accompanying beat entry is a duplicate, for seamless off-beat transitions. If the previous entry has specific timing instructions, they are carried over to this entry.
- If the upper half is 6, start the clip at the frame specified in the third byte.
- If the upper half is 9, display the song's BG image. I don't know what effect, if they, that the other bytes have here.
- If the upper half is A, play the clip at 1.5x speed.

The second byte points to which video clip will be played, as described in the section below. However, there are some exceptions:
- 0x14 represents the song's background image, typically shown at the end of the song.
- 0x15 through 0x1D represent shared generic videos. Most of these were replaced from MAX2 onwards.
- 0x66 and up represent console-exclusive videos, such as those used in Kind Lady or So In Love. Like the common videos, these are not included in the section below.

The third byte controls the video clip's speed. All clips are 80 frames long and, at least for NTSC-region games, play at 30 frames per second by default. This works out to running for four beats at 90 BPM. However, they can also be sped up to match the BPM of the song and play for a specific number of beats. In this example, a value of 0x04 means the clip will play start-to-finish within 4 beats at the song's current temp (about 130.1 BPM).

The fourth byte is not used, at least as far as I have seen so far.

There has to be a way to get the clip to start at a specified frame and also play at a specified rate. One example is teapot1, or the second half of jcteap. In Odoru Ponpokorin in DDR Festival, it looks to be going at 140 BPM just fine without also having drawer1 attached to it.

Well, now that we're talking about CS games, I'm still trying to figure out where the files are in the PS2 structure.

- In the Arcade games, the data is in GAME.DAT, and its file table is at a specific address in that file (reading sys573tools, it's 0xFE4000). The actual executable, aout.exe is in it.

Is there any info on where the code for determining judgements and the corresponding timing windows are in the various mixes? I've been wondering whether the algorithms have changed over time (both on console and arcade versions).

If Sesse's analysis is correct, we should observe some jitter in judgement evaluations in game, since the windows are not an integer number of frames. By aligning 150 Hz ticks with 60 Hz frames, we are able to enumerate all the possibilities of frame alignment: