I Downloaded version 2.1 the other day and just now attempted to slow down a WAV track by 12% via Sliding Time Scale/Pitch Shift. I had done this type of thing several times in version 2.0, but two times in a row, I got an error message just before the process completed and the message was that audacity had encountered a problem and had to close.
So I uninstlalled 2.1 and reinstalled 2.0 and tried the same thing. It finished with no problems.
So obviously there is a “bug” in 2.1 in regard to Sliding Time Scale/Pitch Shift.
Nothing was checked in audio cache (I made sure of that as soon as I installed 2.1). My system is Windows XP Pro SP3 32 bit. The track was a little over 11 minutes.
Again, the process worked fine when I reinstalled version 2.0. In fact, I “slowed down” two additional tracks afterwards and both processes completed just as well.
I have to assume the problem is with 2.1. I will stick with 2.0 until I am advised on how to get this to work error-free in 2.1.
We are unable to reproduce the problem.
Was the track mono or stereo?
What was the sample rate and sample format?
Where did the track come from? Was it a recording or an imported file? (I presume that it was an imported WAV file?)
If the file was imported (as I guess it was), did you use the “copy in” option or “read directly”?
Exactly what settings did you use in Sliding Time Scale/Pitch Shift?
What were you doing before the crash?
Was your computer low on memory at the time of the crash?
Were other programs running at the time of the crash?
Is there any other information that you could give that may help us to reproduce the crash?
Are You able to reproduce the crash in Audacity 2.0.1?
Thanks for your reply. Sorry but I might have confused you by not correctly stating the release number. The problem is in 2.0.1. Reverting to 2.0.0 enabled me to carry out the speed reductions I wanted successfully.
To answer your questions:
Was the track mono or stereo?
Stereo.
What was the sample rate and sample format?
Linear PCM 16 bit.
Where did the track come from? Was it a recording or an imported file? (I presume that it was an imported WAV file?)
The track was WAV ripped from a CD like many other tracks I have imported into Audacity.
If the file was imported (as I guess it was), did you use the “copy in” option or “read directly”?
Read directly as I always do.
Exactly what settings did you use in Sliding Time Scale/Pitch Shift?
Start and End speed reductions were both set to -12.0%. Nothing else was done.
What were you doing before the crash?
Nothing, just waiting patiently for it to complete. The crash occurred at the very end.
Was your computer low on memory at the time of the crash?
No. My computer has 3gb memory and nothing else was running.
Were other programs running at the time of the crash?
No.
Is there any other information that you could give that may help us to reproduce the crash?
I wish I could but this is a routine I have been doing successfully in 2.0.0 without any problems.
Are You able to reproduce the crash in Audacity 2.0.1?
The crash happened every time in Auduactiy 2.0.1. This is the most recent release which I downloaded the other day.
I had no problems with this afterwards when I re-installed the prior version 2.0.0.
I’ve still not reproduced the crash, but one thought has occurred to me. When “Read Directly” is selected, there are a few moments while diagonal shading is displayed before the proper waveform. Do you wait for the the full (proper) waveform to be displayed or do you start processing while there is still diagonal shading showing? (either should work).
I always wait until the entire waveform is showing. In fact, I always listen to a bit of the track before doing any processing.
Sorry that you cannot reproduce the crash. Again, since it only happened to me in the release 2.0.1, I must assume that it is due to something new or fixed in this release.
It seems unlikely but could it be something peculiar to just that one WAV (a bad rip perhaps)? Would it be possible to upload the WAV to a hosting service so that others can try and reproduce the problem?
Maybe you did not read my previous replies thoroughly. I was able to use the 2.0.0 sliding time scale/pitch shift on this exact same WAV file successfully. So it could not be a bad rip. Something in 2.0.1 is probably causing this, I’m afraid. I only wish someone here could replicate the problem.
I’ve been testing thoroughly with the same version of Audacity 2.0.1 on the same OS (Windows XP Pro SP3 32 bit).
We can’t completely rule out something peculiar about that WAV file. It’s possible that there’s something peculiar about it that Audacity 2.0.0 is tolerant of but 2.0.1 isn’t. Would you be able to upload that file somewhere so that we can try it? Sendspace.com allows free uploads up to 300 MB. If you ZIP the file it will be well under that limit.
Ah ha - you have Quality set to 16 bit. I’ve not tried that (I always work in 32-bit float as that is “native” to Audacity and avoids unnecessary conversions).
I’ll try 16 bit and see if that makes any difference.
I have had the quality set to 16 bit for a long time. I always work with WAV or FLAC. All my edited tracks in Audacity are eventually burned to CD-R. I wanted the quality to match that of PCM.
When I first started using Audacity, I kept the default of 32 bit float. But I was getting some additional noise in my output which was not present in the source files. So I then found out about the quality settings and changed to 16 bit. Everything had been fine since then. If I am mistaken in regard to 32 bit float vs. 16 bit, please enlighten me.
Note that all my source files are either WAV ripped from CD or MP3 downloads which I convert to WAV or FLAC. I do not do any of my own recording.
EDIT: I changed the quality to 32 bit float and did the same -12% speed reduction on that track. It did not error out. Maybe that explains things for 2.0.1 but how come I never got any erroring out in prior versions using 16 bit? I need to be fully enlightened on using 32 bit float and how that would affect the sound quality on resulting WAVS or FLACS burned to CD-R.
I’ve repeated your steps as closely as possible on Windows XP SP3 about 20 times with your original file and about 20 times with other files in Audacity 2.0.1 and about the same in Audacity 2.0.0. This took a long time as my XP machine is very old and slow (processing time about 15 minutes for that file).
I’ve repeated the steps about the same number of times on my (main) Linux machine about the same number of times.
I’ve also tested (countless times) generated test signals on the Linux machine with both the 2.0.0 and 2.0.1 versions with a full range of alternative settings.
The most noticeable differences are:
2.0.1 is a little slower than 2.0.0 when “Dynamic Transient Sharpening” is disabled, and a lot faster than when “Dynamic Transient Sharpening” is enabled.
2.0.0 with transient sharpening enabled gives slightly better sound quality with “Dynamic Transient Sharpening” enabled compared to “Dynamic Transient Sharpening” disabled.
2.0.1 does not have a “Dynamic Transient Sharpening” control.
The sound quality of 2.0.1 is significantly (audibly and measurably) better that 2.0.0, with or without “Dynamic Transient Sharpening”.
If part of a track is selected rather than the entire track, 2.0.0 produces a very noticeable glitch at the start that is like a 0.03 second “fade in”. 2.0.1 produces a seamless transition between the unprocessed audio before the selection and the processed audio. There is very minor (and unavoidable) glitch at the end of the selection with both versions.
I have had 1 failure (crash) which was with the file that you provided, on XP SP3 with Audacity 2.0.1
At least we know that the 16-bit aspect is probably irrelevant.
It’s a shame because the newer version gives definitely better quality. If you find any more information that you think may be relevant, please let us know, but as the only way that I’ve been able to reproduce a crash is by flogging my poor old XP machine relentlessly for hours on end I don’t think there’s a lot more that I can do other than log the case. I’ll post if I hear any more. Releases seem to be scheduled for about a 3 month cycle, so let’s hope that you find sliding time scale/pitch shift more stable in 2.0.2. Thanks for investigating this with me.