feat: Allow `--txtp-lang` to accept multiple languages.

[Razmoth]

Greetings,

Would it be possible to explore having --txtp-lang accept multiple languages rather than single one to avoid multiple executions, such as:

 # generate txtp
 ...
 ..
 .
for lang in args.txtp_lang:
     locator.set_txtp_path(args.txtp_outdir + lang)
     locator.setup()

     generator.set_lang(lang)
     generator.generate()

Let me know what would be more fitting, would attempt to PR it.

Thanks

[bnnm]

I considered adding something like that before but it didn't feel that useful, as it just avoids re-parsing banks while non-localized txtp would be re-created and a bunch of stuff re-parsed anyway, so doing separate executions seemed good enough.

The generator.set_x code is becoming rather ugly so I was trying to think of a cleaner solution first (like some way to simplify doing param variations in CLI). Plus would be nice if the GUI could select multiple langs too, but it's kinda annoying/time consuming to tweak.

Generating txtp is mostly done once, and most users would ignore or just check 1 lang (their favorite one), I guess. Anyway if you can explain a bit more when/why would you use this I can get a better idea and maybe just add it as-is for now.

No need to change txtp_outdir btw, when loading multiple lang banks it's designed that txtp names include language suffixes if needed, so different files can coexist in the same place. ex. Play_BGM01.txtp (no suffix), Play_voice01 {l=us}.txtp (-txtp-lang us, Play_voice01 {l=jp}.txtp (same for jp). I feel changing the dir per lang is messier, as non-localized txtp are duplicated (seems it could confuse users, since they only need {l=xx} variations).

[Razmoth]

Greetings,

Thanks for the reply.

Ah that would make sense then.

Would it be maybe possible to achieve that with enum.Flag instead ? not quite sure.

To give some context, I am currently in the process of making some sort of a package explorer tool (link), a small demonstration of how it looks is shown below:

Essentially, it will parse .pck files and display them into a grid view with options to allow users to export based on selection or batch exporting.

One feature Generate TXTP would invoke wwiser based on user's current languages selection and provided events names (it will pass -g/-gbs/-te/-nl/-gl/-go)
where:

• Banks would be dumped in a temporary location (would be better if there was an option to pass bnkname/file/offset/size but that should be fine for now).
• Invoke wwiser based on selected languages and wait for it to finish.
• Scan generated TXTP files to figure out which audio files are needed, then:
• if Export Raw Audio is checked , export raw audio files into wem/.
• if Export Raw Audio is unchecked, export combination of an empty audio file + generated TXTH (sample below) into wem/ to force VGMStream to stream it from the original .pck. (so far seems like it only accepts relative paths, which would not work well if it ran from another drive letter)

Not exactly very familiar with the codebase yet, but looking into how languages are applied, would have assumed that localized bank events (e.g Play_voice01 {l=us}.txtp | Play_voice01 {l=jp}.txtp | Play_voice01 {l=kr}.txtp) should not be counted as duplicates, thought not sure if I might have misunderstood something about it.

[bnnm]

That's an interesting solution to stream from the original .pck. Since you are reading the .txtp you could probably modify them so instead of path/123.wem they call path/123.wem.txth to avoid making an empty file (it's valid to load a .txth directly when body is set).

(I would also recommend extracting the ´.bnk´ rather than using -gbs for preservation's sake though)

I think full path could work in txth but also depends on the player/plugin used, I'll have to recheck.

For passing bnk offset/etc, I was considering parsing .pcks (plus allowing bnk filters) to simplify wwiser's usage, would need some restructuring and think how to handle those params though.

As for the languages, it's a bit hard to explain but basically if you load all banks it would create "non-localized" .txtp (from SFX banks) and "localized" l=xx .txtp for the selected language (like English(US) banks only). When executing again with other language l=xx txtp are created and never considered duplicates, but txtp from SFX banks don't change so they clones compared with the prev execution (you may load only localized banks so only l=xx txtp are created, but some games need both)

Note that in some cases, wwiser may decide to not add l=xx:

• if you pass lang with -gl then l=xx is always added (only for events that use localized audio)
• if you don't pass lang and load multiple langs, it also adds l=xx and defaults to one language
• if you don't pass lang and only load banks from one language it doesn't add l=xx
  • this is done b/c some games may "English(US)" banks for music, even if no other langs exists

[Razmoth]

Greetings,

Oh thanks for the advise, did not try that before, currently the tool opens TXTP file on readonly mode, will have to explore that option.

Setting -gbs helps to unify all audio's inside default path, aka wem/, so that TXTH could be generated, Although not quite sure if extracting banks would be needed in the first place since most of the time output expectation is audio files, but there's nothing wrong with it.

Since BKHD has the language should it not be possible to deal with any langauge without the need of selecting one ? or is it because duplicate bank ID is not allowed in the generator at once ?

[bnnm]

Maybe could add a flag that wwiser writes .wem.txth automatically in txtp (perhaps if I add .pck support could even generate those txth). Though on the other hand this tool is rather obscure so not sure if it needs that many options.

As for -gbs, I feel it's important to encourage data preservation (especially for mobile games that sooner or later die and original .bnk can be easily lost forever), see my thoughts. Also note that RIFF sizes aren't always correct in .wem and one needs to read AkMediaInformation offsets/sizes. Anyway just my recomendation.

Even if BKHD has a language it doesn't mean its events/audio use localized audio, the flag is set per .wem instead (AkBankSourceData.bIsLanguageSpecific). So you don't know if an event is localized unless you see which wem are being used. In other words, you can have English(US) bank that only plays music.

IIRC BKHD language is used by Wwise to ignore other languages when loading many banks (Wwise can only load SFX + one lang banks at once). Handling multiple languages at once in the generator is probably doable, but I thought it would cause odd issues so decided to handle it like Wwise (ignores banks that aren't from selected lang).

[Razmoth]

Greetings,

Oh that would be quite useful if it happened.

Understandable, will try to test it then and see how is the feedback.

I do agree with it being more realistic approach, But while it does make sense to have SFX + one language at runtime, when generating TXTP it would be better to process banks against passed wwnames.txt (if possible of course).

[bnnm]

Couldn't quite think of a way to gracefully handle so just added quick implementation for the time being: --txtp-lang en jp.

I didn't think forcing a txtp subdir per language by default was a good idea so instead added "variables" in output path. For example you can use --txtp-lang en jp -go txtp/{lang} or -go txtp/{bank}-{lang}.

Note that as commented above will make base txtp + en language txtp, then and again generate all base txtp + jp language txtp (a bit wasteful but...).