TODO

[SamWindell]

• [x] Trim command to remove start/end
• [x] Silence removal for start/end with silence threshold param
• [x] Pitch shift
• [x] Some kind of smart file renamer - automate the common tasks that sample library devs have to do manually
• [x] Glob pattern matching for filenames
• [x] Write more tests (fader curve shapes, zcross)
• [x] Convert sample rates
• [x] Convert bit rates
• [ ] Where possible, it might be worth changing the processing to use the native format of a file. For example, process a file as a buffer of 16bit ints if that is what the input file is saved as. Currently, we are converting all input files to float buffers, and then writing them back out to whatever format. This introduces minor precision errors.
• [ ] Add support for AIFF file format
• [x] Recursion should only happen with special wildcard **
• [x] Support 'not' pattern matching. i.e. -*.wav would match anything that's not a wav
• [ ] Loop finder - perhaps add markers to wave file
• [ ] Preserve file metadata chunks - currently we are discarding metadata such as loop markers or sampler markers of a wave file
• [x] Categorise files - either into folders or by renaming them
• [x] Write proper docs
• [ ] Export binaries
• [x] Perform a safety pass and normalise to 0dB if the audio being written would clip
• [ ] Subcommand to print info about an audio file, bit depth, sample rate, etc.
• [x] Convert subcommand should have an option to specify the output encoding - flac or wav.
• [ ] Should --recursive be the default option?
• [x] With renaming subcommands, check all <> variables to see if they are valid. Do this check before processing.
• [ ] Add a delete command - deletes files matching regex
• [ ] Normaliser should have an option to normalise with common per-folder, perhaps 3 modes for normalisation: independently, folder common gain, or global common gain
• [x] Investigate highpass, should the default Q factor be 0.707?
• [x] Improve pitch detection, test: normalising data before detection, blending channels into one, and pitch detecting 0.1 second chunks.
• [ ] Add a 'dry-run' option to renamer
• [x] renamer regex-replace warn if there are not matches for the regex
• [x] Using convert file-format on its own fails if the file-format you are converting to does not support the bit-depth and sample rate of the source
• [x] Improve auto-map functionality - it can be frustrating to be able to make a regex that only matches the root note. Perhaps it should be like regex-replace but with the option to specify the group num for the root note.
• [ ] Slice an audio file at transients
• [ ] Add examples to the help text of each subcommand
• [ ] Add a tool that generates full documentation of Signet
• [x] Ensure file changes/moves are only added to the backup system if they succeeded
• [ ] Add a short version of each of the rename text substitution variables

[faxinadu]

Sounds like a great plan^ :)

also more ideas:

• convert sample rates
• convert bit rates

[SamWindell]

Good ideas, I've added them too.

[faxinadu]

I also think reading and embedding the smpl chunk, especially loop points is essential. what you could do is have reader code that checks if this chunk exists, stores the data in a variable and after the audio operating injects that chunk in the header.

[SamWindell]

Yeah, I'll move that further up the to-do list. I bet that would be a deal-breaker feature for people.

BTW I just closed this issue because I moved these things to the projects section instead. Seems like a better way to handle to-dos.

[faxinadu]

i think its a deal breaker yes, especially considering its for sample library builders... maybe have a look here for inspiration, for the reading (it works but i do not know if my code is bug free there, look at the part where the smpl chunk is read): https://github.com/faxinadu/LuaWAV

so you read everything, perform the operation, then brute force the smpl chunk back in.

[SamWindell]

Thanks. Thinking about it, the complications come from when editing the audio file by changing its length (stretching or trimming). In that situation, things like loop markers would become incorrect. So I guess really the loop data needs to be carried throughout the processing - that way each subcommand can modify the loop points along with the audio data so that by the time we come to write it, it still makes sense.

[faxinadu]

yes thats what I was doing when I was doing these things with Lua. After every process I re-write the chunk.

If a process changes the file's length. for example silence removal then that process should also re-calculate the loop points based on what changed.

[faxinadu]

i have been following your commits, awesome stuff! go on! 👍