Needing help hacking The Thousand-Year Door

[LaDestitute]

I've been screwing around with hacking The Thousand-Year Door and so I've been using gcrebuilder along with jackoalan's custom-build of Audacity to modify the .stm files for the game's BGMs. I'm rebuilding from a root folder exported from a fresh ISO and I always repack/rebuild the root folder to a custom ISO. I'm also using the latest stable of Dolphin (5.0 x64), too.

Problem is, when the game gets to a point where the custom music I inserted gets to the end of it's loop, it crashes and makes a horrible buzzing noise until I close or kill the process. Any idea of what might be doing this from the replaced music and how I can fix it?

I've narrowed it down maybe, since the custom music .stm(s) I inserted technically work, I can hear them in game, short of the crash/softlock I get. I've taken precautions such as making sure it's stereo, that I include the loop label, 32000Hz, 16-bit PCM: but I'm not sure if the game is so fussy about some of those specific details in order to get the custom music working without any crashes or softlocks. I don't think it is for Hz or bitdepth as for requiring 32000Hz or 16-bit PCM but I like being better safe than sorry.

[emu_kidid]

You probably need to make sure they're the exact same file size (or smaller) as what the game intended.

[LaDestitute]

I've tried that, was able to load and run the iso using files smaller than the original .stms. I know they can't be bigger as gcrebuilder refuses to import .stms bigger than the original.

Even tried to have a .stm the same size as the original (as for example, the normal battle music .stm is 1.30 Mb), and that still caused it to crash. I suspect it's the loop label in Audacity, but I'm not sure.

I might have to take a look at some of the other files in the root directory. There is maybe some kind of database/file/etc that dictates when to loop? Just making guesses. I do have a somewhat clear idea of what's what in the sound folder though. Someone did an analysis of everything there and for example one, the audio-sample file is just used to hold...sound effects and not instrument samples. How weird, isn't that.

[Aleron Ives]

Have you tried extracting the entire ISO and then building a new one with the modified file? I'm kind of skeptical that the music must be identical to the original size, but at least you could test having a larger file this way. Another thing to try would be to instruct the new music file not to loop at all. If the music stops and you just get silence, rather than a crash, it would implicate Audacity for setting improper looping instructions. You could also try copying and renaming an existing original music file and see if the game accepts and plays it as the music for something else.

[LaDestitute]

Yes, I take a fresh ISO copy of the game, extract the root to a folder and then I use the root and my modified files to rebuild a custom rom.
I'm not sure how to instruct the new music to not loop, though. It's just as simple as deleting the label that tells it to loop? Someone else provided a copy of the .stm for the title menu that was modified (instead, it was the naming music from EarthBound) and that one had no loop label data at all in it's own .stm. I tried to put that into the rebuilt rom and it still made the game lockup and error.

I tried to replace the battle music with Doopliss Battle .stm file by renaming it to the name of the normal battle .stm, and it works just fine. No crash and it was able to loop, so yes, I think Audacity is applying the loop data or/ metadata incorrectly. I also tried removing the loop label from the modified music, and it still crashed. I suspected it was Audacity as I have the vgmstream plugin for Winamp, and I attempted to use Winamp to play and/or read the metadata for modified .stms, it doesn't even play or give me the metadata popup when I rightclick to select it.
If I suspect it's indeed the looping data and/or metadata, I may need to research further for a way to fix that. I would figure hex-editing the modified file, but there's probably an easier way.

Edit, metadata for the .stms, with the normal battle music as example:

sample rate 32000 Hz
channels: 2
loop start: 55944 samples (1.7483 seconds)
loop end: 1169000 samples (36.5313 seconds)
stream total samples: 1169000 (36.5313 seconds)
encoding: Gamecube "DSP" 4-bit ADPCM
layout: flat (no layout)
metadata from: Nintendo STM header

[LaDestitute]

Update: It's been fixed. Got in contact with the guy who maintains the Audacity fork and it was a bug with the stm export encoding, which is now fixed in his fork.
As a result, I have these done:
http://wiki.origami64.net/ttyd:soundfolder (documentation for the sound folder in the game's iso root structure)
https://www.youtube.com/watch?v=4NHLh5GkIlY (replacing bgm tutorial)

[Aleron Ives]

Nice! Does he have an ADX fork as well?

[LaDestitute]

Far as I know, all his custom-fork currently supports is .dsp, .csmp, .fsb, .strm, .ras, .bcwav, .gcub, and .rsf besides the .stm format. You could always email him, though, and ask if he could.