Audacity Forum

Clayton, I posted the file here:
http://gaclrecords.org.uk/bugs/part_1.zip

though mdubin has said that other files may crash, especially with 16-bit quality.


Gale

Gale Andrews wrote:Clayton, I posted the file here:
http://gaclrecords.org.uk/bugs/part_1.zip

though mdubin has said that other files may crash, especially with 16-bit quality.


Gale

Yes, another smaller WAV file crashed and the quality was set at 32 bit float!

mdubin

otey wrote:Hi,

I am the author of the code, and just heard about this.
I made substantial changes to the effect code in 2.0.1, but never got a crash.
The link to the audio file which crashed it doesn't work anymore.
Can someone repost the file, please?
Hopefully I can fix this quick and we can get it in 2.0.2.

-Clayton

I re-upload the audio file in which I have gotten several crashes at the very end of the process. But note that there were a few times where I did not get a crash, with this file and with some others. And I did get a crash with a smaller WAV file, even with the quality set to 32 bit float.

Here is the link:

http://www.sendspace.com/file/w2ylvu

mdubin

Can't reproduce on my mac with the test case.
I'll run on my only windows machine, 64 bit vista, 32 bit executable on loop for a day on a debugger, and if that doesn't illuminate anything, I'll try to create an executable for mdubin that can give me a stacktrace on his crash.

otey:

I am running windows xp pro 32 bit sp3.

mdubin

EDIT: I had some free time today so I reinstalled 2.0.1 and tried the same -12% processing as before using 32 bit float. Only this time, I created the input WAV files with a different editor and the resulting file names did not have any spaces in them. None of the three WAV files I processed just now errored out. I am not jumping for joy yet but am wondering whether the file name prefix having a space in it could have had an effect (Part 1.Wav before vs. Joined-01.Wav now).

I can't see the file name has any effect.

There is a negligible chance the application ripping the CD is relevant. Which application ripped the CD before and which one now?


Gale

Gale Andrews wrote:There is a negligible chance the application ripping the CD is relevant. Which application ripped the CD before and which one now?

@Gale,
Perhaps not so negligible. Your post has prompted me to recall that I have problems if, on my Win 7 system, I use Windows Media Player to rip tracks from CD. These tracks play OK in WMP. They burn OK to CDs. But if I take one into my AV software it sometimes shows up as having zero duration and does not play. Any such WAV that I want to use in an AV sequence has to be opened in Audacity and Exported to 16bit PCM WAV. Then it works OK in the AV software. (AV = Audio-Visual not Anti-Virus!)

Sorry I was not clear. I always rip CDs using the same software which I have been using for years.

The process I use to create the input files for the Audacity Sliding Time Scale is a bit cumbersome and would require a lengthy explanation. Needless to say, this arose out of the fact that if I applied the sliding time scale to the original ripped tracks as is, an audible annoying "click" would many times be present at the very end of the processed file after export. So I perform a roundabout proceedure of combining the tracks and then splitting them again differently so in the end I would avoid the clicks. It was this roundabout proceedure (after ripping) which I did a bit differently yesterday and the file names themselves were generated automatically and did not have any spaces in them. For example, instead of "Part 1.Wav" which I named myself, the splitting program generated a file named "Joined-01.Wav".

The bottom line is that the only real difference between the two files (the only I uploaded for you and the one I created yesterday) is that there is no space character in the file name.

mdubin

mdubin wrote:Needless to say, this arose out of the fact that if I applied the sliding time scale to the original ripped tracks as is, an audible annoying "click" would many times be present at the very end of the processed file after export. So I perform a roundabout proceedure of combining the tracks and then splitting them again differently so in the end I would avoid the clicks.

We probably need to know more about this.
There is obviously something a bit strange going on in the fact that you can easily reproduce the problem with sliding time scale/pitch shift and no-one else can reproduce the problem (though I did appear to reproduce the problem once after thrashing an under powered 10 year old computer all day).

Steve, PGA, and all the other excellent people here:

I did another 4 sliding time scale processes WITHOUT ANY CRASHES. Again, the quality is set at 32 bit float since, according to the experts here, it makes absolutely no sense to use 16 bit if any processsing is being performed.

That makes 7 straight successful sliding time scale processes. Maybe it is the fact that there are no space characters in the file names.

So as far as I am concerned, I will not worry any more about this crashing. If it does happen again, I will simply reboot my machine and retry.

Thanks everyone for all your assistance.

mdubin

EDIT: I did an 8th straight successful sliding time scale process but on the 9th it crashed at the end like before.