Effects > Change Speed wipes out content of track

Just wondered if anyone had a fix for this behaviour.
Audacity 3.2.4 on Windows 11. PC is i7 64GB RAM and about 500GB disk free.
I have a nearly two hour stereo track (44.1kHz - project file about 2.3GB). I need to speed it up by 4x so use Effects > Pitch and Tempo > change speed.
Put 4 in the speed multiplier box and apply. The process appears to work but then returns with what looks like an empty track.

The effect will work with shorter sections of the main track but I haven’t experimented to find the limit. I have used this effect with similar material in the past with a prior version of Audacity.

Could I be doing something wrong or is there a size/length limit with this effect?

Thanks for you help,
Rob

I’ve just tested with a 2 hour stereo track, and it worked correctly.


On which drive?
Is this a saved or unsaved project? If it is a saved project, where is it saved?

Saved on my C: drive. Same behaviour whether saved or unsaved.
If it makes any difference I can undo the effect successfully.

That’s fortunate :wink:

If, after undoing, are you able to apply the effect successfully, or does it fail again? (Be careful when testing - ensure that you have a WAV file backup of any important audio, just in case it doesn’t come back.)

Apply speedup > undo speedup > reapply speedup
Still does the same thing.

Also rebooted machine, just in case. Still no change in behaviour

Let’s check if it is project specific.

  1. Reboot your computer (don’t miss this step)
  2. Launch Audacity
  3. Add a new stereo track
  4. Generate a 2 hour “Tone” into the stereo track
  5. Apply “Change Speed” with 4 x speed.

Obviously you should end up with a 30 minute stereo tone. Is that what happens?
(You can close Audacity without saving when the test has completed)

Done and works exactly as I would expect. 30 min result file at two octaves above original pitch. So could be something in the project file?

Just a follow up - exported project to WAV (16bit), reimported and then speed up. That works without issue.

I can work this way round if necessary but if you want to look into this further let me know.

Thanks for help Steve.

Rob

Yes it could be.

Here’s a test you can try that will test for one possibility (It checks for a specific kind of corruption).
Apply this code in the “Nyquist Prompt” effect to the entire track (it will be quite slow, but should return a pass or fail result).
For stereo tracks, you should see two “Pass” results (one for each channel)

;type analyze
;debugflags trace
(defun test (sig)
  (setf count 0)
  (do ((val (snd-fetch sig)(snd-fetch sig)))
      ((not val) (/ count *sound-srate*))
    (if (/= val val)
        (return))
    (incf count))
    (if (= count len)
        (print "Pass")
        (format t "Failed at ~a seconds~%" (/ count *sound-srate*))))

(multichan-expand #'test *track*)
""

A pass result does not mean that the track is ok/perfect, but a fail result shows that there is corruption in the track, and says where the corruption starts.

The result was two passes. Oh well - I have a workaround anyway and none of the other tracks have given the same problem (so far :unamused: )

Thanks