Sample Level Not Always Exported into Debug SoundBank TXT
L-Spiro opened this issue · 21 comments
Open Super Robot Spirits in N64 Soundbank Tool.
Check Debug.
Press Write All DLS Soundfont Banks.
Export to any folder.
Open the created file, ExtractedSoundbank_00.dlsDebug.txt.
Notice that Instrument 04 correctly reflects the Sample Vol value:
Sample Vol = 6E and 73, debug file contains Attenuation 03320D13 and Attenuation 03128978.
Now look at Instrument 06, which has Sample Vol = 55, but the debug file has Attenuation 00000000.
Debug file should contain Attenuation 0383E26E here.
Just to be clear, youre referring to https://github.com/jombo23/N64-Tools/blob/master/N64%20Soundbank%20Tool/N64SoundbankToolDlg.cpp#L1710 ?
I am referring to the debug line that looks like this (example taken from Instrument 0C since that happens to be on my screen at the moment):
Key Base 35 Fine Tune FFFFFFEB Volume Attenuation 00000000
Within the same export, sometimes it is correct, other times it is not.
What you posted is one of the lines of code that prints the above debug line, but I can’t say whether it is the exact section of code that has this bug. I expect that the bug is there in all sections that print that debug text.
I was asking because your title says "not always", which means that its intermittent, and this is a section of the code where this value is never set to anything besides 0 before its written to the file. Do you have an example of this actually printing the value, or is this not a conditional issue?
The steps to reproduce the issue are in the first post.
Super Robot Spirits.
Instrument 04
[Not in DLS] Bend Range C8
Number Sounds 0004
Sound 0000
Sampling Rate 22050.000000
Attack 80000000 Decay 000236E8 Sustain 03E80000 Release F6A236E5 (Attack Volume 7F Decay Volume 7F)
Pan 60 (00FFE7CF)
Key Base 30 Fine Tune 0000 Volume Attenuation 03320D13
Key Low 1F Key High 20 Vel Low 00 Vel High 7F
Sound 0001
Sampling Rate 22050.000000
Attack 80000000 Decay 000236E8 Sustain 03E80000 Release F6A236E5 (Attack Volume 7F Decay Volume 7F)
Pan 54 (00A16AD4)
Key Base 30 Fine Tune 0000 Volume Attenuation 03320D13
Key Low 21 Key High 21 Vel Low 00 Vel High 7F
Sound 0002
Sampling Rate 22050.000000
Attack 80000000 Decay 000236E8 Sustain 03E80000 Release F6A236E5 (Attack Volume 7F Decay Volume 7F)
Pan 7F (01F40000)
Key Base 30 Fine Tune 0000 Volume Attenuation 03128978
Key Low 23 Key High 27 Vel Low 00 Vel High 7F
Sound 0003
Sampling Rate 22050.000000
Attack 80000000 Decay 000236E8 Sustain 03E80000 Release F6A236E5 (Attack Volume 7F Decay Volume 7F)
Pan 54 (00A16AD4)
Key Base 30 Fine Tune 0000 Volume Attenuation 03128978
Key Low 28 Key High 7F Vel Low 00 Vel High 7F
This is correct.
Instrument 06
[Not in DLS] Bend Range C8
Number Sounds 0001
Sound 0000
Sampling Rate 22050.000000
Attack 80000000 Decay 7FFFFFFF Sustain 03E80000 Release F6A00000 (Attack Volume 7F Decay Volume 7F)
Loop Count 00000001 Start 00000EDC Length 000003F4
Key Base 30 Fine Tune 0000 Volume Attenuation 00000000
Key Low 00 Key High 7F Vel Low 00 Vel High 7F
This is not correct.
It should have printed Key Base 30 Fine Tune 0000 Volume Attenuation 0383E26E.
It printed instrument 4 correctly and it did not print instrument 6 correctly. Correct prints and incorrect prints are spread throughout the file randomly. When Sample Vol is not 0x7F, sometimes it prints the value correctly and other times it does not.
Also, while we are on the topic, Instrument Vol is never printed to the debug file.
This forces me to write code to manually add it to my own files.
#if MW_CUR_GAME == MW_G_BLAST_CORPS
static const uint32_t ui32Table[] = {
0x00, 0x1B,
0x4F, 0x69,
0x50, 0x69,
};
#define MW_HAS_TABLE
#elif MW_CUR_GAME == MW_G_EXTREME_G_2
static const uint32_t ui32Table[] = {
0x19, 0x70,
0x1A, 0x64,
};
#define MW_HAS_TABLE
Looks like its decay related instead of sample volume related. If the decay is -1 it (conditionally) gets printed as 0x7FFFFFFF and it sets the attenuation to 0.
I dont know the reason behind this.
I imagine this is the reason for that behavior:
https://github.com/jombo23/N64-Tools/blob/master/N64%20Soundbank%20Tool/N64SoundbankToolDlg.cpp#L1219
There are a couple areas where that same set of code can be observed, but like i said, i dont know the reason behind it
It is in a few places. In all places it is a bug. It’s saying that if a sample has no decay, then it must play at full volume. That’s bizarre and incorrect. All copies of that line should be removed and then the exports will be one step closer to complete.
Getting the Instrument Vol exported would be another good step, and adding the release rate next to the ADSR values in my other open issue would be the final step. These 3 things make a fully complete set of debug exports.
Im sure there is some reason for it, however, since this is open source youre more than welcome to modify it, demonstrate it actually being proper under all cases, and then submit a pull request. That is, unless subdrag has anything to add.
I can’t even build it…
Can you make a branch and build that I can test? I don’t know if you know what I do with this tool, but it is a certainty that I use it more than any other human, and by a very large margin. If you can put a build in a branch, my usage of it will provide an extremely thorough testing of it.
As for the purpose of that code, it’s a bug in its current form, but its intent would have been as a hot-fix for some kind of issue that must have been observed in ancient days before electricity was invented. I am quite ready to prove that its original intent is no longer even relevant in modern times and that it needs to be completely removed if only I am given a special build.
In 11.5 hours I will be able to give a more compelling reason for my insistency, but for now I can simply say, “I use the tool for professional work and I really really need it to be working properly.”
I don't have the build environment for it set up. Its not my code. ill take a quick stab at editing the binary but no promises.
Its likely because in X% of games, a decay of -1 indicates that theres no data or something along those lines.
I pulled the first 3 occurrences and nothing changed. Will do the second set of three and check again.
Instrument 06
[Not in DLS] Bend Range C8
Number Sounds 0001
Sound 0000
Sampling Rate 22050.000000
Attack 80000000 Decay 7FFFFFFF Sustain 03E80000 Release F6A00000 (Attack Volume 7F Decay Volume 7F)
Loop Count 00000001 Start 00000EDC Length 000003F4
Key Base 30 Fine Tune 0000 Volume Attenuation 0383E26E
Key Low 00 Key High 7F Vel Low 00 Vel High 7F
This only fixed a couple instances. Theres apparently more going on here or im bad at reading x86. Going to edit a couple more things just for giggles and see where it ends up.
I think this might be as i suspected. @L-Spiro What are the chances of only some of the instruments with decays of -1 having attenuation values? I cleared just about everything I could find and it fixed a handful of instruments (instrument 6 is now filled in while instrument C isnt for ex). Is its something where theres a default if the value is 0? Im kinda lost.
Heres the build with the decay check/s patched out. This comes with absolutely ZERO support as the binary itself was edited. http://holdinghandsis.gay/images/patched%20soundbank%20tool.7z
edit*
fixed instrument C and a couple other things i guess. Still dont know what youre looking for. All the other instruments have their attenuation set to 0x80000000 if i clear out the checks completely, so it seems right to me.
I appreciate the hard work you are putting into this!
Now that the 11.5 hours have passed I can finally show what this means to me: https://www.fangamer.com/products/jet-force-gemini-vinyl-soundtrack
I work with Rare and other game companies and create HD restores of OST’s for official release. So the proper functioning of these tools can have a major impact on my work.
#What are the chances of only some of the instruments with decays of -1 having attenuation values?
The chances can increase or become 0% depending on the personal style of the composer. A lot of composers keep their banks simpler, but nothing prevents from them having a no-decay sample that plays at a level other than maximum. Those settings are completely unrelated and are a perfectly valid combination, so if we keep going through OST’s, the chances of encountering them is basically 100%.
I just did the Super Robot Spirits OST ( https://www.youtube.com/playlist?list=PLWsnao9n727PGn40lPqqyUKKksEDAynsn — holy wobbly dangles it jams to wiggity wack and back WTF), and it has an extremely complicated sound bank, where multiple samples (0x0C as a great example) are layered on top of each other to create different effects (Instrument 0C is a pair of strings that both cover the full keyboard and velocity range, so both samples always play together, but each has a different pan and volume, and no decay).
I think the approach should be to remove that weird code as default and then figure out how to correct it and add it back later, but since the EXE seems to have been edited already I will start using it now and then provide feedback.
I will be putting it through its paces as I am doing about 1 full OST every day right now.
I made these changes, however...
Please rebuild the source code yourself and submit merge requests. You need any version of Visual Studio with MFC C++ - 2008 is easiest and probably cheapest, but it can work on any. You may need to change targetver.h to later targets, beyond 0x400, since that is obsolete post Visual Studio 2008, and need to have DirectX installed, which is also on this github. I am not maintaining these tools anymore in any serious fashion - this is why open source.
Thanks sub. I'll get the build tools set up on a vm for future sanity's sake :)
maybe with a basic how-to so it can be referenced so this doesn't happen again
I've personally only got vs2013/17/19 set up on my machine
Thanks that would be helpful! You will need to install directx sdk, point library paths to it (if different). Install MFC C++. Make sure you update targetver.h to like 0x600, maybe even higher (check out microsoft for what OS's you target with with what values). Setting running directory to main folder when running (so picks up ini). Should be that simple, more or less.
Working well so far! Thank you!