Sir | Audio Editor

[giftfish]

Ported from the old forum with formatting changes for readability. Highlights only, due to thread length, and broken up into multiple posts.

---

PART 1 : INITIAL IDEA

---

New(ish) Tool | Audio Editor

Postby giftfish » 13 Sep 2016, 16:03
Placing new audio in the game is a royal pain in the ass and requires a LOT of different tools.

Here's the current workflow:

1. Extract game audio using different programs, depending on the game and how much audio you want extracted (Gibbed's, Kyp's, ME3Exp Audio Extractor, Soundplorer)
2. Edit sound files in Audacity/audio editor
3. Convert sound files in Wwise
4. Use Fob's AFC Creator to build a new AFC; use a text editor to keep track of the new lengths and offsets in the new AFC
5. Add new AFC to name list in PackEd
6. Repoint exports to new AFC in PackEd
7. Hex edit export references to WAV length and offsets in new AFC in PackEd
8. Use WwiseBankEditor to hunt down edit bank hex, if necessary (lots of fun there)
9. Test in game
10. Do all of this all over again when the line doesn't test well in game
11. Do all of this for every line you want to replace

Yeeeeah. It sucks. Pretty hard. It's incredibly tedious and time consuming. ME3 is frequently uncooperative, as the game engine changes what the audio sounds like. So, something that is perfect in Audacity and Wwise, might end up sounding less perfect in game. In short, there is lots of trial and error involved. At least for dialogue. If you have to add SFX to the audio (like a drell voice that you have to match to existing lines), boy, you're really asking for trouble.

We can't do anything about Wwise and Audacity. But, we can streamline ALL the rest of this. By a lot. In a new "Audio Editor". It'll require a new GUI, which... yeah, I'll get on that. It'll also require we finish and expand the current feature set of all these tools.

Btw, Deager and I will likely be so excited about this we'll crap out some kittens. Really. This is on the level of the FaceFX Editor.

Github issue here.

---

Postby SirCxyrtyx » 14 Sep 2016, 10:48
I'd love to make the whole audio workflow better. Stuff like dealing with AFCs and offsets would majorly benefit from the tool doing it for you.
I've heard of this fabled AFC creator of Fob's, but I don't think I've ever seen it. It doesn't appear to be on the third-party utilities board.

---

Postby The Fob » 19 Sep 2016, 20:31
sircxyrtyx: If you feel like making a tool out of this simple command line prog, that'd be great!
The code is really simple, so it should it'll probably take you about 30 seconds to transfer it.

---

Postby SirCxyrtyx » 19 Sep 2016, 20:41

giftfish wrote:
A more general question: I'm thinking we can probably remove the functionality of replacing WAVs via Soundplorers Import/Export/Direct AFC replace methods? Since folks should be putting new audio into new AFCs, instead?

Something to keep in mind is that some sounds are pcc-stored. A direct-replacement option would be necessary for those, at the very least.

---

Postby giftfish » 20 Sep 2016, 04:20

SirCxyrtyx wrote:
Something to keep in mind is that some sounds are pcc-stored. A direct-replacement option would be necessary for those, at the very least.

This I did not know, so thanks for clarifying

The replacement method actually should no longer matter as far as the GUI workflow I came up with last night. However, if we allow replacement within vanilla AFCs we either need to change how that works behind the scenes so that size isn't an issue, or we need to have it work under different constraints than a non-vanilla AFC and not allow the replacement unless it's within the vanilla size range.

I have no idea how sound replacement within PCCs works and if the toolset even supports it. Assuming that the sound is concatenated to the end of the file, then in theory, I think the modder could use whatever file size they need to.

---

Postby Deager » 20 Sep 2016, 06:14

giftfish wrote:
A more general question: I'm thinking we can probably remove the functionality of replacing WAVs via Soundplorers Import/Export/Direct AFC replace methods? Since folks should be putting new audio into new AFCs, instead? Allows them to keep the quality significantly better and to not overwrite a vanilla AFC. Anyone know if new AFCs will work in the base game Cooked? If the modder for some reason doesn't want to use a DLC mod?

