-
Notifications
You must be signed in to change notification settings - Fork 12
/
note.txt
23 lines (13 loc) · 2.15 KB
/
note.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
So, the idea I've just had is to make a program that takes a single .wav or .aif file as input, and automatically splits it up into several .wav or .aif files as output. Once the waveform's volume goes above a certain (command line specifyable) threshold in either polarity, a new output waveform is started and written to, and once it stays under that threshold for a certain (also command line specifyable) duration, that new output waveform is closed. So you can give it a waveform that's a bunch of single hit samples, and it will automatically split them out into one waveform file per hit. That way, I won't have to do it by hand in Cool Edit, and it doesn't have any of the BPM second guessing in ReCycle, which doesn't apply to a bunch of unrelated single hit samples.
It would also be a simple enough program to learn a bit more Python with.
Example usage:
wavesplit input.wav -threshold 64 -duration 128
Output would be:
input01.wav
input02.wav
input03.wav
...and so on. The threshold is a number between 1 and 32767 (for 16-bit files, which is all it needs to work with), and the duration is any positive integer, for the number of samples to wait. At least to begin with, it's fine if it only works with exactly CD quality files (16-bit, 44.1kHz) and if it only works with .wav files, not .aif. Sensible defaults should be preset, so you can simply type "wavesplit input.wav" and it'll automate absolutely everything.
Possible idea: it could automatically look at, say, the second second (as it were) of the recording, find the maximum volume of the waveform, multiply it by, say, 1.25, and use that as the threshold.
It should really work with stereo files, or for that matter files with arbitrary channels. This shouldn't be difficult to implement.
Another good feature would be an optional boolean command line argument to tell it to politely wait until the next zero value before closing each output wave file.
Note that this currently only works with 16-bit wave files. Changing "<h" to other values may allow 8 or 24-bit ones, but I'm not sure how to implement this yet. For now, I should at least make it exit politely when confronted with a non-16-bit wave file.