Composers Desktop Project Forum

I now (re)discovered that prepending "-f" to the output file name of the (time domain(*)) programs, a 32 bit floating point file will be produced. However, it looks to me that the processing internally is not floating point or is handled incorrectly.

A simple test : use the modify loudness program to increase the volume of an already loud 16 bit file that has peaks at the maximum range, using the -f option. The expected result is that when the resulting file's volume is again reduced enough in some program known to do the floating point calculations as expected (such as Cockos's Reaper), there would be no distortion. The files obtained from the CDP modify loudness program however do not behave like that. They are permanently clipped to produce distortion. This leads to me to believe that either the internal processing does not happen as floating point or that the output is clipped into the -1.0...1.0 range, effectively making the floating point output file option nearly useless. The same behavior can be observed with the other CDP programs, but modify loudness is the clearest way to reproduce this behavior.

I don't bring this up due to "golden ears" concerns. The value of having a clean 32/64 bit floating point processing chain to me is almost entirely in the available volume headroom when the processing chain is working correctly. Ie, even if a DSP calculation ends up producing samples beyond the nominal -1.0...1.0 range, the signal can later be brought down in volume to not distort the monitoring output or to make it work better when mixing. If how this is supposed to work is not clear from the description, I can produce a demonstration as a video or a set of audio files.

(*) It seems that the spectral processings now always result in 16 bit PCM files, which seems like an obvious bug. (Unless the pvoc program and the CDP programs that transform the .ana files actually just are 16 bit only...?)

That gives me a page, but the download links don't do anything.

I found an archive at the bitbucket site:

https://bitbucket.org/xenakios/cdp-python-reascripts/downloads

Will that do?

The ge.tt download works for me, but perhaps there's some mysterious reason it won't work for you.

Yes, the bitbucket download should be nearly identical to the zip archive in ge.tt. (Unless I happen to push a new commit to Bitbucket before you try downloading that.)

That's a very good idea! Thanks for the link.  It is interesting also because Reaper is the DAW engine used  for the EarSketch project at Georgia tech:

http://earsketch.gatech.edu/

So this could be a(nother) way to smuggle some CDP into schools!

Thanks for the feedback!

Now that I've actually written down the procedure to get those scripts working, I feel it might be a bit too complicated, for even people who would be quite dedicated to get it working...

If I implemented these as a C++ Reaper extension plugin, the set up for the user would be much more simple. But unfortunately I don't have a Macintosh (or even a suitable machine to use as a Hackintosh) to build the C++ plugin for OS-X. Well, I will have to see what I will end up doing.

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.)