Pvoc 16 bit/mono only?

[Xenakios]

Is it a known issue that pvoc.exe ends up producing 16 bit wav files from the resynthesis? This happens even if my initial wav file that is analyzed is for example 32 bit floating point.

Another thing that I am wondering about is that are the spectral processings really only mono? If it's mono-only, what has been the problem in making those work in stereo or more channels? This isn't really clear from the CDP user documentation for PVOC, the words "mono" or "stereo" don't appear on that documentation page at all...Yet the pvoc anal program only seems to work with mono files.

I've been trying to build pvoc.exe from source code to understand these issues better and to potentially fix them, but unfortunately in the end the pvoc.exe that I was able to build with Visual Studio 2013 doesn't run succesfully when done as a release build. (Debug build appears to run, but there certainly is something wrong since the release build crashes.) I would prefer to not use mingw to build, but I guess I will try that too at some point.

[rwdobson]

It looks like an old bug has resurfaced - indeed pvoc should resynth to the original sample size/type.  I will make sure this is included in the next release.

Regarding the mono question - this is not so easy to change! For long historical reasons the current .ana file format is actually based on WAVE, and the channel field is currently used to indicate the size of the analysis frame (i.e. channels=  FFt bins), so there is no means of defining a stereo or N-channel analysis file.

My solution-in-progress has been to define a new PVOCEX analysis file format (extension .pvx), which supports N-channel data and is now the standard format in Csound. Integrating this into CDP is unfortunately a "non-trivial" task; not least as the question also arises in regard to all the other frequency domain CDP file types-  transposition, etc. Really. new file formats are needed for these too. And then the code for all the spectral processes would need to be updated (where appropriate) to handle multi-channel data. In the meantime, the current version of "pvplay" will play back a stereo .pvx file.

Current recommended practice (in some cases managed behind the scenes in e.g. SoundShaper) is to split multi-channel files into mono files (use channelx from the Toolkit or "housekeep chans"), process each using pvoc as desired, and then re-interleave the outputs using "submix interleave" or "interlx". The same applies to (for example) the distortion programs, as zero crossings are unlikely to coincide across  channels.

That said, multi-channel pvoc processing presents in any case certain technical problems in that as soon as any frequency transformations are applied (including pitch-=shift or time-scaling), the original stereo image is usually destroyed as the  subtle inter-channel phase relationships get knocked around.  Thus in the majority of cases, pvoc is idiomatically a "mono" sound-design process, with successful (or useable) multi-channel results very much dependent both on the nature of the input and on the trasnformation used.

[Xenakios]

It looks like an old bug has resurfaced - indeed pvoc should resynth to the original sample size/type.  I will make sure this is included in the next release.

Regarding the mono question - this is not so easy to change! ...

Thanks for the insights! I was in fact almost sure the pvoc anal->process->pvoc resynth chain used to keep the sample type/size of the originating pcm file. Good to hear it can still be fixed.

Had I managed to compile a working pvoc.exe (I will still work on that though), my preferred way of dealing with this would have been to drop other formats besides 32 bit floating point completely...  IMHO it usually doesn't make sense to keep the original integer format around once processing takes place. (ie, original recordings may well be 16 or 24 bit integer, but once they are processed, it's most often preferable to just get 32 bit floating point files from processings.)

[Xenakios]

It looks like an old bug has resurfaced - indeed pvoc should resynth to the original sample size/type. 

Are there any news on this? I managed to build most of the CDP programs with MinGw (including pvoc), so if there's an easy source code fix, I could pop it in myself...

[simonk]

New versions of pvoc are now available.

Updates to pvoc to restore the proper behaviour with respect to
outfile sample formats;

Mac
www.unstablesound.net/CDP_Updates/pvoc-osx-06-14.zip

Windows 32bit
www.unstablesound.net/CDP_Updates/pvoc-win32-06-14.zip

[Xenakios]

New versions of pvoc are now available.

Updates to pvoc to restore the proper behaviour with respect to
outfile sample formats;

Mac
www.unstablesound.net/CDP_Updates/pvoc-osx-06-14.zip

Windows 32bit
www.unstablesound.net/CDP_Updates/pvoc-win32-06-14.zip

Thanks! I haven't tried yet, but will soon.