Not sure if this is answered later in the thread and I don't know about afc stuff in the base game. Theoretically, yes, it would work...I think. But I think we really need people to get used to DLC mods since they are massively malleable and, I think, much better for the end user.

---

Postby giftfish » 20 Sep 2016, 06:23

Deager wrote:
Not sure if this is answered later in the thread and I don't know about afc stuff in the base game. Theoretically, yes, it would work...I think. But I think we really need people to get used to DLC mods since they are massively malleable and, I think, much better for the end user.

The new DLC Mod Generator we'll be making should help substantially.

Also, Sir pointed out that some sounds are PCC-stored, which I didn't know. So, it looks like we'll need to retain the functionality, but hopefully we can improve on it. For example, from what I understand, the reason we need to stay within the same size range for vanilla AFCs, is b/c the hex pointers don't get changed. We're literally swapping out the bytes in the same area of the file, which is why we have to keep the sound the same length and size. Why not change this so that the new sound is concatenated to the end of the AFC and then the hex is adjusted and the file name repointed, just like when generating a new AFC?

Is there some reason why this method was never put into Soundplorer that I'm missing? >.> Music has it's own complications with the banks, which is something else we'll address, but for dialogue, I can't see why this method wouldn't work.

---

Postby Deager » 20 Sep 2016, 07:06
The history on that issue with moving new sounds to the end was we didn't have the dll fix. So, anytime we had a file larger than the original, we borked the game and it wouldn't authorize or load. But if we kept file sizes the same or smaller, we could get stuff done.

Now of course we have the dll thing so that limitation got lifted. That's my understanding of it anyway. And I only worked with the Citadel DLC back then so I'm not sure what core game stuff did.

---

Postby The Fob » 21 Sep 2016, 08:19

deager -- That makes some sense. The DLL fix wasn't needed for base game files, though, so that's a bit weird.

IIRC, the main problem really was that it took us a while to figure out how/where to exchange the HEX in the pcc files, that indicates offset/length of the sounds. So when we did this for the very first time, we tried to keep everything as it was as much as possible and just change bytes.

deager/Fob/JohnP -- You guys have also done lots of audio work. Please let me know if there's any UI elements or functionality you want to see.

So, one thing I really got used to was to work with batch files that call AFC creator commands. It's great because it saves your work procedure, rather then the result only. You can save your replacements in a .bat file and do as many modifications to the original files as you like with just one command/click, while not modifying the original file at all. If you want to change some of your edits later, you just need to change one line in the bat file and run it again, rather then work out what's where in the new afc file again.
If we could implement batch execution and saving or something similar in the new tool, that would be perfect.

---

Next Post: Part II

[giftfish]

Ported from the old forum with formatting changes for readability. Highlights only, due to thread length, and broken up into multiple posts.

---

PART 2 : GUI

---

Postby giftfish » 25 Sep 2016, 11:02

And we have a mock up:



To be clear, this is a general mock up, unlike the main window mock ups. The final tool will not look exactly like this.

There's a lot of things to cover with this, so please read carefully:

1. New Template.
All major tools will follow a similar template as this window. The template contains the following:

• Window Size -- This will be changed to 1000x700. Not sure yet if that will be customizable. I know that lots of folks have higher rez monitors now (including myself) and bigger is better, but then it screws folks on smaller screens.
• Windows Title Bar -- We're switching to a much more typical style with this. The file/path name left-justified, followed by an em dash and the name of the tool.
• Top Menu -- Again, conforming to certain standards that users expect. File/Edit/View/Tools/Help. Keyboard shortcuts provided. Almost every tool will have these. Help will always point to the wiki/forums/Git. The background color of this area will change for each tool to provide some visual differences across windows. They'll coordinate (roughly) with the icon color.
• Large Tabs -- When a tool has more than one main function, this is what will provide more flexibility with the GUI. I'm trying to help us get away from having to click a new tab to see every little thing (holy annoying, batman), but these large tabs allow us to completely change the layout of the "content area" below.
• Toolbar -- Yay for toolbars. Most programs provide at least 3-4 ways to make a specific edit: top menu, toolbar icon, right-click, and keyboard shortcuts. The toolset will now have all these to provide flexibility to the user.
• Content Area -- The main content area will change for each tool. Also, colored in gray b/c all this white in Win10 is burning my fucking retinas.
• Infobar -- All major tools will have an infobar immediately below the content area. This will include the file name, a summary of main data associated with the file. As you can see, there's still more space, so we'll likely mess with the layout a bit and create a section that is specific to each tool. The backgroun will match the Top Menu.
• Progress Bar/Debug -- Some tools will have a bar and text; others will only have text. It depends on the tool and operations. The tool will always let you know when an operation has completed and there will be no more dialog pop ups. Yay.

