Bandai Namco .lopus Encoding Troubles

[ThatNintendoNerd]

Using a .lopus file from VGAudioCli in Super Smash Bros. Ultimate appears to be mute in-game. With the following corrections, I was able to modify the output with the below to make the file somewhat usable:

• Offset 0x1F should always have a value of 0x10
• Offset 0x4A should always have a value of 0xA8
• The 32-bit integer for offset 0x5C should always equal 0x78000000

I used "somewhat usable" because after these corrections, the audio will only play for a few seconds and just cut out entirely after. I have a hunch that offsets 0x24, 0x64, 0x68, and 0x6C are the last possible cause for the issue mainly because I haven't corrected these and can't figure out what they actually define.

I would also like to note that starting from offset 0x68, it contains the value 0x000000A0, which then that value follows to 0x110, then 0x1B8, 0x260, and etc. This is missing in encoded .lopus files from this application.

I can try to provide more information or clarifications you need, if necessary.

---

Edit: 0x24: Seems to be an offset. It splits the change between using 0x0000000A to 0x000000F0. 0x64: Seems to also be an offset in little-endian format. It's 40 bytes smaller than the value of offset. 0x6C: All I can say is it's little-endian.

[Thealexbarney]

The first 0x40 bytes is Namco's own header format. Everything from 0x40 on is the standard Nintendo format.

One thing you could try is unpacking and repacking Nintendo's Opus format with Namco's header. If that works then it's nothing to do with the headers. VGAudioCli original.lopus repacked.lopus --opusheader namco

Offset 0x4A is the size of each Opus frame, or 0 if the stream is VBR.
0x5C - Preskip sample count 0x64 - Length of the Opus stream data 0x68 is where the Opus stream data begins 0x24 - Length of the Namco container's data

[ThatNintendoNerd]

Sorry for the late-ish response. I'm pretty limited to testing since I need someone else to test for me.

I did try repacking, and the output had a result of 0x1F and 0x4A being 0x00, but the most major difference being everything after from the offset listed in 0x24 being wiped. Though after the two byte corrections, the wiped data seemed to have caused no playback issues as far as I can tell.

It seems the headers do partly contribute to the mute issue. The value of byte 0x4A still needs to equal 0xA8 instead of 0x00 otherwise the audio is mute the whole time. Byte 0x1F doesn't appear to affect anything, but in my opinion I think it would be best to correct it to be 0x10 instead of 0x00 for accuracy purposes. In custom .lopus files, 0x5C either as 0x78000000 or 0x38010000 also doesn't appear to have any effect on how the audio plays.

However, even after correcting these bytes, most of the audio is still mute after a few seconds, which then leads me to believe it's an issue with how the tool encodes the stream data.

---

Edit: It seems all outputs I've tried stop at around seven seconds in-game. Same place, too.