It didn’t. It created a 1.5GB AUP3 file. While we’re still in the transition period, it’s good to have accurate descriptions.
The aup3 file has to be able to recreate your entire editing environment, all the original tracks, the management, and positions. The legacy aup system didn’t save UNDO. I don’t know how the aup3 does it, but if it does, you have multiple copies of your whole show.
If you have a large, complex show, you could run out of memory and start real-time shoveling data off to the drive. That is expected to slow you down significantly, but still work OK if there’s room enough on your internal drive. That’s the forum complaint that suddenly, each effect, filter, or correction takes a minute or more. You just outran your machine.
Cloud drives are a whole different world. They’re made to appear snappy, convenient, and native to your machine, but they’re not. They could be anywhere on earth and have all the problems that internet connections do. Error Correction, Resend, Path Management, and Collision Detection. A friend of mine recently gave up and got a new internet connection because his old one would stutter and drop frames while watching a movie, Youtube show, or Zoom call. Most of his neighborhood worked like that. That would be deadly if it did that in the middle of a complicated Audacity edit.
While the project is open, each time you process the audio, the processed audio is put into the track(s) and the old, unprocessed audio is retained in case you want to “undo” the processing.
Example:
1 track, 250 MB audio - approx project size: 250 MB (a little bit more in reality)
Process: Normalize to 0 dB.
250 MB of (new) processed audio created.
250 MB of Undo data.
AUP3 size: approx 500 MB
Process: Noise Reduction
250 MB of (new) processed audio created.
500 MB of Undo data.
AUP3 size: approx 750 MB
Process: Equalization
250 MB of (new) processed audio created.
7500 MB of Undo data.
AUP3 size: approx 1 GB
…
When the project is closed correctly, the “Undo” data is deleted.
When a lot of Undo data is deleted, this will leave a lot of empty space in the AUP3 file, which is still occupying disk space, so Audacity will then “Compact” the project. Compacting the project removes the empty spaces so that the project is not wasting disk space. In the above example, the project will be just a bit more than 250 MB after compaction.
Some disk formats (notably “FAT” formatted drives) don’t support SQLite Compaction. In this case, Audacity is unable to remove the empty space from the AUP3, so it remains huge, and gets bigger every time you work on it. It appears that this problem can also occur with cloud drives (such as Google Drive), though I don’t know the precise mechanisms that cause the problem in this case.
Obviously, if Audacity crashes or is forced to close (for example, if the computer is powered off), Audacity will not have chance to compact the project before quitting. It is important to allow Audacity to complete the Compaction step before quitting.
While I do find on Windows 10, that the aup3 file does shrink after closing, I’m still finding the files inexplicably large. This one in particular (which represented about 250mb audio) became 1.8GB when open and only compacted to 1.5GB. This is despite the Google Drive app being paused for the entire opening, editing and closing process. It seems as if something funny is going on there.
I’m tempted to go back to an older Audacity for my next podcast.
I’m on Linux, and I’m still using Audacity 2.4.2 for production work due to its excellent stability and reliability. Of course it’s necessary to ensure that the AUP file and _data folder remain together (which is a non-issue for the self contained AUP3 format), but I’m used to that, so not a problem.
I have to agree with Steve, 2.4.2 is probably the best, most stable version of Audacity.
For me, the move to the AUP3 project format is not ideal.
The concept of having everything in a database file may be good in theory but in practice, it brings quite a few negatives
with it.
Mainly, the addition of another “layer” of software that must terminate properly else the project is lost.
The extra limitations imposed by drive types/formats not supported by the database format, is yet another hinderance.
I have been using the old AUP format for years and have yet to experience a “lost” project.
Some of these are pretty large, 12 stereo audio tracks, several label tracks and up to 90 minutes long.
I for one, cannot see the big deal in having a aup project file plus an associated folder.
Transferring or moving a project, simply requires one to have the project file and folder together.
BTW, same as when saving a wepgage locally, you land up with the html file plus a folder that contains all the other
assets and required files (if any) for that saved page.
Nobody complains about that.
Hmm, not sure that is true. In Audacity 2.x it is just as important that Audacity terminates correctly, otherwise the XML will not be correct. The difference now is that the XML is in a SQLite database file rather than in an XML file.
Also, the problem with FAT formatted drives “shouldn’t” be a problem, given that FAT is an archaic format - it’s unfortunate that Microsoft haven’t yet completely abandoned it in favour of the many superior disk formats available.
The SQLite format itself is robust and widely used (example: Firefox settings, millions of websites, very many iOS applications, and even flight software for the A350 XWB family of aircraft).
What is true though, is that the old “AUP + _data” format has had 20 years to iron out bugs and glitches, whereas the AUP3 format is still relatively new (first release in 17 Mar 2021).
The main problem was the constant stream of users losing their work due to the AUP and _data folders becoming separated - often because users would “tidy up” and delete the _data folder without realising that it contained the audio data. One particular case sticks in my mind, which involved a recording of somebody’s father’s final words - lost forever.
Most likely in that case that the page can be downloaded again with just a few mouse clicks - rather than redoing hours or weeks of work.
The SQLite format itself is robust and widely used…
In Audacity 2.x it is just as important that Audacity terminates correctly, otherwise the XML will not be correct.
Quite right however, the xml file is very quick to write versus a lot more data with the database version.
It’s the time involved to write that increases the risk of corruption.
Of course if Audacity bombs out before the save process is started, the chances of corruption is still there with either.
Also, the problem with FAT formatted drives “shouldn’t” be a problem…
In theory yes, however I don’t see Microsoft getting rid of FAT anytime soon, so it will remain a problem for some years to come.
To this, there is the added “complication” that many devices like smart TVs and media players don’t yet support NTFS (and other file systems),
so may users will format drives to be compatible with these devices and their computers and then try and use them for audio projects using Audacity.
FAT is also fully compatible with MacOS and Linux (read and write), where as NTFS is OK with Linux but does not play well in MacOS especially with writing to NTFS drives.
Most likely in that case that the page can be downloaded again with just a few mouse clicks - rather than redoing hours or weeks of work.
Yes true, but the concept is the same and brings me to another point that you made as to project files being lost due to users deleting them,
where does one draw the line?
Especially if the folder has the same name as the project file with a _data appended to the end.
The XML in the database version is the same as in the old format except that it is now written as binary data rather than being converted to text.
You can just about make out the old XML format in this screenshot:
I’m would guess it’s got to do with Google Drive - not with any corruption of data.
I’ve just now done the following:
opened a file on my desktop - works
moved the file to my Google Drive - can’t open it anymore - failes with
“log”: “18:01:55: DBConnection SetDBError\n\tErrorCode: 10\n\tLastError: Failed to set page size for database /Meine 04-Sing Alleluja clap your hands - \n\tLibraryError: disk O error\n18:01:55: DBConnection SetError\n\tErrorCode: 10\n\tLastError: Failed to open database file:\n\n/Meine 04-Sing Alleluja clap your hands - \n\tLibraryError: (10): disk O error\n”
moved the file back onto my desktop - works again
Reading the error message, it might have to do with blanks in the file name? The actual path is “~/Google Drive/Meine Ablage/Musik/04-SingAllelujaClapYourHands.aup3” but the error message shows only parts of this … just a guess …
Yes - you are quite right: Do not use cloud drives for Audacity projects files. If you must do so, first copy the file locally, work on the local copy, then after closing the project, copy it back.
So all of the cloud services are going to have issues with the project files, depending on implementation details. On one service you may get a certain error today - tomorrow using a different service, you may get an entirely different error. In some cases you may not get an error reported at all, but the file will be corrupted and you will lose your data.
Yes. I have seen various database related errors disappear when the project is copied to a local drive. Yes - I have seen projects (usually without provenance) that are currently on a local drive and that are “corrupted” and exhibit this and other specific errors.
I’m using other applications quite a lot with various cloud drives.
I would expect that there is some ‘issue’ in the implementation that is not according to standards. Some cloud services are like disk drivers to other types of disks, which are intended to be transparent for the application …
I’ve found a simpler fix to all of this using the project tools (which I couldn’t run because I didn’t have the correct VCRUNTIME libraries).
Simply run Audacity as an administrator (right-click the app icon, go to Properties, go to the Compatibilty tab and tick the box ‘Run this program as an administrator’). Then all your .aup3’s that stopped working will now work again.
