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 commands described below.
## TXTP MODES
TXTP can join and play together multiple songs in various ways by setting a file list and mode:
*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).
Mixing sample rates is ok (uses max) but channel number must be equal for all files. You can use mixing (explained later) to join segments of different channels though.
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). If all layers share loop points they are automatically kept.
You can set "groups" to 'fold' various files into one, as layers or segments, to allow complex cases. This is an advanced settings 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:
# commands to make a 6ch with segmented intro + loop:
introA_2ch.at3
mainA_2ch.at3
introB_2ch.at3
mainB_2ch.at3
introC_2ch.at3
mainC_2ch.at3
# - group intro/main pairs as segments, starting from 1 and repeating for A/B/C
group = S2R
# - play all as layer (can't set loop_start_segment in this case)
mode = layers
# you could also set: group = L and mode = mixed, same thing
```
`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`: file start (optional, default is 1 = first)
-`type`: group as S=segments or L=layers
-`count`: number of files in group (optional, default is all)
-`repeat`: R=repeat group of `count` files until end (optional, default is no repeat)
Examples:
-`L`: take all files as layers (equivalent to `mode = layers`)
-`S`: take all files as segments (equivalent to `mode = segments`)
-`3L2`: layer 2 files starting from file 3
-`2L3R`: group every 3 files from position 2 as layers
-`1S1`: segment of one file (useless thus ignored)
Internally, `mode = segment/layers` are treated basically the same 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.
```
mainA_2ch.at3
mainB_2ch.at3
group = L #h44100
commands = #h48000#overwrites
```
Segments and layer settings and rules still apply when making groups, so you can't group segments of files with different total channels. To do it you could use commands to "downmix" the group first:
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).
- **`#L`**: play forever (if loops are set set and player supports it)
- **`#i`**: ignore and disable loop points, simply stopping after song's sample count (if file loops)
- **`#e`**: set full looping (end-to-end) but only if file doesn't have loop points (mainly for autogenerated .txtp)
- **`#E`**: force full looping (end-to-end), overriding original loop points
- **`#F`**: don't fade out after N loops but continue playing the song's original end (if file loops)
*processing*
- **`#l(loops)`**: set target number of loops, (if file loops) used to calculate the body part (modified by other values)
- **`#b(time)`**: set target time (even without loops) for the body part (modified by other values)
- **`#f(fade period)`**: set (in seconds) how long the fade out lasts after target number of loops (if file loops)
- **`#d(fade delay)`**: set (in seconds) delay before fade out kicks in (if file loops)
- **`#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`)
-`trim-begin` gets audio from `body`, but immediately removes it (substracts time from body)
-`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 substracts `(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).
**`#I(loop start time) [loop end time]`**: force/override looping values (same as .pos but nicer). Loop end is optional and defaults to total samples.
*(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.
#bgm01.ogg#I 1421387 4212984 # equivalent, end is 4212984
#bgm01.ogg#I32.231 1_35.533 # equivalent, end over file samples (~4213005) but adjusted to 4212984
#bgm01.ogg#I 1421387 4212985 # ignored, end over file samples
#bgm01.ogg#I32.231 1_37 # ignored, end over file (~4277700) but clearly wrong
```
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.
**`#h(sample rate)`**: changes sample rate to selected value (within some limits).
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.
**Super Paper Mario (Wii)**
```
btl_koopa1_44k_lp.brstm#h22050 #in hz
```
**Patapon (PSP)**
```
ptp_btl_bgm_voice.sgd#s1#h11050
```
Note that this doesn't resample (change sample rate while keeping play speed).
* not necessarily fades, as you could set length 0 for volume "bumps" like `1.0~0.5`
*`(shape)` can be `{` = fade, `(` = crossfade, other values are reserved for internal testing and may change anytime
*`(time-start)`+`(time-length)` make `(time-end)`
* between `(time-pre)` and `(time-start)` song uses `(volume-start)`
* between `(time-start)` and `(time-end)` song gradually changes `(volume-start)` to `(volume-end)` (depending on `(shape)`)
* between `(time-end)` and `(time-post)` song uses `(volume-end)`
*`time-pre/post` may be -1 to set "file start" and "file end", cancelled by next fade
Considering:
-`N` and `M` are channels (*current* value after previous operators are applied)
- channel 1 is first
- channel 0 is shorthand for all channels where applicable (`0*V`, `0=V`, `0^...`)
- may use `x` instead of `*` and `_` instead of `:` (for mini-TXTP)
-`(volume)` is a `N.N` decimal value where 1.0 is 100% base volume
- negative volume inverts the waveform (for weird effects)
-`(position)` can be `N.NL` or `NL` = N.N loops
- if loop start is 1000 and loop end 5000, `0.0L` = 1000 samples, `1.0L` = 5000 samples, `2.0L` = 9000 samples, etc
-`(time)` can be `N:NN(.n)` (minutes:seconds), `N.N` (seconds) or `N` (samples)
- represents the file's global play time, so it may be set after N loops
- beware of `10.0` (ten seconds) vs `10` (ten samples)
- may not work with huge numbers (like several hours)
- adding trailing channels must be done 1 by 1 at the end (for stereo: `3u,4u,(...)`
- nonsensical values are ignored (like referencing channel 3 in a stereo file)
Main usage would be creating stereo files for games that layer channels.
```
# quad to stereo: all layers must play at the same time
# - mix 75% of channel 3/4 into channel 1/2, then drop channel 3 and 4
song#m1+3*0.75,2+4*.75,3D
# quad to stereo: only channel 3 and 4 should play
# - swap channel 1/2 with 3/4, then drop channel 3/4
song#m1-3,2-4,3D
# also equivalent, but notice the order
# - drop channel 1 then 2 (now 1)
song#m1d,1d
```
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. 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).
### Macros
**`#@(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.
-`volume N (channels)`: sets volume V to selected channels
-`track (channels)`: makes a file of selected channels
-`layer-v N (channels)`: mixes selected channels to N channels with default volume (for layered vocals)
-`layer-b N (channels)`: same, but adjusts volume depending on layers (for layered bgm)
-`layer-e N (channels)`: same, but adjusts volume equally for all layers (for generic downmixing)
-`remix N (channels)`: same, but mixes selected channels to N channels properly adjusting volume (for layered bgm)
-`crosstrack N`: crossfades between Nch tracks after every loop (loop count is adjusted as needed)
-`crosslayer-v/b/e N`: crossfades Nch layers to the main track after every loop (loop count is adjusted as needed)
-`downmix`: downmixes up to 8 channels (7.1, 5.1, etc) to stereo, using standard downmixing formulas.
`channels` can be multiple comma-separated channels or N~M ranges and may be ommited 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.
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:
- *boss2_3ningumi_ver6.adx#l2#F.txtp*: loop twice then play song end file normally
- etc
## MIXING
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-dependant). 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 2`), 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)
song#m1d,0*0.5
```
## UNDERSTANDING PLAY CONFIG AND FINAL TIME
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 separatedly, 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)