That covers the new general template. Now onto the new Audio Editor, itself.

2. Audio Editor Overview.
It will combine the following:

• Audio Extractor
• Soundplorer
• WwiseBank Editor
• Fob's AFC Creator

The tool will be divided up into a Wwisestreams tab and a Wwisebanks tab, as these are the two type of exports involved in audio replacement and editing.

WwiseStreams Tab
This tab has a list of the Wwisestreams in the loaded file on the left, and associated properties on the right. Each pane is searchable in it's own right and can be adjusted left/right and up/down. ONLY export names will be shown in the list. Columns now have proper labels that will stay fixed while scrolling. There will be context menu and toolbar options to extract the selected track(s) or all audio in the file, plus a couple of configuration options.

The Properties area on the right is confined to WwiseBank and AFC associations, as that's the only thing involved in audio replacement and editing. If the modder needs to clone in exports, relink, etc, all that must be done in PackEd, which can be open simultaneously. The layout of the Properties area in all tools will follow a slightly more updated UDK-style, everything collapsible, etc. We'll make sure there is a button to easily collapse/expand everything with one click (or I will go insane ).

Replace Audio Area.
This is the new workflow for replacing audio for a single export or two dozen exports. I haven't mocked up all the visual aspects; instead I describe the workflow. The goal is to make a complex process as simple as possible. As few clicks as possible. Drag/drop into boxes 1 & 2. Reorder via drag/drop within box #2, then specifiy your AFCs in box 3. There will be an easy way to point all replacements to the same AFC. If for some reason you need to point to 12 different AFCs, you'll be able to do that, too. Same with creating a new AFC from scratch.

Once you've configured the tool, there will be some type of "Go" button and everything will be done automatically. No more hex editing.

Tools.
The Tools main menu option will provide 2 other functionalities:

• Batch Extract Audio -- This will allow the user to extract all audio for the game or multiple selected files.
• AFC Creator -- For folks who want to stick to the old hex-editing method, this will provide a simple GUI for Fob's tool, launched within the toolset. Probably similar to the Replace Audio area, just with only boxes 2 & 3, and the latter will only allow a single AFC. It would be up to the user to hand-edit the hex in PackEd.

-----

Sir will likely start working on this soon, as I work on the new GUI for the Wwisebank tab. That tab is going to be troublesome b/c the current editor is such a... well, mess. Folks with experience in editing the banks, please monitor this thread, as I'll likely be posting questions that will need feedback.

Thanks

---

Next: Part 3

[giftfish]

Ported from the old forum with formatting changes for readability. Highlights only, due to thread length, and broken up into multiple posts.

---

PART 3: PROBLEMS WITH RIFFS + CINEDESIGN

---

Re: New(ish) Tool | Audio Editor

Postby giftfish » 26 Sep 2016, 09:09
I just remembered something else we need to consider with the new editor: wwisestreams that exist as RIFFs. The toolset doesn't seem to know how to handle these, which makes sense a bit, as gibbed's audio extractor doesn't handle these properly, either.

I've been researching something with Hanar Diplomat and actually just ran into this, so the timing is convenient.

Here's a RIFF, as viewed in PackEd:



Note that the WwiseStream RIFF, A-Doesn't have a File Name Property, and B- has a whole shitton of hex that is, I guess, PCC-stored audio?

