Pay someone to build app to split voice samples into pitch and noise components

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

It has been a while since I have used it, but I'm almost sure this is possible with CDP (composers desktop project).

http://www.unstablesound.net/cdp.html

v7 is now free.

Post

Mike Greene wrote:It's an interesting conundrum. (Or paradox, or whatever the word is.) I could forget the Python education and just pay someone to tweak the sms-tools app to do what I need. (Accept 24 bit files, for starters.)...
OK, first, I figured out the sms-tools does indeed accept 32-bit float wav files. I tried this the other day, and noted that the input-file playback feature (">" next to the input file name) doesn't work for float wav files, and kicks out a warning, but I took another look tonight and found that the file does get pulled in correctly (I haven't looked at the input-file playback code, but the problem must be there).

So, if you batch convert your 24-bit files to 32-bit float wav files, you're good with no code changes (for input).

Second, the only reason that the resulting processed files are 16-bit is that sms-tools hard coded that; if you feed scipy 32-bit float arrays, they will gets save as float wav files.

Edit wavwrite (/software/models/utilFunctions.py) to just pass on the float array to scipy's write function (when you restart the models_GUI, it will recompile):

Code: Select all

def wavwrite(y, fs, filename):
	"""
	Write a sound file from an array with the sound and the sampling rate
	y: floating point array of one dimension, fs: sampling rate
	filename: name of file to create
	"""

#	x = copy.deepcopy(y)                         # copy array 
#	x *= INT16_FAC                               # scaling floating point -1 to 1 range signal to int16 range
#	x = np.int16(x)                              # converting to int16 type
#	write(filename, fs, x)
	write(filename, fs, y)     # add this, comment out the above, for 32-bit wav files
It wouldn't be hard to modify the scipy wav code for 24-bit, but more work than this...
My audio DSP blog: earlevel.com

Post

Dumb editorial comment in case it is useful-- Direct reading/writing of the 24 bit audio files is the least-simple uncompressed sample format to use, merely because of the natural byte-alignment of modern processors. One needs to either read the data byte-by-byte into high-bit aligned SInt32 and then convert to Float32, which isn't real slow, but much slower than reading other sample formats. Or alternately write fancier code to read in 32 or 64 bit ints and bit-twiddle them into the high-aligned SInt32's, which is faster but a little trickier. Especially for stereo files.

Not rocket science, but I just find the 24 bit sample format annoying.

A lot of "24 bit" audio drivers, on the low level, expect the driving program to supply high-bit-aligned SInt32. In other words, the three most-significant bytes of the 32 bit int contains the 24 bit data, and the least-significant byte is zero. I believe that is just because 32 bit size values are much faster and simpler for most modern computers to deal with, versus 24 bit sized values.

Float32 seems the most ideal file format to me, for most purposes.

Post

JCJR wrote:Not rocket science, but I just find the 24 bit sample format annoying.
True enough, Jim, though if the code is endian-neutral, there's not much difference (but not so much need to write big-endian friendly code these days).

I prefer float32 as well, insensitive to scaling and clipping. I can't get my musical collaborator to adopt it, though, because he can't bear the idea of giving up more disk space for no good reason :wink:
My audio DSP blog: earlevel.com

Post

Thank you for that wavwrite function, Nigel. When I get a chance to play some more with this stuff, I’ll plug it in.

That’s great if the sms-tools will accept 32 bit float wav files. Interestingly, I hadn’t been able to get the input file playback feature to work with 16 bit files, either, so I’m already kinda used to that. It will play the included wave files, but not for my own files that I made in ProTools. Not a big deal, though, because it does the conversions (I’m playing with “HPN”) just fine.

Here’s a really remedial question, though. (Actually, I have a few remedial questions :D , but here’s the first): How do I batch convert 24 bit files to 32 bit files? Usually I do sample or bit rate conversions in ProTools, but I don’t think there’s a 32 bit option. Is this one of those times where everybody uses Reaper?

