[Solved] DanceDanceRevolution MAX-EXTREME (AC) .SBS files

[pm41224]

Hey guys. I would like to present to you these weird file types used throughout the arcade DDR series - mainly from DDRMAX -DanceDanceRevolution 6thMIX- to DanceDanceRevolution EXTREME (all released in Japan) - but the sample files come mainly from DDRMAX.

That said, is it possible to decipher anything from this file format? If this is a sprite-type file assembled from still frames, how can I go about ripping the frames from said file?

If this is the wrong place to post this topic in, I could post it in Audio and Video file formats.

Thanks in advance.

[pm41224]

Short Bump:

I suspect that these .sbs files might be background animations that play during a song. For example:
https://youtu.be/c59t9OZiImM?t=72
(can't play video directly so you'll have to click the link, but basically it's DDRMAX AC gameplay showing the background animations)

The animations clearly have .jpeg artifacting. Of course YouTube compression makes the artifacting look worse than it actually is.

[BloodRaynare]

Was this one is still using PS1-based hardware?
Because in your sample I saw a MDEC encoded data (FYI MDEC are the video codec that used in majority PS1 games for FMVs, and it's actually derived from MJPEG, so those JPEG artifacts you've described is correct.)
The only problem is it's header are completely custom, so jPSXdec unable to scan anything from it.

[pm41224]

Was this one is still using PS1-based hardware?
Because in your sample I saw a MDEC encoded data (FYI MDEC are the video codec that used in majority PS1 games for FMVs, and it's actually derived from MJPEG, so those JPEG artifacts you've described is correct.)
The only problem is it's header are completely custom, so jPSXdec unable to scan anything from it.

System 573 is based on the PS1, and DDRMAX to DDR EXTREME run on System 573 Digital, a variant of System 573 in which a digital I/O board is used.

If I'm not mistaken, the custom header indicates that this file format seemed to be Konami's way of compressing the MJPEG frames, which is weird.

[BloodRaynare]

System 573 is based on the PS1, and DDRMAX to DDR EXTREME run on System 573 Digital, a variant of System 573 in which a digital I/O board is used.

If I'm not mistaken, the custom header indicates that this file format seemed to be Konami's way of compressing the MJPEG frames, which is weird.

If you still following this thread...

It wasn't a custom header actually, it's still identical to standard PS1 STR format, it's just the first 0x20 bytes of the STR sector header in each 0x800 chunks was removed, and those header was responsible for things like dimensions of the video stream (Width x Height), frame numbers, and other stuff, anyway you can read more about the STR format here: https://github.com/m35/jpsxdec/blob/rea ... format.txt

By adding those sector headers, jPSXdec was able to scan the files as a PS1 STR video stream, the problem is looks like your samples has a varying width sizes (but the height sizes are identical from what I've seen so far).

Here's one of the first frame I've managed to extract from the SBS file (This one is from JABAKA.SBS)

[pm41224]

So it turns out Konami removed a bunch of sector headers. That's also weird, I thought it looked custom to me.

As for the varying width sizes, I assume that the frames are stored in a way that they were cut into pieces?

Anyways, thanks for the work of getting that sample frame extracted.

[BloodRaynare]

So it turns out Konami removed a bunch of sector headers. That's also weird, I thought it looked custom to me.

As for the varying width sizes, I assume that the frames are stored in a way that they were cut into pieces?

Anyways, thanks for the work of getting that sample frame extracted.

After some more fiddling, turns out I kinda goofed on the frame header :p
The frame header only appears at the sector 0 of each frame data (absolute offset 0x10 after the sector headers), the rest of sectors for that frame after 0 are just sector headers. Stupid me for including the frame header on each sectors after it, caused it to get decoded as well, thus producing garbage on the width of the video. So, the width was actually the same on every SBS files, which is 304 pixels and the height is 175 pixels.

Here's it how one of the frames actually should look like (Again, from JABAKA.SBS)



Another example, this time from hwfroa.sbs

[pm41224]

I have to thank you once again for your work on decoding these files and owning up to the goofs you made.

These look good even with that MJPEG crust, which is to be expected.

[pm41224]

Bumping this thread to throw a curveball. I've got another sample file - D30F_8S.SBS - which was used in DanceDanceRevolution USA, which like other variants of DanceDanceRevolution 3rdMIX also runs on System 573 Digital. I believe it was used as the opening FMV for this game.

Unlike the other samples files I gave you, this one, I think, is in a 4:3 aspect ratio and is probably at 320x240 resolution.

https://www.dropbox.com/s/hlh77tgr7pnurvr/D30F_8S%20%28raw%20extraction%29.zip?dl=0

[BloodRaynare]

Can you extract the SBS file in a 2048-bytes sector mode? Because, I actually have written a bms script to convert it into a 2352-bytes STR, which then would be playable in jPSXdec. But, I guess I'll have to write an another bms script just for this one.


EDIT: In case you're interested, here's the scripts to convert the SBS files into PSX standard STR video file

sbs_scripts.zip

Use QuickBMS to run the scripts. Then play the resulted STR file with jPSXdec
Usually, sbs.bms is enough to convert the files, but in case jPSXdec fails to scan the files properly, use the sbs2352.bms variant.
It's not an accurate representation of the real Mode 2 Form 2 files though, for example the ECC datas are replaced with 0xff dummy value, but jPSXdec won't really care anyway.
I also included the optional 2352to2048 script to convert the 2352-bytes sector files into a 2048-bytes one (Like your current SBS sample).
I know it's redundant to convert the files that already has 2352-bytes sector, but it's much easier since the SBS files seems to have a constant frame data size, at least with a 2048-bytes sectors.

Note: You probably want to edit the "WIDTH" and "HEIGHT" fields inside the scripts first to suit your files.

[pm41224]

Will do!
https://www.dropbox.com/s/iquxds8uwwv0ywr/D30F_8S.zip?dl=0

Also, thanks for writing that script. I'll test it out when I have the time.

[pm41224]

UPDATE: I just tested sbs.bms on a few .SBS files from DDRMAX (AC) using the following WIDTH and HEIGHT settings.

Code: Select all

math WIDTH = 304
math HEIGHT = 176

While some of the .sbs files converted to .STR just fine, a few others... didn't. Here's JABFCA.SBS, as an example.

Code: Select all

C:\Users\Harrison\Documents\QuickBMS>quickbms C:\Users\Harrison\Documents\QuickBMS\sbs_scripts\sbs.bms "C:\Users\Harrison\Documents\sm randommovies\DDRMAX - SBS\Problematic Files\JABFCA.SBS" C:\Users\Harrison\Documents\QuickBMS\sbs_output

QuickBMS generic files extractor and reimporter 0.10.0
by Luigi Auriemma
e-mail: me@aluigi.org
web:    aluigi.org
        (Apr 28 2019 - 07:25:07)

                   quickbms.aluigi.org  Homepage
                            zenhax.com  ZenHAX Forum
                     @zenhax @quickbms  Twitter & Scripts

- open input file C:\Users\Harrison\Documents\sm randommovies\DDRMAX - SBS\Problematic Files\JABFCA.SBS
- open script C:\Users\Harrison\Documents\QuickBMS\sbs_scripts\sbs.bms
- set output folder C:\Users\Harrison\Documents\QuickBMS\sbs_output

  offset   filesize   filename
--------------------------------------

Error: incomplete input file -1:
       Can't read 2 bytes from offset 00001f76.
       Anyway don't worry, it's possible that the BMS script has been written
       to exit in this way if it's reached the end of the archive so check it
       or contact its author or verify that all the files have been extracted.
       Please check the following coverage information to know if it's ok.

  coverage file -1  100%   8054       8054       . offset 00001f76

Last script line before the error or that produced the error:
  59  log MEMORY_FILE2 CURRPOS_MEMFILE 0x7e0 MEMORY_FILE

I made sure to rip it using jPSXdec at 2048/bytes and even did a second rip of that at 2352/bytes, for which I have not tested the 2352 scripts yet.

[BloodRaynare]

While some of the .sbs files converted to .STR just fine, a few others... didn't. Here's JABFCA.SBS, as an example.

I made sure to rip it using jPSXdec at 2048/bytes and even did a second rip of that at 2352/bytes, for which I have not tested the 2352 scripts yet.

Send me the problematic file

I'll bet the problem lies on the "FindLoc" command, as I assumed that the only four bytes of zeroes is enough for the heuristics detection of the frame sizes, looks like I'll have to make it to scan the whole 0x10 bytes.

EDIT: Okay, just "obtained" the DDRMAX CHDs myself, and I see the problem now. One of the frame data ends with 0x00 values, and this threw off the frame data size detections, because the sizes should be dividable by 0x10, I'll push the version 2 of the scripts shortly.

EDIT 2: Here's the V2 scripts.

sbs_scripts_V2.zip

[pm41224]

Thank you so much for the V2 scripts. I'll send the sample file (JABFCA.SBS) anyways.

This is the one that was ripped at 2048 rather than 2352.

EDIT: I will test these scripts on all the .SBS files from MAX, MAX2, EuroMIX 2 and DDR EXTREME. Will eventually report back with the results.

[pm41224]

BUMP: Tested the script on every .sbs file from DDRMAX, DDRMAX2, Dancing Stage EuroMIX 2, and DDR EXTREME. They converted to .str except for these files below.

DDRMAX2 -DanceDanceRevolution 7thMIX-:
jebrne
jehnzb
junyca

Dancing Stage EuroMIX 2:
junyca

DanceDanceRevolution EXTREME:
jcligh
jctrof
jmbrne
junyca

Across all three of the listed games, junyca did not convert to .str properly. The problematic files (in zips labeled with "did not convert") are linked below.

[BloodRaynare]

Here's the V3 of the scripts, I improved the search pattern of the end marker of the frames data.

EDIT: Had some mistakes on the script, if you already downloaded the previous one, please redownload.

sbs_scripts_V3.zip

[pm41224]

Tested the script on the very files I sent you and... it worked like a charm!

Thank you very much. The third time was the charm.