Songs from games newer than 25 lag on first keysound #2

New Issue

Scan · 2024-08-29T04:21:07Z

Scan commented

2024-08-29 04:21:07 +00:00

As the title describes, with the current configuration music from 25 and newer lags slightly on the first keysound, causing the keysounds to be behind the track itself.

This is likely unrelated to the tools. Probably has to do with 25 and onward using .s3p wma containers for songs instead of the proprietary lossless .2dx wav containers, combined with the fact that the current configuration is making use of proprietary dsdmo.dll in its wineprefix.

Two venues to test this:

Convert all the songs to .2dx using https://github.com/mon/2dxTools & observe changes
Supply the wineprefix with dsdmo from latest upstream Wine build (has fixes for FX, with Compressor and Echo having support + stubs for Flanger and Chorus, it seems...) instead of one from a real win10 system

As the title describes, with the current configuration music from 25 and newer lags slightly on the first keysound, causing the keysounds to be behind the track itself. This is likely unrelated to the tools. Probably has to do with 25 and onward using .s3p wma containers for songs instead of the proprietary lossless .2dx wav containers, combined with the fact that the current configuration is making use of proprietary dsdmo.dll in its wineprefix. Two venues to test this: - Convert all the songs to .2dx using https://github.com/mon/2dxTools & observe changes - Supply the wineprefix with dsdmo from latest upstream Wine build (has fixes for FX, with Compressor and Echo having support + stubs for Flanger and Chorus, it seems...) instead of one from a real win10 system

Scan commented

2024-08-29 04:25:44 +00:00

could also be gstreamer jank?? idk lol, will test tmo im tired

Scan commented

2024-08-29 20:53:03 +00:00

Supplying & registering the wineprefix with dsdmo from wine-9.16 also lets the game boot without disable-fx patches, but exhibits the same problems so its likely to do with the way gstreamer is handling s3p containers in Wine.

Need to test using 30 with the disable-fx patches applied and see if the same behaviour is exhibited. If behaviour is the same, it's an audio container processing issue. If its different, than the problems lie within dsdmo and all games may require disable-fx patches.

Still need to test:

Converting a song from 25 and newer to use .2dx container format instead of s3p & observe changes

This issue is probably better suited for the getting-started repo, or the automation scripts but those werent ready at the time i discovered this

Supplying & registering the wineprefix with dsdmo from wine-9.16 also lets the game boot without disable-fx patches, but exhibits the same problems so its likely to do with the way gstreamer is handling s3p containers in Wine. Need to test using 30 with the disable-fx patches applied and see if the same behaviour is exhibited. If behaviour is the same, it's an audio container processing issue. If its different, than the problems lie within dsdmo and all games may require disable-fx patches. Still need to test: - Converting a song from 25 and newer to use .2dx container format instead of s3p & observe changes This issue is probably better suited for the getting-started repo, or the automation scripts but those werent ready at the time i discovered this

Scan commented

2024-08-30 00:29:53 +00:00

Unpacking the .s3p's .wma files and converting them to 573's former audio standard (256kbps MS-ADPCM .wav, which is not lossless at all, sorry for assuming all wav is lossless lol, its uncompressed) and repacking them back into .2dx fixes these issues. Only tested with one song but I think it's safe to assume this works across the board.

Surely a method, but it feels pretty invasive (and insanely tedious without a script). Need to find a way to handle this nicely, but for now the following should work for individual songs:

.\s3p_extract song_id.s3p (Use mon's tools for this)
cd song_id.s3p.out
for i in *.wma; do ffmpeg -i "$i" -acodec adpcm_ms -b:a 256k "${i%.*}.wav"; done (linux/macos)
FOR /F "tokens=*" %G IN ('dir /b *.wma') DO ffmpeg -i "%G" -acodec adpcm_ms -b:a 256k "%~nG.wav" (windows)
rm -R *.wma
.\2dxbuild song_id.2dx

Currently needs to be done on Windows, s3p_extract releases only provide .exe binaries. Might try recompiling it at some point

Only venues left to test:

Use 30 instead of 31 with custom disable-fx patches applied and see if the same behaviour is exhibited. If behaviour is the same, there may be a wider audio processing issues with .wma keysounds contained in .s3p

Unpacking the .s3p's .wma files and converting them to 573's former audio standard (256kbps MS-ADPCM .wav, which is not lossless at all, sorry for assuming all wav is lossless lol, its uncompressed) and repacking them back into .2dx fixes these issues. Only tested with one song but I think it's safe to assume this works across the board. Surely a method, but it feels pretty invasive (and insanely tedious without a script). Need to find a way to handle this nicely, but for now the following should work for individual songs: `.\s3p_extract song_id.s3p` _(Use mon's tools for this)_ `cd song_id.s3p.out` `for i in *.wma; do ffmpeg -i "$i" -acodec adpcm_ms -b:a 256k "${i%.*}.wav"; done` (linux/macos) `FOR /F "tokens=*" %G IN ('dir /b *.wma') DO ffmpeg -i "%G" -acodec adpcm_ms -b:a 256k "%~nG.wav"` (windows) `rm -R *.wma` `.\2dxbuild song_id.2dx` *Currently needs to be done on Windows, s3p_extract releases only provide .exe binaries. Might try recompiling it at some point* Only venues left to test: - Use 30 instead of 31 with custom disable-fx patches applied and see if the same behaviour is exhibited. If behaviour is the same, there may be a wider audio processing issues with .wma keysounds contained in .s3p

Sign in to join this conversation.

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: bm2dnix/spicetools#2