Upon opening an existing audacity file, version 3.5.1 instantaneously changes The position of the mix tracks and changes the pitch and speed of the tracks. It then instantaneously saves the file over the existing file burning-in the destruction of the original file. This should never have been released. This bug is destructive and infuriating in that this version was not properly tested prior to release. Is there a fix for this? I can not trust audacity any longer to open my files and do any work on them because of this issue. This is an emergency fix that must be properly tested and put in production ASAP!
Are you using the audio.com cloud Project sharing? There have been other instances of cloud storage changes rippling through show files.
Are you doing all the work on the local machine internal drives—other than the audio.com tools?
Yes, but it has to be broken to issue a fix.
Describe the show. You suggest many music mixes and complex track management. How long is the show? Are you mixing 44100 and 48000 (video) sampled music files?
Were you fine until, for example, you did the last few edits and tried to save the Project? What were those edits?
Koz
Hi Koz,
I was not using the audio.com cloud project sharing oraudio.com tools. This is a local installation on a 64-bit Windows 11 laptop. Nothing in my environment has changed since I started using audacity about a year ago. The only thing that has changed is the version to 351. The show is a simple song just over 4 minutes long. I had multiple versions as I made edits. Each time I opened a version, the problem automatically revised that version with pitch and speed changes and moved the mixed tracks. I would immediately close audacity and reopen the file and the new file had the exact same issues. Whether this is an issue that is occurring upon opening of all the attempts and the original file is unchanged, I do not know. If I had a way to go back a version to see if it opened properly in a prior version, I would do that to test the scenario. Is there a way to do that? Thank you for replying.
Ps, The file is 44100 sampling and has always been. There are no mixes with different sampling rates. And yes, everything was perfectly fine until I simply opened one somemy files from February. And whamo.
Very much appreciated !
Yes,
I’m using 3.4.2 rather than 3.5.1.
You can get the installer from here.
If you do install one, Tools > Reset Configuration to keep poisoned preferences and settings from carrying forward.
The last stable version before that was 2.4.2. That version used the Split File Format. An AUP file and a _DATA folder with the music in it. 2.4.2 will only open the older format Projects. 3.4.2 and 3.5.1 are expected to open anything.
Post what you did and how it went.
Koz
One note. Once a show is cursed, the problem is permanent. There is no opening a show in an earlier Audacity and have all the problems go away.
You open an older Audacity and start building the show again.
Koz
I’ll give your tips a try. Unfortunately this does not solve the root cause of the problem. Audacity 3.5.1 appears to be the root cause of this problem. It should never have been released. Proper QA testing would have discovered this issue and it would have been corrected prior to release if that were the case. So my original message stands. A patch needs to be developed and tested ASAP.
Looks like it may be this issue that @steve logged yesterday:
Peter
I guess this is a known issue at this point. The sample rate of the files you are working with need to match the project sample rate in audacity preferences. Otherwise when you close an already saved project, the tracks will want to change to the project sample rate next time you open.
Here’s my remedy until a fix comes:
If the tracks are now faster and pitched up a bit.
Click the dropdown of the track with the altered audio.
In that menu select Rate
Select 44100khz
Your track should now sound normal. All you have to do is align the track again.
This works for me for now, so I think it might work for you
Update: Look like they found a fix, mere minutes ago, and will be released with 3.6.0 according to dozzzzer on github
Yes it;s known @steve logged this yesterday:
And it looks like it’s been fixed for the upcoming 3.6.0 release, as it’s been marked as “Closed”
Peter
This topic was automatically closed after 30 days. New replies are no longer allowed.