Program Crash - Batch Editor

[Jack Wallstreet]

For years I have periodically had Batch Editor crash unexpectedly while processing. I am almost certain I found the problem and hope you can fix it in the next main release (if there is one). The batch editor apparently doesn't like long, but legal path names. If I shorten the name, the Editor will run cleanly. If it encounters a long pathname, it crashes. I don't know what the limit is.

[Craig Maier]

Interesting. We had not seen this before. What is the operating system and the HD file system type?

Craig

[Jack Wallstreet]

Windows 10, but this has been happening for several years - Window 7 definitely and, I think, Windows 8.1. Since I wrote this on 3/6, I have used the batch editor a number of additional times and have had hard crashes on long file names (combined with path). As soon as I shorten the name it works fine. Always editing .wav files.

[Craig Maier]

Is your hard drive configured using FAT32 or NTFS? I am using NTFS and have not seen this crash yet.

[rickc]

Jack
Can you give me an example of the long filename that you are using to cause the crash? Also are you using a destination directory?

[Jack Wallstreet]

The Mamas & The Papas - All The Leaves Are Brown_The Golden Era Collection (Disc 2) - Twelve Thirty (Young Girls Are Coming To the Canyon).wav in directory C:/temp.

I stored the files there to try to shorten the pathname so I could get the batch editor to work, but just the short directory name didn't work. If I shorten the file name, it works every time. The source and destination directories are the same. Does that answer your questions?

[sus4chord]

That is definitely a very long file name. It's probably not your problem, but I have occasionally run into problems with some applications when file names have an ampersand in them. Just a thought to try it by changing the name to "Mamas And The Papas", rather than "Mamas & The Papas".

[Craig Maier]

From what I can tell, both FAT32 and NTFS systems allow for up to 255 characters within a single file name. Not sure why that file name is not working unless sus4chord's idea regarding the ampersand is clashing with something in the software or the operating system. Not sure.

Craig

[Jack Wallstreet]

Ok. I have now done enough testing to, I think, answer your questions, and hopefully to allow a fix in the next version.

1. The "&" is not the issue. I removed it and the crash still occurs
2. The length of the pathname does not seem to be the issue. I changed it at the crash point (ie., the maximum file length) and it made no difference.
3. The crash appears to occur with filenames longer than 126 (if I counted correctly - which seems like something close to 1/2 of 255)
4. The crash ONLY occurs if the different directory option IS NOT selected (i.e., a digit has to be appended onto the old filename)
5. The number of files to be processed is not relevant. I used 1 file in my testing (but have used more in the past). Crash occurs with one file or more, whenever a long file is processed.
6. The crash appears to occur after the file is processed (pkf file is produced and processing has occurred) - I am guessing it occurs when the new file with the extra digit is being written.
7. On my system, it is reproducible, with no exceptions.

[Craig Maier]

If you turn off peak files (Edit/preferences/display) does it still happen?

[rickc]

Got it!!!
It was the length of the file name that was the problem, Not the overall path. I have looked at this code a dozen times and never noticed the short buffer length. I even have a check to see if the filename is too long.
Oh well, It seems to be fixed now. This will be the upcoming bug fix release of DCForensics10. I am not sure when I will get it back into DC8 as we are working on the update to that program as well.

Thanks so much for your persistence Jack.

[Jack Wallstreet]

Thank you for taking the time to look into it!

[Gord Staples]

I was having a similar problem using DC8 when using manual interpolation edit. I'm trying to remove all the major scratches manually on a record by zooming into the waveform, isolating the impulses one by one and using the Ctrl-I control to remove the spikes. The Expert Impulse Noise or Big Click Filter didn't work well enough. They overlooked too many spikes or didn't clean them very well. In each session this was working well but after a number of manual fixes, the program would crash with a "not responding' error and all fixes up to that point would be lost. I could never tell how many fixes it would take before the program would crash but it always did. I wondered if the long file name or directory structure similar to the problem Jack Wallstreet was having might be the reason. The file name was down several sub-directories and the file name was rather long (still under the limit for Windows 8.1). I then moved the file up to the first sub-directory of the root drive and renamed the file to only a few characters. The seemed to work as the program didn't crash after this change. So I'm wondering if there is an issue 'bug' with DC8 program with long file names or if the directory structure is to long.
Thanks
Gord

[Craig Maier]

We know of nothing indemic along those lines. I would recommend updating to DC8.5 (free update). Also, it might not hurt to check the box on the soundcard preferences called re-initialize on play and also increase the number of buffers by 2 or 3. See if any of those things helps. BTW - we recommend the use of the EZ Impulse filter run with light settings and run twice or three times via cascading in the multifilters. That way, it appears to the user as one filter when it is actually running those three times. Since the EZ Impulse filters are non-linear processes, they work better when cascaded insead of just one shot through. Also, you will gain benefit by transferring your recordings at 96 kHz before running impulse filters. After the impulse filter part of the restoration is complete, you can down convert to 44.1 kHz.

Craig