openmpt123: Getting 16Bit WAV PCM on stdout

[Joker]

EDIT:
I've figured out the magic "sox" options. Still wondering why "--output -" produces only a header though.
openmpt123 --no-float --stdout <MOD> | sox -t raw -b 16 -e signed -c 2 -r 48000 - -t wav - | stereo_tool_cmd_64 --quiet - -  | aplay --quiet

I'm playing with the "Maximizer - MOD Files (ProTracker).sts" from the following URL if anyone is wondering:
https://forums.stereotool.com/viewtopic.php?t=3831


I'm trying to pipe 16bit PCM WAV into stereotool. I get the correct format with --no-float,
however when using "--output -" i only end up with 256 bytes of data which is probably
only the header.

This works:
openmpt123 --no-float --output tmpfile <mod>
cat tmpfile | stereo_tool_cmd_64 --quiet - - | aplay --quiet

This fails:
openmpt123 --no-float --output - <mod> | stereo_tool_cmd_64 --quiet - - | aplay --quiet

The reason it fails is because "openmpt123 --no-float --output - <mod> > file" only produces
256 bytes of data.

The "--stdout" option seems to provide "too" raw output for further processing.
It would be helpful if someone knew what sox parameters could convert that
into the required 16bit PCM WAV format.

openmpt123 is clearly meant to accept "-" as stdout for --output, otherwise it would reject
"-" or create a file named "-" in the first place. Is this a bug i'm hitting?

[manx]

I'm trying to pipe 16bit PCM WAV into stereotool.

WAV is unsuitable for piping to stdout, because a WAV header needs to contain the length of the contained data, which cannot be known precisely before the file is finished. Updating the length later would require seeking, which is impossible for piped output. Do NOT try use WAV for pipe output.

I get the correct format with --no-float,
however when using "--output -" i only end up with 256 bytes of data which is probably
only the header.

This works:
openmpt123 --no-float --output tmpfile <mod>
cat tmpfile | stereo_tool_cmd_64 --quiet - - | aplay --quiet

This fails:
openmpt123 --no-float --output - <mod> | stereo_tool_cmd_64 --quiet - - | aplay --quiet

The reason it fails is because "openmpt123 --no-float --output - <mod> > file" only produces
256 bytes of data.

openmpt123 is clearly meant to accept "-" as stdout for --output, otherwise it would reject
"-" or create a file named "-" in the first place. Is this a bug i'm hitting?

No, this is not meant to work. openmpt123 passes the passed filename ("-") verbatim to the backend that writes the output. In the default case, this would be libsndfile for WAV (the default) output. Libsndfile apparently chooses to write to stdout, which may be a bug in libsndfile (I did not investigate this further). There sadly is absolutely nothing openmpt123 could do here. The correct behaviour would be to write to a file called "-".

Try
openmpt123 --stdout --samplerate 48000 --channels 2 --no-float SOMEFILE.MOD | aplay --quiet --rate=48000 --channels=2 --format=s16_le

The "--stdout" option seems to provide "too" raw output for further processing.
It would be helpful if someone knew what sox parameters could convert that
into the required 16bit PCM WAV format.

openmpt123 --stdout --samplerate 48000 --channels 2 --no-float SOMEFILE.MOD | sox -t raw -r 48k -e signed -b 16 -c 2 - output.wav
Also note: Always specify the full triplet of samplerate, sampleformat, and channels for headerless RAW output and input because defaults might change in future versions.

If you want to preserve metadata, I suggest roundtripping through a file instead of using stdout though, as openmpt123 currently does not support writing a metadata-supporting format to stdout:
openmpt123 --output output.wav SOMEFILE.MOD

Is there any specific reason why you want to use 16bit PCM instead of the default 32bit float PCM? Module files can contain signals >0dBFs (either as intended for formats that specify absolute volume, or simply as rendered by libopenmpt) and floating point PCM provides better signal-to-noise ratio than 16bit PCM, which is particularly useful if you perform further processing (which is what I gather stereotool does (I am not familiar with stereotool though)).

[Joker]

Is there any specific reason why you want to use 16bit PCM instead of the default 32bit float PCM? Module files can contain signals >0dBFs (either as intended for formats that specify absolute volume, or simply as rendered by libopenmpt) and floating point PCM provides better signal-to-noise ratio than 16bit PCM, which is particularly useful if you perform further processing (which is what I gather stereotool does (I am not familiar with stereotool though)).

The reason for 16bit PCM WAV is because, that's what stereo_tool accepted as input. There is a bit depth option but i didn't really see
something to accept float. I'll check the documentation a bit more to see if there's such an option.

Update:
Found the option for a full 32bit float chain. The bit option was "32f" while i falsely assumed only "32" works.
Sox is still required for "-t raw" to "-t wav" though, otherwise there's just noise:
openmpt123 --stdout <MOD>) | sox -t raw -b 32 -e float -c 2 -r 48000 - -t wav - | stereo_tool_cmd_64 --bitspersample 32f --quiet - -  | aplay --quiet