TXTP is a text file with commands, to improve support for games using audio in certain uncommon or undesirable ways. It's in the form of a mini-playlist or a wrapper with play settings, meant to do post-processing over playable files.
Simply create a file named `(filename).txtp`, and inside write the song name and commands described below. Then open the new file directly and vgmstream should play it.
*files* may be anything accepted by the file system (including spaces and symbols), and you can use subdirs. Separators can be `\` or `/`, but stick to `/` for consistency. Commands may be chained and use spaces as needed (also see "*TXTP parsing*" section).
You can mix any kind of files (including different formats and codecs), as long as vgmstream plays them separately too. If you have problem getting a TXTP to play try playing file by file first and make a simpler TXTP then add more. There are technical limits in total files (usually hundreds but varies per O.S.) and layered channels though. Also see explanations below for some per-mode limitations too.
Mixing sample rates is ok (uses max). Different number of channels is allowed, but you may need to use mixing (explained later) to improve results. 4ch + 2ch will sound ok, but 1ch + 2ch would need some upmixing first.
If all layers share loop points they are automatically kept.
```
BGM1a.adx # loops from 10.0 to 90.0
BGM1b.adx # loops from 10.0 to 90.0
mode = layers
# resulting file loops from 10.0 to 90.0
# if layers *don't* share loop points this sets a full loop (0..max)
loop_mode = auto
```
Note that the number of channels is the sum of all layers so three 2ch layers play as a 6ch file (you can manually downmix using mixing commands, described later, since vgmstream can't guess if the result should be stereo or 5.1 audio).
You can set "groups" to 'fold' various files into one, as layers or segments, to allow complex cases. This is an advanced setting for complex cases, so read this after understanding other features first.
From TXTP's perspective, it starts with N separate files and every command joins some files to make a single new "file", so positions are reassigned. End result after all grouping will be a single, final "file" that may contain groups within groups. It's pretty flexible so you can express similar things in various ways:
`group` can go anywhere in the .txtp, as many times as needed (groups are read and kept in an list that is applied in order at the end). Format is `(position)(type)(count)(repeat)`:
`position` may be `-` = automatic, meaning "start from position in previous `count` before current". If `repeat` is set it's ignored though (assumes first).
```
bgm1.adx
bgm2.adx
group = -L2 #layer prev 2 (will start from pos.1 = bgm1, makes group of bgm1+2 = pos.1)
bgm3.adx
bgm4.adx
group = -L2 #layer prev 2 (will start from pos.2 = bgm3, makes group of bgm3+4 = pos.2)
group = -S2 #segment prev 2 (will start from pos.1 = bgm1+2, makes group of bgm1+2 + bgm3+4)
# uses "previous" because "next files" often creates ambiguous cases
# may mix groups of auto and manual positions too, but results are harder to predict
Group `R` is meant to help with games that randomly select a file in a group. You can set with `>N` which file will be selected. This way you can quickly edit the TXTP and change the file (you could just comment files too, this is just for convenience in complex cases and testing). You can also set `>-`, meaning "play all", basically turning `R` into `S` (this can be omitted, but it's clearer). Files do need to exist and are parsed before being selected, and it can select groups too.
You can put `?.` in an entry to make a silent (non-existing) file. By default takes channels and sample rate of nearby files, can be combined with regular commands to configure.
```
intro.adx
?.silence #b 3.0 # 3 seconds of silence
loop.adx
```
It also doubles as a quick "silence this file" while keeping the same structure, for complex cases. The `.` can actually be anywhere after `?`, but must appear before commands to function correctly.
```
layer1a.adx
?layer1b.adx
group = -L2
?layer2a.adx
layer2b.adx
group = -L2
group = -S2
```
Most of the time you can do the same with `#p`/`#P` padding commands or `#@volume 0.0`. This is mainly for complex engines that combine silent entries in twisted ways. You can't silence `group` with `?group` though since they aren't considered "entries".
Internally, `mode = segment/layers` are treated basically as a (default, at the end) group. You can apply commands to the resulting group (rather than the individual files) too. `commands` would be applied to this final group.
You can set file commands by adding multiple `#(command)` after the name. `#(space)(anything)` is considered a comment and ignored, as well as any command not understood.
### Channel removing/masking for channel subsongs/layers
**`C(number)`** (single) or **`#C(number)~(number)`** (range), **`#c(number)`**: set number of channels to play. You can add multiple comma-separated numbers, or use ` ` space or `-` as separator and combine multiple ranges with single channels too.
If you use **`C(number)`** (uppercase) it will remove non-selected channels. This just a shortcut for macro `#@track` (described later):
If you use **`c(number)`** (lowercase) it doesn't change the final number of channels, just mutes non-selected channels (for backwards compatibility).
- **`#p(time-begin)`**: pad song beginning (not between loops)
- **`#P(time-end)`**: pad song song end (not between loops)
- **`#r(time-begin)`**: remove/trim song beginning (not between loops)
- **`#R(time-end)`**: remove/trim song end (not between loops)
*(time)* can be `M:S(.n)` (minutes and seconds), `S.n` (seconds with dot), `0xN` (samples in hex format) or `N` (samples). Beware of 10.0 (ten seconds) vs 10 (ten samples). Fade config always assumes seconds for compatibility.
Based on these values and the player config, vgmstream decides a final song time and tweaks audio output as needed. On simple cases this is pretty straightforward, but when using multiple settings it can get a bit complex. You can even make layered/segments with individual config for extra-twisted cases. How all it all interacts is explained later.
Usage details:
- Settings should mix with player's defaults, but player must support that
- TXTP settings have priority over player's
-`#L` loops forever even if player is set to play 2 loops
-`#l` loops N times even if player is set to loop forever
- setting loop forever ignores some options (loops/fades/etc), but are still used to get final time shown in player
- setting target body time overrides loops (`#b` > `#l`)
-`body` is the main audio decode, possibly including N loops or silence
-`fade-delay` waits after body (decode actually continues so it's an extension of `body`)
-`fade-period` fades-out last decoded part
-`trim-begin` removes audio from `body` (mainly useful when using `#l`
-`pad-end` adds silence after everything else
- final time is: `pad-begin + body - trim-begin - trim-end + fade-delay + fade-period + pad-end`
-`#R 10.0 #b 60.0` plays for 50s, but it's the same as `#b 50.0`
-`#d 10.0 #b 60.0` plays for 70s, but it's the same as `#b 70.0`
- big trims may be slow
Those steps are defined separate from "base" decoding (file's actual loops/samples, used to generate the "body") to simplify some parts. For example, if pad/trim were part of the base decode, loop handling becomes less clear.
**`#t(time)`**: trims the file so base sample duration (before applying loops/fades/etc) is `(time)`. If value is negative subtracts `(time)` to duration.
*(time)* can be `M:S(.n)` (minutes and seconds), `S.n` (seconds with dot), `0xN` (samples in hex format) or `N` (samples). Beware of 10.0 (ten seconds) vs 10 (ten samples).
This changes the internal samples count, and loop end is also adjusted as needed. If value is bigger than max samples it's ignored (use `#l(loops)` and similar play config to alter final play time instead).
*(time)* can be `M:S(.n)` (minutes and seconds), `S.n` (seconds with dot), `0xN` (samples in hex format) or `N` (samples). Beware of 10.0 (ten seconds) vs 10 (ten samples).
Wrong loop values (for example loop end being much larger than file's samples) will be ignored, but there is some leeway when using seconds for the loop end.
Use this feature responsibly, though. If you find a format that should loop using internal values that vgmstream doesn't detect correctly, consider reporting the bug for the benefit of all users and other games using the same format, and don't throw out the original loop definitions (as sometimes they may not take into account "encoder delay" and must be carefully adjusted).
Note that a few codecs may not work with arbitrary loop values since they weren't tested with loops. Misaligned loops will cause audible "clicks" at loop point too.
**`#a`** (loop start segment), **`#A`** (loop end segment): mark looping parts in segmented layout.
For segmented layout normally you set loop points using `loop_start_segment` and `loop_end_segment`. It's clean in simpler cases but can be a hassle when lots of files exist. To simplify those cases you can set "loop anchors":
Needed for a few games set a sample rate value in the header but actually play with other (applying some of pitch or just forcing it), resulting in wrong play speed if not changed. Higher rates will sound faster, and lower rates slower.
Proper mixing requires some basic knowledge though, it's further explained later. Order matters and operations are applied sequentially, for extra flexibility at the cost of complexity and user-friendliness, and may result in surprising mixes. Typical mixing operations are provided as *macros* (see below), so try to stick to macros and simple combos, using later examples as a base.
This can be applied to individual layers and segments, but normally you want to use `commands` to apply mixing to the resulting file (see examples). Per-segment mixing should be reserved to specific up/downmixings.
Mixing must be supported by the plugin, otherwise it's ignored (there is a negligible performance penalty per mix operation though, though having *a lot* will add up).
**`#@(macro name and parameters)`**: adds a new macro
Manually setting values gets old, so TXTP supports a bunch of simple macros. They automate some of the above commands (analyzing the file), and may be combined, so order still matters.
-`track (channels)`: makes a file of selected channels (drops others)
-`layer-v (N) (channels)`: for layered files, mixes selected channels to N channels with default volume (for layered vocals). If N is ommited (or 0), automatically sets highest channel count among all layers plus does some extra optimizations for (hopefully) better sounding results. May be applied to global commands or group config.
-`layer-e (N) (channels)`: same, but adjusts volume equally for all layers (for generic downmixing)
-`layer-b (N) (channels)`: same, but adjusts volume focusing on "main" layer (for layered bgm)
`channels` can be multiple comma-separated channels or N~M ranges and may be omitted were applicable to mean "all channels" (channel order doesn't matter but it's internally fixed).
vgmstream supports a few common extensions that confuse plugins, like .wav/ogg/aac/opus/etc, so for them those extensions are disabled and are expected to be renamed to .lwav/logg/laac/lopus/etc. TXTP can make plugins play those disabled extensions, since it calls files directly by filename.
Combined with TXTH, this can also be used for extensions that aren't normally accepted by vgmstream.
### TXTP combos
TXTP may even reference other TXTP, or files that require TXTH, for extra complex cases. Each file defined in TXTP is internally parsed like it was a completely separate file, so there is a bunch of valid ways to mix them.
All defined files must exist and be parseable by vgmstream, and general config like `mode` must make sense (not `mde = layers` or `mode = laye`). *subdir* may even be relative paths like `../file.adx`, provided your OS supports that.
Commands may add spaces as needed, but try to keep it simple. They *must* start with `#(command)`, as `#(space)(anything)` is a comment. Commands without corresponding file are ignored too (seen as comments), while incorrect commands are ignored and skip to next, though the parser may try to make something usable of them (this may be change anytime without warning):
The parser is fairly simplistic and lax, and may be erratic with edge cases or behave unexpectedly due to unforeseen use-cases and bugs. As filenames may contain spaces or # inside, certain name patterns could fool it too. Keep all this in mind this while making .txtp files.
To simplify TXTP creation, if the .txtp doesn't set a name inside then its filename is used directly, including config. Note that extension must be included (since vgmstream needs a full filename). You can set `commands` inside the .txtp too:
Sometimes games use multiple channels in uncommon ways, for example as layered tracks for dynamic music (like main+vocals), or crossfading a stereo song to another stereo song. In those cases we normally would want a stereo track, but vgmstream can't guess how channels are used (since it's game-dependent). To solve this via TXTP you can set mixing output and volumes manually.
A song file is just data that can contain a (sometimes unlimited) number of channels, that must play in physical speakers. Standard audio formats define how to "map" known channels to speakers:
-`1.0: FC`
-`2.0: FL, FR`
-`2.1: FL, FR, LF`
-`4.0: FL, FR, SL, SR`
-`5.1: FL, FR, FC, LF, SL, SR`
- ... (channels in order, where FL=front left, FC=front center, etc)
If you only have stereo speakers, when playing a 5.1 file your player may silently transform to stereo, as otherwise you would miss some channels. But a game song's channels can be various things: standard mapped, per-format map, per-game, multilayers combined ("downmixed") to a final stereo file, music + all language tracks, etc. So you may need to decide which channels drop or combine and their individual volumes via mixing.
Say you want to mix 4ch to 2ch (ch3 to ch1, ch4 to ch2). Due to how audio signals work, mixing just combines (adds) sounds. So if channels 1/2 are LOUD, and channels 3/4 are LOUD, you get a LOUDER (clipping) channel 1/2. To fix this we set mixing volume, for example: `mix channel 3/4 * 0.707 (-3db/30% lower volume) to channel 1/2`: the resulting stereo file is now more listenable. Those volumes are just for standard audio and may work ok for every game though.
TXTP has a few macros that help you handle most simpler cases (like `#C 1 2`, `#@layer-v`), that you should use when possible, but below is a full explanation of manual mixing (macros just automate these options using some standard formulas).
Performance isn't super-well tuned at the moment, and lots of mixes do add up (shouldn't matter in most simple cases though). Mixing order does affect performance, if you need to optimize:
```
# apply volume then downmix = slower (more channels need volume changes)
song#m0*0.5,1d
# downmix then apply volume = faster (less channels need volume changes)
When handling a new file, vgmstream reads its loop points and total samples. Based on that and player/TXTP's config it decides actual "final time" that is used to play it. "internal file's samples" and "external play duration" are treated separately, so a non-looping 100s file could be forced to play for 200s (100s of audio then 100s of silence), or a looping 100s file could be set to play 310s (so 3 loops + 10s fade).
For example, with a 100s file that loops from 5..90s, `file.adx #p 5.0 #r 10.0 #l 2.0 #f 10.0 #P 2.0` means:
- pad with 5s of silence first
- decode first loop 0..90s, but trim first 10s seconds, ending up like 10..90s
- decode second loop 5..90 (trim doesn't affect other loops)
- during 3rd loop fade-out audio for 10 seconds
- pad end by 2 seconds
- song ends and player moves to next track
- final time would be: `5s + (90 - 10)s + 85s + 10s + 2s = 182s`
When you use commands to alter samples/looping it actually changes the "internal decoding", so final times are calculated differently So adding `#t -5.0 #I 5.0 85.0` to the above would result in a final time of `5s + (85 - 10)s + 80s + 10s + 2s = 172s`.
### Complex cases
Normally the above is mostly transparent, and vgmstream should "just work" with the player's settings. To understand how some extra-complex cases are handled, here is what it happens when you start having things over things over things.
Internally, a regular file just plays once or keeps looping (if loops are set) for a duration that depends on config (pads/fades/etc, with no settings default duration would be file's samples). Anything past pre-calculated final time would be silence (player should stop at that point, unless "loop forever" is set).
Behavior for layers and segments is a bit more complex. First, a layered/segmented vgmstream is made of multiple "internal vgmstreams", and one "external vgmstream" that manages them. The external takes its values from the internals:
- layered samples: highest base sample count among all internals
- layered loops: inherited if all internals share loop points, not set otherwise
- segmented samples: sum of all internals
- segmented loops: not set (uses `loop segment` settings instead)
Play config (loops/fades/etc) is normally applied to the "base" external vgmstream, and same applies to most TXTP commands (changing some values like sample rate only makes sense in the external part). This allows looping the resulting vgmstream in sync.
However each internal vgmstream can have its own config. This means first layer may be padded and internally looped before going to next one. In that case external vgmstream doesn't inherit loop points, but internals *can* be looped, and sample count is the calculated final duration (so segment of 30s that loops 2 times > external time of 60s). More or less, when using play config on an internal vgmstream it becomes a solid "clip". So when dealing with complex layouts make sure you only put play config in the internal vgmstream if you really need this, otherwise set the external's config.
Since layout/segments can also contain other layouts/segments this works in cascade, and each part can be configured via `groups`, as explained before). Certain combos involving looping (like installing loops in the internal and external vgmstreams) may work unexpectedly.
### Examples
Example with a file of 100s, loop points 10s..95s, no settings.
```
#l 2.0 #f 10.0 / time=190s (default settings for most players)
#i #l 2.0 #f 10.0 / time=100s (loop times and fades don't apply with loop disabled)
[0..100]
#E #l 2.0 #f 10.0 / time=210s (ignores original loops and force 0..100)
[0..100][0..100][0..10)
#l 2.5 / time=185s (ends in half loop)
[0..10..95][10..95][10..95][10..53]
#l 2.0 #F / time=185s (play rest of file after all loops)
[0..10..95][10..95..100s]
#l 2.3 #F #f 10.0 / time=185s (2.3 becomes 2.0 to make sense of it, and fade is removed)
[0..10..95][10..95..100s]
#p 10.0 #l 2.0 / time=190 (pad 10 seconds, then play normally)
(0..10)[0..10..95][10..95]
#r 5.0 #l 2.0 / time=175s (removes first seconds of the output, then loops normally)
[5..10..95][10..95]
#r 5.0 #b 180 / time=175s (same as the above, note that 180 is base body including non-looped part)
[5..10..95][10..95]
#r 25.0 #l 2.0 / time=155s (removes part of loop start, but next loop will play it)
[25..95][10..95]
#p 10.0 #r 25.0 #l 2.0 / time=165s (pad goes before trim, and trim is applied over file's output)
(0..10)[25..95][10..95]
#b 120.0 #i / time = 120s (force time, no sound after 100s)
[0...100](0..20)
#b 120s #l 2.0 / time = 120s (force time, stops in the middle of looping)
[0..10..95][10..35]
```
Using *loop forever* is a bit special. Play time is calculated based on config to be shown by the player, but it's ignored internally (vgmstream won't stop looping/playing after that time).
```
#L #l 1.0 / time=95s (loops forever, but time info is shown using defaults)
#L #l 1.0 #f 8.0 / time=103s (song never ends, so fade isn't applied, but is part of shown time)
[0..10..95][10..95] ... [10..95] ...
```
With segments/layers note the difference between this:
```
# play config is set in the external vgmstream
bgm1a.adx
bgm1b.adx
layout = layered
commands = #l 2.0
```
and this:
```
# play config is set in the internal vgmstream, and shouldn't set the external's
# (may change other settings like sample rate, but not others like loops)
bgm1a.adx #l 2.0
bgm1b.adx #l 2.0
layout = layered
#commands = ## doesn't inherit looping now
```
It's not possible to do "inside" padding or trims (modifying in the middle of a song), but you can achieve those results by combining trimmed/padded segments (used to simulate unusual Wwise loops). You can do internal loops per part too.
```
#???
[0..10..50][10..95]
#???
[10..95](0..10)[10..95]
#segmented: play 2 clips with padding between
[10..95] #r 10.0 #b 95.0
(0..10)[10..95] #r 10.0 #b 95.0 #p 10.0
layout = segmented
loop_mode = auto
#segmented: play 2 clips sequentially and loops them
[0..10..50] #b 50.0
[10..95] #r 10.0 #b 95.0
layout = segmented
loop_mode = auto
#layered: plays a single track with "sequential" clips
[0..10..50] #b 50.0
(0......50)[10..95] #p 50.0 #r 10.0 #b 95.0
layout = layered
#segmented: loop partially a segment before going next
[0..10] #b 10.0
[10..100][0..50] #E#l 1.5 #r 10.0
layout = segmented
loop_start_segment = 2 #note this plays 10s then loops the *whole* 140s part (new 2nd segment)
```
Since padding has the effect of delaying the start of a part, it can be used for unaligned transitions.
```
# layered: plays a single track with *overlapped* clips (first 10s)