Second remedial question: When you wrote, ”I can't get my musical collaborator to adopt it, though, because he can't bear the idea of giving up more disk space for no good reason ;) that was a joke based on your collaborator’s misconception that float32 takes more space than fixed32, right? My (admittedly limited) understanding is that float 32 is one sign bit, 8 exponent bits, then 23 value bits. Is that correct, or is that only sometimes correct?

Jim, I hear you about these 24 bit files. Definitely confuses things. So here’s remedial question 3: A 24 bit file is actually a 24 bit file, not a 32 bit file with 8 zeros at one end, right? Is audio the only place where 24 bit files get used? And is a 24 bit wave file signed, or unsigned?

I’m on Week 6 of the course, by the way. This has been a really valuable experience that may lead to more than just the harmonic plus noise separation I was after. Or maybe not, but the education is still great.

Post

Hi Mike. About my music partner, I meant that he likes using 24-bit audio tracks. I prefer 32-bit float tracks these days, but it's a minor deal. I get that he doesn't like the idea of wasting 33% more disk space, that's a lot so he has a good point, especially because he's a freelance engineer/producer and has a lot of projects going. But for me, I see disk space as cheap. Actually, the argument I have is that I catch him giving me 16-bit mixes. He's so used to CDs. I tell him, print the mix in 32-bit float (he might still insist on 24-bit). Reduce that to a smaller format only when you have to. I'm not going to be burning CDs. Even if I'm making an AAC for my iPhone, give me the full-resolution to use for the math.

Yes, you are correct that padding the 24-bit smiles to 32-bit and saving as 32-bit int wav files is fine.

As far as signed, not bothering to check but I believe 8-bit is the only unsigned format. 16-bit and larger integers are always assumed signed (two's complement).
My audio DSP blog: earlevel.com

Post

earlevel wrote:
JCJR wrote:Not rocket science, but I just find the 24 bit sample format annoying.
True enough, Jim, though if the code is endian-neutral, there's not much difference (but not so much need to write big-endian friendly code these days).

I prefer float32 as well, insensitive to scaling and clipping. I can't get my musical collaborator to adopt it, though, because he can't bear the idea of giving up more disk space for no good reason :wink:
Yep, though disk storage is so cheap nowadays. :)

Speed of 24 bit conversion probably wouldn't ever matter for Mike's purposes. Maybe it doesn't even matter for multi-track sequencing purposes, but years ago for sequencing purposes I wrote a flock of optimized asm routines to convert arbitrary size blocks of audio between all the common sample formats. I was "aesthetically offended" at how nasty the 24 bit variants were. Lots slower than other format conversions, though it only matters, if at all, when doing lots of simultaneous realtime tracks.
Mike Greene wrote: Here’s a really remedial question, though. (Actually, I have a few remedial questions :D , but here’s the first): How do I batch convert 24 bit files to 32 bit files? Usually I do sample or bit rate conversions in ProTools, but I don’t think there’s a 32 bit option. Is this one of those times where everybody uses Reaper?.
Maybe there are some programs which make batch conversion real easy.

You could look for a Macro program. These beasts come and go, and I dunno what are the better ones nowadays. Haven't used a macro program lately. You can tell the macro program to "record" a sequence of key taps and such. So you might record the sequence of commands you use to open, convert, and save-as in protools, and then invoke that macro on each file you want to convert. Reducing the number of user-actions down to 1 action per file. Or perhaps in some cases, select entire folders of files and invoke the macro on all of them with one click. Depending on the features available in the macro program.

For work (from which I mostly retired a couple of years ago), we made some command-line faceless converters for some format combinations, and used some open-source free command line programs for other format combinations (various compressed formats). Then I wrote a little program that opens a file dialog allowing the user to select a folder, and then the program would iterate thru all the files in the folder and its sub-folders, calling the command-line converter on each audio file in the directory tree.

