Windows CLI zero sized buffer always

I thought that, but I get the same results across any file I use.

Can you send me your file so we can rule out any me problems?

Having to hotspot my phone at the moment, so not very data rich. What happens if you try with something we both have, like one of the flucoma media files (or jongly)?

mfcc -source C:\code\flucoma-max\media\Tremblay-AaS-AcousticStrums-M.wav -features mfcc.wav

works for me

the best track ever :wink:

Seriously, this is amazing to find all discrepancies between platforms and users and will help us tremendously to make a clear ‘read me’ with eventual hints and limitations. Thanks @jamesbradbury

Just tried some of the cli tools including mfcc on windows server 2012, and they work ok here as far as I can tell… I only see the zero size message if the source file isn’t readable (namely has deny read permissions to the executing user or the path doesn’t exist)

2 Likes

Okay so Nicol-loopE-M.wav works when I cd into a directory with the .exe (and the file is in there too) and referring to full paths. Hurray! For some reason my Max generated .wav file does not work in the same way. I assume that this is a me problem, but perhaps you would like to try with this file to determine if its the reader or how I have saved the file.

The next problem is that given the paths work on the command line python throws the error that the input buffer is zero. I assume as @richardK pointed out, the interpreter might not have read permissions on the files and so I’ll do some further digging on how to bypass this.

In summary:

I think this was a me problem, testing on files that didn’t work but there is still a bit to figure out in order to use the CLI windows tools embedded or called from another environment.

GitHub - Sycnex/Windows10Debloater: Script to remove Windows 10 bloatware. I use this and it has stopped all windows behaviour in its tracks. Give it a shot if you value your sanity and time