You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The client currently relies on an adjacent text file for reading loop points in audio (e.g. Track.opus + Track.opus.txt with loop_start / loop_end / loop_length). This works for base content (local), but it creates a couple of issues:
For music streamed directly via /play command in OOC, it's impossible to make the music loop unless the audio file was rendered this way beforehand (potentially skipping the "intro" segment of a track).
Extra "clutter" in music folders (one extra file per track).
Describe the solution you'd like
Add support for reading loop points from audio file metadata when an adjacent .txt file is not present, while keeping current behavior the same for existing content.
Proposed behavior (backwards-compatible):
If Track.opus.txt exists: keep current behavior (no changes for existing content packs).
If no adjacent .txt exists: attempt to read loop points from embedded metadata tags in the audio file.
Supported keys (case-insensitive): LOOPSTART, LOOPEND, LOOPLENGTH and also loop_start, loop_end, loop_length.
Values are interpreted the same way as the existing .txt fields (i.e., samples).
If no loop tags are found (or values are invalid): fall back to default non-loop behavior.
Describe alternatives you've considered
No alternatives considered at this time. The goal is to keep the existing adjacent .txt behavior while adding metadata as an optional fallback.
Additional context
Opus supports custom metadata fields (as well as being the most optimal lossy format for streaming, seeing as how the majority of KFO music uses this codec), so loop points can be embedded directly in the audio file.
The suggested tag names are commonly used in various audio/game workflows, so supporting them case-insensitively would make compatibility easier.
Is your feature request related to a problem? Please describe.
The client currently relies on an adjacent text file for reading loop points in audio (e.g.
Track.opus+Track.opus.txtwithloop_start/loop_end/loop_length). This works for base content (local), but it creates a couple of issues:/playcommand in OOC, it's impossible to make the music loop unless the audio file was rendered this way beforehand (potentially skipping the "intro" segment of a track).Describe the solution you'd like
Add support for reading loop points from audio file metadata when an adjacent
.txtfile is not present, while keeping current behavior the same for existing content.Proposed behavior (backwards-compatible):
Track.opus.txtexists: keep current behavior (no changes for existing content packs)..txtexists: attempt to read loop points from embedded metadata tags in the audio file.LOOPSTART,LOOPEND,LOOPLENGTHand alsoloop_start,loop_end,loop_length..txtfields (i.e., samples).Describe alternatives you've considered
.txtbehavior while adding metadata as an optional fallback.Additional context
Opussupports custom metadata fields (as well as being the most optimal lossy format for streaming, seeing as how the majority of KFO music uses this codec), so loop points can be embedded directly in the audio file.