A fella knowledgable with Terminal command-line scripts could probably make an automated script that would do the same thing-- Iterate thru the directory, calling a command-line converter on each file. I never learned that much about scripting, so it would be a science project for me. Easier to write a shell program, which I already knew how to do.
Mike Greene wrote: Jim, I hear you about these 24 bit files. Definitely confuses things. So here’s remedial question 3: A 24 bit file is actually a 24 bit file, not a 32 bit file with 8 zeros at one end, right? Is audio the only place where 24 bit files get used? And is a 24 bit wave file signed, or unsigned?
Wave file, or aiff/aifc files, can store lots of different sample formats. The raw 24 bit format are streams of signed samples, with each sample taking up 3 bytes, or an interleaved stereo stream taking 6 bytes per sample frame.

Common CPU's like to deal with quantites sized 1, 2, 4, 8 bytes long. Operations on other sized containers, you have to coddle the CPU to do the right thing with them. However, earlier generations of Protools and many hardware gadgets were based on Motorola DSP chips that are designed to work fabulous with 24 bit or 48 bit wide data, so packed 24 bit is great for that kind of hardware. Nigel knows lots about the Motorola DPS's. I never programmed them much.

Wave files have property settings where you can identify the number of bits separate from the size of each sample. For instance, you could specify 32 bit sample container size, that only uses 24 bits, or 13 bits, or whatever, out of each container, to hold the audio information.

If converting 13 bit samples out of an old Ensoniq EPS into a 16 bit or 32 bit signed int wave file, the 13 useful bits would be shifted to the most significant (biggest) end of the 16 bit or 32 bit integer, and leave the rest of the lower-order bits zero.

So after the EPS sample has been turned into 16 bit or 32 bit int WAV file, programs can load it, and it will be "as loud" as real 16 bit or 32 bit files, except of course a little grainier sounding, because of the reduced bit depth.

Post

Mike Greene wrote:How do I batch convert 24 bit files to 32 bit files?
Just remembered about this question, and I see that Jim replied as well...

I didn't have anything in mind when I suggested it—I know of Barba Batch, but that's not cheap; I had hoped it would be a matter of loading them into iTunes, setting up the export format, selecting the list, and telling it to convert—but iTunes only exports 8 or 16 bit(!).

But, barring having a handy Mac application that could do it via automator, my first choice would be as Jim said, a command line tool. And it looks like SoX (Sound Exchange) will do it easily—just specific the input file, and output file and formatting. I've never used SoX, but it looks like a handy tool, and is multi-platform.
My audio DSP blog: earlevel.com

Post

earlevel wrote: I see disk space as cheap.
Depends on what work you do, if you go over a certain amount, you'll need a server - which can get expensive. My friend is a post-production engineer, does mostly 5.1 surround @ 24bit/48kHz and runs 165x terabytes split over 2 servers last I checked. Adding 33% to that would not be cheap!

Post

Ichad.c wrote:
earlevel wrote: I see disk space as cheap.
Depends on what work you do, if you go over a certain amount, you'll need a server - which can get expensive. My friend is a post-production engineer, does mostly 5.1 surround @ 24bit/48kHz and runs 165x terabytes split over 2 servers last I checked. Adding 33% to that would not be cheap!
True, but what I actually said was, "But for me, I see disk space as cheap." I acknowledged that my friend was in a different position, working many more projects.

Actually, these days I work for a product that offers capacity up to 50 PB of high performance disk storage as a single flat file system. No, not cheap :wink:
My audio DSP blog: earlevel.com

Post

Mike, it looks like sox is a good way to go.

Unix tips:

"./" will execute as a command without the command being in a command path, so it will save you some possible confusion. If you place the sox command in the same file as the ones you're converting, and "cd" there (otherwise, just more fully specify the paths of sox and the input and output files):

./sox myInput.wav --bits 32 --encoding floating-point myOutput.wav

PS—Do you know the trick of dragging a file or folder to the terminal window on Mac? It gives you a POSIX (unix-style) path that you can further edit, even escapes out spaces for you.
My audio DSP blog: earlevel.com

Post

I'll give SoX a go. Thanks for the UNIX tip, too, because this is not familiar territory, so that command line example is very helpful.

I did stumble onto the "dragging a file onto Terminal" trick. Handy, although I still screw stuff up.

Starting Week 8 tonight . . .

Post

Afaik Molecularbytes Membrane can do this.

Post Reply

Return to “DSP and Plugin Development”