Koei Tecmo Sound Bank format? (Final Fantasy Dissidia NT PS4 wbd/wbh files)

[DeathChaos]

Final Fantasy Dissidia NT uses 2 container formats for all of it's audio, BGMs use a g1l wrapper, which actually does nothing, delete the first few bytes of the wrapper and it turns out BGMs are just standard at9 files for Sony consoles.

Voices and Sound Effects on the other hand, seem to be on a .sed container, with the bms script made for another game (Fatal Frame: Maiden of Black Water) found here ( http://aluigi.altervista.org/bms/fatal_frame.bms ) and changing the endianess from Big to Little made it successfully unpack everything inside the .sed, in most cases it spits out 2 files, one "small" file with a header of _HBW0000, which I assume to be WBH_0000 due to endianess, and a "big" one with a header of _DBW0000, or WBD_0000.

They both seem to be linked somehow, WBH seems to contain file IDs? While the WBD file would be a sound bank of sorts, maybe with headerless streams?

Here are some sample .sed archives from the game, If anyone could help figure this out I would really appreciate it.
https://cdn.discordapp.com/attachments/ ... oice_e.sed
https://cdn.discordapp.com/attachments/ ... tvoice.sed
https://cdn.discordapp.com/attachments/ ... oice_e.sed

[corruptturret]

Fire Emblem Warriors for the Switch has files in a simple container format (.bin.gz, 4 bytes for entry offset little endian, 4 bytes for entry length little endian)
They contain a small file with header "_HBW0000" and a larger file with header "_DBW0000" and are probably SFX.
Same problem here.

[DeathChaos]

Well our problem is a bit different.
We managed to figure out that our wbd section files are just headerless at9s, the header is made with a combination of data from the wbh section and some hardcoded data on the eboot, so unless someone who knows how to dig into the eboot decides to help we're kinda stuck on this.

We know they're headerless at9s because we gave it an at9 header from an existing at9 and go the audio to play (but it sounds very broken due to wrong header info).

[corruptturret]

I used the script as you said for your first sample file, but the second extracted file had _DBW0000 at 0x5c (92 bytes in, not file start) for some reason. Started with 0x80bb0000 and some other data. Is that encoding 48000 khz... Also, the 4 bytes after the _WBD0000 header give the correct content size (as do the _WBD files in Fire Emblem). Strange. Looking at the original archive, kind of looks like 96 bytes are missed at the end. Last 4 were 0x00, so more like 92 missed bytes of value (as noisy as the bytes actually extracted). The other two _DBW files seemed similarly offset. Something's off with that script.
I'm assuming Fire Emblem _DBW files are headerless KTSS streams seeing as KTSS streams are the only audio format I've encountered. I have no idea how entries in _HBW files are structured at all. Nor do I know of any KTSS documentation.
Looks like I'm SOL.

A few notes

In the Fire Emblem _HBW files I'm looking at, 0x0c-0x0f is "KWBN" while your sample says "K4HD"
Fire Emblem _HBW files seem to have a constant 0x00 64 68 00 at 0x10 while yours have 0x38 00 00 00
Fire Emblem _HBW files seem to have a payload length at 0x14-0x17 (little endian ofc) as it's the _DBW file length minus 12 bytes for the header (which uses 4 bytes for file length). Your samples do something else.