- They should work with 8-bit and 24-bit .wav files too, not just 16-bit
- Optimise .wav writing so the waveform's stored in memory first, then all written out in one go. Yes, this isn't very Pythonic, and will make it more difficult to port to C, but it will speed the programs up a lot, and it will allow the next feature, original file overwriting.
- Have a command line argument to overwrite the original files, eg --overwrite or --replace
- Allow command line specification of arbitrary --sample-frequency and --bit-resolution, plus preset options like --tracker that do what it currently does (8-bit, 8363Hz). Then rename the program to something more generic.
- Perhaps this should be split up into two different programs: one to change the bit depth, and another to change the sample frequency?
- At any rate, it should be able to increase the sample frequency and bit resolution just as easily as decrease them. (Instead of skipping things, it should merely repeat them.)
Alternatively, "truncate-left" and "truncate-right". One or two programs, which independently allow trimming off the beginning of the sample to the first upwards (negative to positive) zero-crossing, and the end of the sample back to the last upwards zero-crossing. As it would perform the cut just *inside* the zero-crossing, it could be run multiple times to keep trimming one more cycle off the waveform.
They're intended to only be used on samples which are already cropped to miss off their beginning and end, hence they needn't concern themselves with thresholds.
These would help people to make samples which seamlessly loop.
- Make this, to convert .wav files to .syx files containing MIDI sample dump standard format data
- Make this
For each specified file (presumably split out with Wavesplit, but not necessarily), attempt to determine its pitch (using the method I worked out and implemented earlier in other software), and if it has one TTET-rounded-off pitch that's more common than others within the sample, rename the file to append either the note name (foo.wav
(foo.wav => foo-24.wav, foo.wav => foo-30.wav).
A nice option would be to specify the root filename, as obviously all the existing files won't be able to have the same filename, and/or to extend Wavesplit to incorporate Renametopitch's functionality.
A possibly useful, albeit odd, program would be one that read in an unlimited number of .wav files and created a .png, maybe 16 bytes wide, of an unlimited height, which had a pixel for each .wav file, representing its loudest peak. This would make it easy to spot at a glance whether any files (albeit not which ones) were silent, and whether the files are normalised or not.
A possibly more sensible approach would be a program that you give a number to, and a list of files, and it lists the files which don't reach that number with their volume peaks.