Encoding to WavPack with SoX always produce a -hh .wv file, no matter what -C FACTOR is specified. Is there any way to use the extra encode processing -xn with SoX?
I just took a look at the SoX source and, yes, the only encoding mode ever selected is very high (-hh), with no extra processing.
I think the easiest thing would be to use the WavPack command-line encoder to re-encode to the settings you desire after generating the WavPack file with Sox. Since it's lossless you're just wasting a little time and the WavPack command-line program makes this really easy. I actually work this way with the abcde CD ripper which doesn't allow me to configure as much as I'd like. I assume if you're using SoX then using another command-line program would not be a stretch.
I haven't build SoX in a long time, but of course it would be pretty easy to modify the source and re-build to use the mode you want, or even use the compression factor to choose modes sort of like FFmpeg does.
you can also maybe output data to stdout as uncompressed and put it as input to wavpack, then there's also no need for temporary files. wavpack supports pipe input, I don't remember if sox supports pipe output but I'm almost certain it does.
I tried piping sox to wavpack and works very well but the metadata is lost.
Ffmpeg with -compression_level 3 seems a good alternative as it keeps metadata and embedded cuesheet, and produce an identical size, bitrate and MD5 file as the two-step-transcoding with sox and wavpack (same audio MD5), but with mediainfo or fb2k it appears as WavPack normal instead of high, and also the attached images (covers, etc.) are lost.
I will try to rebuild SoX, as it seems to be the best long term solution.
metadata can be copied over as a separate step with another tool(s)... but that's a bit more complicated
... but with mediainfo or fb2k it appears as WavPack normal instead of high ...
It is a known issue that encoding parameters (e.g., high or fast, extra modes) are not
stored by FFmpeg, even though the parameters are used during encoding. I have never considered this a really big deal because it's informational only, but I might look into making a patch for it when I do some other FFmpeg work.
I have not tried it, but FFmpeg can also use libwavpack for encoding, in which case that information would
be stored (but I have no idea what else might be different).