Here's what it looks like in Soundplorer, and it cannot be played, likely b/c the toolset doesn't really understand where it is:



Something else funny: If you try to extract it, the toolset will say that it has, but if you look in the specified directory, it's not there. So, two bugs with that (not extracting, and doesn't realize it hasn't extracted.

So, right now, RIFFs cannot be edited or extracted.

----

FYI, here's "normal" WwiseStream object in PackEd and that is playable/extractable/replaceable in Soundplorer:

SPOILER: Click to show

---

Postby SirCxyrtyx » 26 Sep 2016, 09:24
Soundplorer has been able to play and extract pcc-stored sounds since 2.0.8. It can't replace them though. I got distracted by other things and never got around to that I'm afraid.

---

Postby giftfish » 26 Sep 2016, 09:54

SirCxyrtyx wrote:
Soundplorer has been able to play and extract pcc-stored sounds since 2.0.8. It can't replace them though. I got distracted by other things and never got around to that I'm afraid.

Maybe it's a bug unique to this file, then, b/c it cannot play or extract the sound from that export. I try and like I said, the file is not created. And clicking play does nothing.

Do you want me to report it as a bug on Git?

---

Postby SirCxyrtyx » 26 Sep 2016, 10:08
This is a file you've edited right? Try re-saving the file with 2.0.15 first. Despite the fact that the audio data is right there, it's accessed as though the pcc was an afc, so it looks for a specific offset in the file. Doing a reconstruction save could mess that up. In 2.0.15, I've fixed that by re-doing the offsets for pcc-stored WwiseStreams when saving.

---

Postby giftfish » 26 Sep 2016, 10:35

SirCxyrtyx wrote:
This is a file you've edited right? Try re-saving the file with 2.0.15 first. Despite the fact that the audio data is right there, it's accessed as though the pcc was an afc, so it looks for a specific offset in the file. Doing a reconstruction save could mess that up. In 2.0.15, I've fixed that by re-doing the offsets for pcc-stored WwiseStreams when saving.

No, this is a vanilla file. Just re-tested to be certain. You should be able to replicate on your end by loading BIoD_CitHub_HanarDiplomat_LOC_INT.pcc inside Soundplorer and attempting to listen/extract.

---

Postby giftfish » 26 Sep 2016, 10:47
Something else involving Cinedesign sounds.

There's a strange flow here I'm going to have to understand to put together the GUI for the WwisebankEditor.

Same vanilla, HanarPlot_LOC_INT.pcc:

Here's a typical WwiseEvent object:

Normally, there's a reference at the end of the object that points to the relevant WwiseStream export. The user can then open in Soundplorer and listen to that sound file.

For many cinedesign sounds, this doesn't work. For example, in this file there are 13 cinedesign Wwiseevents:

There are only four cinedesign Wwisestream exports that can be played. In addition, there are no cinedesign-related imports. So, somehow, the game is getting directly from the Wwiseevent to the AFC via the bank. There is no stream object as far as I can tell, which means there's no way to extract or listen to the sound. I've looked in the bank and tracked down the relevant entries, but none of the hex references any of the 4 cinedesign wwisestreams in the file, which aligns with my thought above.

I have no doubt all the sounds are actually stored in Wwise_CitHub_Cinedesign.afc, but I don't see how to access them.

---

Next Post Part 4

[giftfish]

Ported from the old forum with formatting changes for readability. Highlights only, due to thread length, and broken up into multiple posts.

---

PART 4 : NEW BANK EDITOR RESEARCH I

---

Re: New(ish) Tool | Audio Editor

Postby giftfish » 10 Oct 2016, 06:52
Finally diving into laying out the large tab for the bank editor.

This is a bit of a black hole... there's a lot stuff to consider. I think there's also still a significant amount of stuff that isn't researched, which makes me a bit uncertain as to what types of fields to include in an editor. Even answers as simple as "what does 'HIRC' stand for?" are not easily found. It's not even defined inside Audiokinetic's 904 page help PDF (ugh).

