Temp/output folders that aren't writeable cause crash when SoX tries to write a file

[ghost]

Describe the bug

Hello, I received a FATAL unhandled exception when I ran the Towsey.Acoustic.yml config file when calculating acoustic indices on a 30 mins recording. I tested the QUT tutorial prior to using my own data and the tutorial worked with the data provided.

Expected behavior

I expect to get output files with indices analysis for my .wav file.

Diagnostics

Instructions

✅ I have followed the instructions for reporting a bug

I have attached a log:

log_20200609T152953Z.txt

The operating system I'm using is:

Windows 10 Home Version 1903

The version of AnalysisPrograms.exe I'm using is:

20.5.0.170

The data used can be found:

Data file: Acoustic recording
Name: 20200309_120000_Gabon_Non_Stop
Size: 150 MB
Duration: 29:54 (minutes:seconds)
Count: 1 file
Format: WAV File

The command I used:

C:\AP\AnalysisPrograms.exe audio2csv 20200309_120000_Gabon_Non_Stop.wav  C:\AP\ConfigFiles\Towsey.Acoustic.yml .\IndicesOutput

The config file I used:

log_20200609T152953Z.txt

Screenshots

Additional Details

[atruskie]

Thank you for the report @tsatchivi! We appreciate it 😄

I don't have enough information to diagnose this problem. Is there any chance you could provide me with the audio file that is causing the error?

If the data is sensitive you can email the file to me and we'll ensure it is not shared.

[ghost]

Hello @atruskie,

Thank you for getting back to me! Absolutely, I can provide you with the file. The data is not sensitive. I'm not able to attach it here because it's too large but I can email it to you or place it in Google Drive where you can access it. I'm actually working on this data with the Sound Forest Lab where the principal investigator is Zuzana Burivalova. She told me about the QUT tool that your team built. The file is soundscapes data recorded in a tropical forest in Gabon.

Here the link to the data in Google Drive: https://drive.google.com/open?id=12HLK1_IZSwJYx93MuoM923v9dI-fRUnq

[atruskie]

Ok, great, thanks for the Google drive link, I'll check it out tomorrow (it's midnight here)

[ghost]

Yes, the time gap! Thanks!

[atruskie]

Hmm, I can't seem to reproduce this on my machine. I tried with our very latest version (not yet released) as well as the version you used.

Can you please try running the command again and then ensure you suffix it with --log-level 7 to add more debug information to the log. Then attach the log into the a response here in the issue.

C:\AP\AnalysisPrograms.exe audio2csv 20200309_120000_Gabon_Non_Stop.wav  C:\AP\ConfigFiles\Towsey.Acoustic.yml .\IndicesOutput --log-level 7

If that doesn't work we may have to set up a call.

Lastly, what locale is your computer using? https://docs.microsoft.com/en-us/powershell/module/international/get-winsystemlocale?view=win10-ps

Thanks!

[ghost]

@atruskie, I think I may have found out what's going on. I just created a folder directly under the C: drive on my computer and placed the file in there. I placed the file at the path C:\Temp instead of C:\Users\Alma\Documents#SoundForestLabWork. When I ran AP.exe on the exact same file located at C:\Temp, it worked without any issue. I don't understand why this is happening but it seems that when I place the file in a subfolder it doesn't work. I hope my explanation makes sense.

Thank you so so much for taking the time to debug this issue! I really appreciate it. This is a fantastic application!

[atruskie]

OK, I'm going to assume the issue here is due to the # symbol in the directory name?

I'd still like to fix this bug - there's no reason it should have failed. Could you please attach the verbose log?

[ghost]

Hi @atruskie, I also assumed that the issue was the # symbol yesterday but it doesn't appear to be so. When I placed the file at the path C:\Users\Alma\Documents\Testing, I still ran into the error yesterday. I've rerun the command this morning with the file located at C:\Users\Alma\Documents\Testing and the error still persists. Below is the log file (I ran the command with the suffix --log-level 7 as you've asked):

log_20200611T132909Z.txt

Also, to answer your question about the locale on my computer, it is en-US.

Thank you.

[atruskie]

This is super interesting. The error from the log is:

C:\AP\audio-utils\win-x64\sox\sox.exe FAIL formats: can't open output file `C:\Users\Alma\Documents\Testing\IndicesOutput\Towsey.Acoustic\mtjk3nmndlsvd0z0ejhbnkrg0xsm1wfo.wav': Permission denied

So it can't write temporary files to your documents folder... Is there something special about that folder?

• is that folder a Google drive or one drive folder?
• is that folder a network folder?
• are you using a personal computer, or one provided by your organisation?
• have you got windows ransom ware protection enabled? https://www.lifehacker.com.au/2019/08/why-you-should-use-windows-defenders-ransomware-prevention/

Regardless, I should be able to mock up a similar situation now and write some code to deal with it. Thanks!

[ghost]

hmm, interesting.

• The Documents folder is on my C: drive, it's a physical drive; not a Google drive one drive folder
• I'm using my personal computer.
• I have Bitdefender installed so that's the software that handles ransomware protection. I just checked it and it turns out that Bitdefender was blocking sox.exe and AP.exe from making the change to the folder!! I hadn't noticed until you pointed this out. The error is gone now! I can run AP.exe on the file located in my Documents folder.

I'm glad the issue is solved! Thank you so much for troubleshooting @atruskie!

[atruskie]

Oh, great, fantastic news.

I think the fix here will be adding some documentation and a warning that has a nice clear message if the folders aren't writeable for some reason.

[ghost]

Yes, it seems like a good idea to have a reminder in the documentation for the user to check their ransomware protection software - although I should have thought about that knowing Bitdefender!