For reference, I'm using info from:

WwiseBank technical research thread
Xentax Wwise SoundBanks wiki article (very detailed, but incomplete)
Fob's original research post
Wwise Help PDF 2010.3.3 (Wwise > Authoring > Help)
Wwise Web Glossary


Anyone can open up a LOC_INT or main PCC in the editor to see how the tool is currently organized. It needs a lot of improvement; the question is the best way to go about it. For ease of reference, here's some caps:





I've done SOME work in the banks, but not a lot, which is why I need to hear from modders out there with more experience than I. Trying to organize all this hex and undefined audio terminology into an intuitive editor is going to be very difficult. For that reason, I'm not going to create detailed mockups at first. For now, it's about just figuring out what to call things, what should be displayed, and how to display those things. Then I can figure out how to organize them within the GUI.

Initial comments/questions:

1. SoundBank.
I'll be changing the bank selection mechanism to a simple dropdown. There are typically few banks in a file and there's no reason to have the entire left half of the tool empty. This will replace the current list and be situated in the top left.

2. RAW Tab.
This shows all hex for the bank. In other words, the same thing that is visible with PackEd, just without the preceding Unreal properties (uh, I think that's what those are called...). I have 3 related questions:

• Do any of the current operations in the tool under Edit/Transfer require that the modder might need to use the RAW tab?
• If yes, which ones and do we want to retain them?
• If no, does this tab of RAW hex need to be in the new editor, or are the small segments of hex on the HIRC Objects tab enough?
• Can/Should the display of the hex in the RAW Tab be combined with the hex displayed in the HIRC Objects Tab?

For the latter question, let me provide an example. If the HIRC had it's own "Properties" area that was always visible, would it be enough to have the hex for the whole bank visible, as long as the section associated with a specific object was highlighted?

And, one final follow up. Right now, displaying the hex associated with any HIRC object is necessary, as we don't know what it all does and we have no other way to edit the bank. *IF* we were able to fully decipher and edit the bank, would we still want a hex editor present?

3. WwiseAudio.pcc
I wanted to mention this PCC since it's likely one of the most uneditable files in the game, and one that is directly relevant to the new editor. It's full of various Wwise parameters and scripted behaviors. It also contains the Initialization Bank (which does a variety of things including load all other banks) and the Default_WwiseBank, the latter of which throws an error when attempting to view in the editor.

----------

I think that's it for now.

kinkojiro, Fob, JohnP, Deager, I think you are the only 4 folks besides myself that have done work in the banks, so it's pretty important that I get whatever feedback you can give

---

Next: Part 5

[giftfish]

Ported from the old forum with formatting changes for readability. Highlights only, due to thread length, and broken up into multiple posts.

---

PART 5 : DIDX/DATA SECTIONS (First Scan Tab)

---

Postby giftfish » 10 Oct 2016, 10:12

DIDX/DATA SECTIONS (First Scan tab)

These are the "Data Index" and "Data" sections in the existing editor. They will typically only be in non-dialogue banks. So, banks that are for music, ambient sounds, etc. They contain WEM references and data.

FYI, WEM = Wwise Encoded Media. Prior to 2011, which includes the version of Wwise BW used to create ME3, Wwise used the WAV file extension (Wwise Audio-Video, I'm assuming). This is why we see "WAV" extensions associated with the streams in ME3 files. These WAVs are technically WEMs.

Currently, the "First Scan" area of the editor is simply a list. Looking at the Soundbanks section in the Wwise PDF is extremely helpful as to where this content might fit in, but I have some questions.


1. Embedded vs External WAV/WEM Sounds
Various sources explain these WEM/WAV references in the DIDX/Data are for the bits of sound that are actually embedded within the bank. This includes two types:

• A full sound, like a datapad beep
• A piece of a streamed sound, which ultimately leads to a Wwisestream object

My understanding is that the former has no WAV (Wwisestream) counterpart in the file. The audio exists in the bank, ONLY.

Is this correct?

If this is correct, this means that we need a way to play and replace this audio. Right now, we can do neither inside the tool. The WEMs can be extracted and listened to via the Export All WEM files option, but for some reason WV never built in the OGG conversion. They have to be converted manually via ww2ogg. This is something that should be built into the tool, as it is for Wwisestreams.

In the case of pieces of streamed sound, these are currently the portions that need to be replaced manually when modders do a music edit to a PCC. The plan is to have this handled via the new "Audio Replace" feature in the WwiseStream tab.


2. WEM/WAV IDs
In the particular bank I'm looking at, there are 73 WEM references. They each have an ID and a size parameter that looks something like this (but in hex):

ID/Size
867467429 /6679
841736579/5026
794754303/9683
394613384 /27903
570288598 /23729
830186304 /9718
1019932694/63669
...

Whether the IDs are hex or integers, these are very unwieldy. I assume BW had some actual names for the WEMs/WAVs on their end, but that name isn't in the file. Some screenshots in the help PDF provides some ideas as to what might have been in place:





What I'm wondering is if we can assign actual names to these, without it impacting the file. I don't really know how that would work, but part of the issue with dealing with banks is all these crazy long integer IDs -- or the modder having to know the hex of the ID. Even something as simple as WEM1 would work. Just some way to keep track that doesn't involve numbers like "1019932694". I guess we could build it into the GUI... maybe.

Any ideas on that, Sir?


3. Replacing Fully-Embedded WEMs
This will be new territory. Would we want a specialized area of the UI similar to the WwiseStream Audio Replacer? Or, would it be enough to only replace one at a time via a context menu/toolbar button?

---

Postby giftfish » 10 Oct 2016, 10:59
Some general FYI and notes on tools/operations we'll likely want:

1. HIRC = Hierarchy Inclusion. Almost certain. This field is in Wwise's Soundbank Editor.

2. ENVS/FXPR -- Has anyone seen these sections in any bank? So far, I haven't run across them.

3. Imported Banks -- The Init.bnk is imported into probably every file. Lots of files also import other banks. I think we'll want to create a special place in the GUI to notify the modder of imported banks, since they are easy to miss and can explain strange behaviors when attempting to replace game audio. Then, probably provide a way to "Open Imported Bank" or something.

3. Operations/Tools -- Open/Close/Save, Generate empty bank, Export bank hex, Export one/some/all WEMs, Replace (one/some/all) WEMs, Add WEM, Open imported bank.

----

@sir -- Another example of a bank that throws an error in the current editor is export 3228 inside BioD_ProEar_415Harvester. Looks like there's a reference in binary at the end of the very short bank. Might point to something inside the Init bank... maybe?

---

Next: Part 6

[giftfish]

Ported from the old forum with formatting changes for readability. Highlights only, due to thread length, and broken up into multiple posts.

---

PART 6 : INIT.BANK + STID

---

Postby giftfish » 10 Oct 2016, 11:14
SOUNDBANKS and INIT.BNK

All banks have an ID that I'm assuming is unique across all PCCs. In addition, the Wwise Help PDF states this:

By default, Wwise updates the initialization bank each time one or more SoundBanks are generated. This is to ensure that the two sets of banks are in sync. The Initialization bank contains all the general information about a project, including information on the bus hierarchy, and information on states, switches, RTPCs, and Environmental effects. If changes are made to any of these elements within your project, you will have to update this bank in your game along with the newly generated SoundBanks. If, however, no changes are made to these project elements, you can keep theolder version of the Init.bnk.

Comments:

1. I took this to indicate that the Init.bnk contains an index of all valid bank IDs, a bit like a TOC. Yet, doing a search for a few by their ID, I couldn't find any. So, apparently not.

2. This suggests that if we ever want to ADD a new bank to a file we'd need that process to edit the Init.bnk inside the WwiseAudio.pcc... depending on what types of edits we allow.

3. Fully deciphering the Init.bnk might be the key to more fully understanding the properties within individual soundbanks. Some of that hex we haven't been able to identify the meaning of, yet.

---

Postby giftfish » 10 Oct 2016, 11:46
STID

Xentax identifies this, questionably, as the "Sound Type ID":

The STID section (Sound Type ID?) section contains a list of all the SoundBanks referenced in the HIRC section (including the current SoundBank). In the HIRC section, only the SoundBank ids are given, so this section can be used to match an id with a SoundBank file name.

       53 54 49 44 -- STID
       uint32: length of section
       uint32: unknown integer, always 01 00 00 00
       uint32: number of SoundBanks
       FOR EACH (SoundBank) {
           uint32: SoundBank id
           byte: length of SoundBank name
           char[]: String with given length, e.g. "music". Can be used to find the SoundBank file name: "music.bnk".
       } END FOR
This seems to be incorrect, in part. I think this is just "String ID", which seems to verify how WV is labeling fields in the current bank editor:

Found Chunk, ID:STID len= 39 bytes
   ...String Count : 1
   ...String(0) : ID(0xAC13A2C2) citprs_ash_talk1_d
I'd think is this just what Wwise stores as the user-defined name for the bank. The bank will only ever have one name, so there's always 1 string count and one string. So far, I've never seen more than one reference in this section, and it always matches the unreal export name. It's possible there are cases where it doesn't, though, so we'll likely want to include this in some type of Wwise Metadata info. It doesn't seem like it would need to be editable.

--------

FYI -- Looks like the Init.bnk has ENVS and STMG sections. They're labeled as "unsupported" in the current editor.

---

Postby The Fob » 11 Oct 2016, 09:04

Hey gift, I am sure you are on to this already but just as a reminder, the only time I came in contact with the Init bank was when I chased Music IDs. See here, it's more towards the end of this rather long post, and yes, I say there that I'd write a tutorial which I never did, so I guess you may hit me (but not really).

To my knowledge, this is the only time anyone on these boards ever talked about the init bank and I never bothered to decipher anything more than the plot states for music IDs but I am sure it's possible to decypher it if necessary.

Not sure if this is helpful to you guys at this stage, just letting you know what my latest info on this was.

---

Next: Part 7, Final

[giftfish]

Ported from the old forum with formatting changes for readability. Highlights only, due to thread length, and broken up into multiple posts.

---

PART 7: LINKS TO GOOGLE DOCS & THOUGHTS ON WWISE

---

Postby giftfish » 19 Oct 2016, 10:38
@sir --

Had a chat with Deager a bit and thought I'd toss out one of his main ideas for the new editor. I'm not sure how viable it is, but it's worth mentioning

One of the biggest complications for modders is needing build 3773 of Wwise, which is 6-years old and no longer available for download on Audiokinetic's site. It is available on SaintsRowMods, and that is the download everyone uses. However, if that ever is removed, we've got a problem. At that point game audio becomes unmoddable for the masses.

At any rate, as you know, Wwise is needed to encode any new audio files into game-compatible Vorbis-format Wwise "WAVs". Deager's point was if we were able to do that from within the toolset, it would omit the need for Wwise. This would both be great for workflow, and it would omit needing to track down a 6 yo build of software.


I think it's a great idea, in theory, but I also see complications:

1. I'm not sure we can legally do this. There are parts of Wwise that are open source, but I'm guessing this wouldn't be one.

2. There is some type of Wwise SDK documentation on the site, but I don't know that any source code is available. I doubt it.

3. For dialogue, the WAV conversion is basically all that's needed. Essentially what ww2ogg does, but in reverse. It's possible the modder will need to make changes to Channels, Sample Rate, and Quality, however, in almost all cases I leave "As Input" selected for the former two. For Quality, I tend to leave it at the default of 4 now that we're able to make our own AFCs.

4. For music, things get more complicated, since the SeekTable needs to be set to 8192.

5. I have no idea how ambient sounds or cinedesign sounds are handled (footsteps, datapad beeps, etc). They might be treated like music, but I really don't know. These would almost always be WEM files stored in the bank.

----

So yeah, likely not doable, but if it were, those are the minimum features we'd need to ditch Wwise.

---

spreadsheet
doc