Forced drive type

Dear Audacity devs,

I decided to test drive Audacity 3 to see what are the upcoming changes and I immediately bumped into a terrible change that makes it completely unusable for me.

I am well aware of the limitations of FAT drives, I’ve been working with them in an audio setting for long enough. Please don’t treat all your users as idiots who can’t possibly be able to manage their own drive settings. It is the height of user unfriendliness to force a setting just to remove the chance of a predictable, preventable and rare issue to crop up.

It’s of course fine if you set Audacity’s temp folder to a non FAT drive by default and alert about FAT usage when necessary, but let your advanced users set whatever drive they want to use. I for example have my temporary folder on a ram drive and if Audacity won’t let me use that, it becomes completely useless because I will not switch to a fixed drive only to worsen my user experience.

Changing to a drive that makes Audacity 3 happy, doesn’t have any benefit for my workflow whatsoever, only downsides because I never edit files that get anywhere close to 2gb let alone 4gb. Please reconsider this unnecessary imposition, this uncalled for limitation and let your users explicitly select any drive they want.

Audacity cannot use FAT formatted drives for the Temp directory because FAT does not support “sockets”.
There’s also the issue that even modest sized projects can easily exceed 4 GB, which is an issue now that the project is a single file.

I did a LOT of QA testing on FAT/FAT32 drives when we were working on the development of Unitary Project, before we finally decided to block their use.

I found that even with relatively short projects, a 4-5 minute song say, and with several edits (which is not unusual for our users) I could soon exceed the 4GB drive space available for a single file and the project would halt with an out of drive space error. That is why we ultimately decided to remove the use of FAT/FAT32 use for UP-3.0.0 in order to protect the majority of our users - many of whom are not mega computer savvy.

This is basically because temporarily the project grows much larger than is the case for just a 4 to 5 minute recording, as the various states have to be stored to support the Undo capability. Of course once you close such a project the undos are thrown away and the project is compressed back to the expected size for a 4-5 minute song.

This only became an issue with the single project file structure for 3.0.0. With 2.4.2 and earlier this problem does not arise as we have the AUP file which is in effect the “project manager” and the audio data is stored in (lots of) individual block files of 6 seconds in the data folder. So with 2.4.2 even very large projects never encountered the FAT/FAT32 4GB limit. But over the years this complicated mult-file project structure has caused many users to lose or damage their valuable projects - that is why we decided to move to the unified project file structure for 3.0.0.

You do of course thus have the workaround to stick with 2.4.2 if FAT/FAT32 usage is the most important criterion for you.

Or you could reformat your FAT/FAT32 drive to exFAT (which does not have this 4GB limitation).

Perhaps, since you find it necessary to have your temporary files on a RAM drive, you should consider using a computer with an SSD drive for your system drive and thus the default location for your temporary files directory.

The W10 PC and the Big Sur Macbook Pro that I use for QA testing both have 256MB SSD drives and handle Audacity (including large projects) slickly, I regularly work with 2 to three hour projects.

The PC which is my workhorse also has an on-board 1TB spinning metal drive in addition to the SSD - but there:
a) I have my live projects on the SSD, along with my temp files directory
b) I archive them to the 1TB spinning metal disk (and to two external USB drives)


Let’s say soon-ish when 4GB can literally store 100x 4 minutes of audio at full CD quality (or still roughly 30x 4 minutes with 96khz/24bit stereo). I have more than two decades of experience with audio editing and with the kind of editing I do, I literally haven’t bumped against the FAT file size limitation once. Not even when I used to author audio CDs back in the day which could go over 79 minutes in length. With the kind of editing I do nowadays, I’m not getting any closer to hitting that limitation, in fact I’m very far away from it. Obviously I know what it would take to hit it and I know that this limitation does really concern certain use cases, all I’m saying is that there are also plenty (and likely more) of use cases where this is a total non issue.

I understand all that, which is why I said I see no problem if the default setting for Audacity v3 is the way it is, ie forcing a non FAT disk for temp files. I’m not asking to revert this back to v2, all I asked for is an explicit setting to let a person that knows what they’re doing change that. I wouldn’t mind if you made it accessible only through manually editing audacity’s cfg file in the users folder (so if you left the setting out of the GUI). That way no one could turn this on by mistake if you find that to be a reasonable fear.

Presumably this was a user side issue (understandable one). I mean surely it wasn’t Audacity that couldn’t keep track of its multiple files, right? If so, there’s no real benefit for the user if the undos are also all stored in a single file, is there? The users aren’t supposed to directly interact with undo files, so they don’t really care how the app writes them and even a unified file on the user facing side, could work with multiple undo files on the back side.

Far from ideal since v2 is horribly slow compared with some other audio editors, even freeware. After a very quick test v3 seems significantly faster than v2 (nice job here), more or less matching the competition and it would definitely be nice to take advantage of that speed increase.

Thanks for the tip but I’m already using SSDs, for a while now not even as just system drives. However I don’t see the need to route my temp files to an SSD just to humor an overly zealous user error protection, when I have more than enough space for them on my RAM drive with all the various benefits that come along with that. A user friendly app is supposed to have sensible and safe defaults, but it also shouldn’t unnecessarily hinder and cripple perfectly legitimate and valid use cases. With this change you haven’t simply added secure locks to prevent accidental opening of car doors during transit, you weld the doors shut and now they can’t be opened even intentionally. Sure I can still get out of the car through the window, but it’s not ideal is it. Btw this FAT limitation issue is mostly a self resolving one since there’s fewer and fewer FAT disks out there anyway (Win XP was released 20 years ago and it already used NTFS by default).

So there is really no incentive for the Audacity developers to change the design of Audacity to support a 40 year old file system that is well on its way to becoming obsolete.

audedit - let me check: You’re using a free RAM disk that does not support exFAT or NTFS, and that’s the reason the ‘simple’ fix of just changing the drive type that we’ve suggested isn’t on? And if that’s the reason, I totally get the resentment at maybe having to pay $9.99 (for Radeon’s pro RAM disk software) or $25 (for SoftPerfect after v 3.4.8 RAM disk software) or maybe $30 (for a really fast good USB3 flash drive that can be exFAT format).

We’ve decided on a policy of not enabling FAT with the new .aup3 format. With millions of users many of our users are not that computer sophisticated. If these users use a FAT formatted USB flash drive as a temporary store they will likely run into the 4GB limit and then come a cropper. We’d rather have the conversation with you about why we’ve disabled FAT than with 100x as many people about recovery from overfull projects.

We’re not going to build in even a hidden and hard to find new option to re-enable FAT. That option is already there if you want it enough - the option to build the software from source yourself. If you want to do that, I will show you which line of our source code you need to change to re-enable FAT. I’m not though prepared to incur the cost in time for both me and for Audacity support volunteers of making the mainstream version support disk formats (FAT and FAT32) that will cause problems for most users, if they use those formats.

ImDisk Toolkit claims to support NTFS and is free.

I appreciate the snarkiness :wink:, but that’s not the reason. It’s a matter of principle, well two principles. One is supporting and using open source software as much as possible, the other not fixing and/or changing stuff that works perfectly fine. I’m always happy to make changes for the better, being forced to make them just so I can get back to where I already was if not worse (usb flash drive vs ram disk seriously?), doesn’t induce quite the same level of happiness as I’m sure you can understand.

Fair point. Now sure, computer unsophisticated users switching Audacity’s temp folder to a flash drive AND writing files in excess of 4GB does sound a bit like a unicorn to me, more importantly I’d also worry what such users will do when they attempt to switch the temp folder to their flash drive (most likely for a reason like lack of space on their fixed drive because why else would computer unsophisticated users even bother with these settings) and be told that’s a no go, but I genuinely don’t presume to know your users better than you do and it’s obviously reasonable to cater to a larger rather than a smaller number. I wouldn’t expect anything different, I only started this thread because I’m not convinced this is the optimal solution. After all it doesn’t seem to be the common solution among audio editing apps.

I’d appreciate that.

I was being snarky, and/but it came from genuine puzzlement as to why formatting a (presumably temporary and often blown away!) RAM disk a different way was considered a bother. A minor inconvenience for someone technically so clued in. It’s surely rare to use a RAM disk with Audacity??? I think using a RAM disk you are more of a unicorn than our less experienced FAT32 USB key users are! :smiley:

The (new) function IsOnFATFileSystem is where we do the FAT file system checking. I think it’s these two uses that pop up the unsuitable drive messages. We don’t want to accept a patch that makes this a preference option, if you’re making one. We don’t currently think it’s an often enough useful option to justify it in the mainstream version. We are though totally behind people who want to take Audacity code and customise it. It’s one of the big freedoms of Open Source. Fair play to you for being ready to do so!

32 FileNames::PathType::_None), wxT(“”));
34: if (FileNames::IsOnFATFileSystem(path))
35 {
36 ShowErrorDialog(

118 wxWindow window / = nullptr */ )
119 {
120: if (FileNames::IsOnFATFileSystem(path))
121 {
122 ShowErrorDialog(

James Crook wrote: ↑
Sat Feb 27, 2021 11:20 am
audedit - let me check: You’re using a free RAM disk that does not support exFAT or NTFS, and that’s the reason the ‘simple’ fix of just changing the drive type that we’ve suggested isn’t on? And if that’s the reason, I totally get the resentment at maybe having to pay $9.99 (for Radeon’s pro RAM disk software) or $25 (for SoftPerfect after v 3.4.8 RAM disk software) or maybe $30 (for a really fast good USB3 flash drive that can be exFAT format).

Thanks for the great software now downloadable on the 'Net (free) in Version 3.01.02:

[WARNING: This download is unofficial, unsupported, untested and may be dangerous.]

Just grabbed an old USB and it worked.

Please note than “Audacity 3.0.2 rc01” is not an official release.
Please also note that downloading software from unofficial sources is potentially dangerous and definitely NOT recommended.

Found this thread after bashing my head on this problem.
As a business I have a weekly podcast and we use google drive (filestream) and I collect wav files from hosts. It is an easy way for my team members to share to a common folder. My finished projects run between 400-700MB. This puts me WELL under the FAT limit. However, thanks to this nice ‘check’ I am forced to quit the software or find a new working directory.

I get the fat check…but make it a warning rather than a hard error. I am happy to work within the limitations. But this should be my choice, not the dev choice.

This may be the breaking point for my use of audacity if it is not fixed. I really don’t want to have to create yet another volume, it will be far easier for me to just start using audition instead.

1 Like

Here’s the issue re. FAT formatted drives:

For Audacity 3.x, a new single file project format was developed.
Why? Because it is heartbreaking to see inexperienced or less technical Audacity users permanently losing their work because they haven’t understood the concept of a multi-file project format. Week after week on this forum we would see users that had inadvertently destroyed their own work, sometimes valuable, never to be repeated recordings. In one sad case it was the final words of a relative.

The technical challenge: how to modify data in the middle of a long track without having to write the entire track data (which could be several gigabytes).
The original solution was to split the track data into small “block files” (the “.au” files in the _data folder), but how to do that with a single file format? It is not possible to just write data in the middle of a normal computer file.

The answer was to use a kind of database - SQLite
As with other databases, it is possible to access chunks of data, read them, modify them and write them back to disk. Unlike other databases, SQLite manages to achieve this yet still use a single file format for the database.

After many years of thinking, discussing, and considering very many possible solutions, SQLite looked like the best answer. Two of top developers began working on developing a “Unitary Project Format”, based on the SQLite database.

Unfortunately, a snag was discovered:
One one of the platforms that Audacity supports, there is an ancient (44 years old, which is an aeon in computer technology) disk format called FAT, which is still used today. By today’s standards, the FAT file system and is very primitive. Among it’s many limitations, it does not support file locking, which is required by SQLite in order to perform secure transactions.

There were two choices; either abandon the work, or drop support for FAT. An executive decision was made to drop support for FAT. In this case it was decided that the needs of the many outweighed the needs of the few.

Since Audacity 3.x has been available, the number of cases that we’ve seen on this forum, of people losing / destroying their projects, has reduced very noticeably. Of the few cases that we have seen recently, most if not all have been using older (2.4.2 or earlier) versions of Audacity, with the old “pile of files” project format.

I know this is old, but why would this affect you? You wouldn’t happen to be using Audacity projects directly on the virtual cloud storage drive, would you? That’s been against all recommendations even before the AUP file format change. It’s been strongly recommended for years to work on a project on a fast, local drive, which a cloud drive is not. And all fast local drives, since almost the beginning of this century, will be formatted as NTFS (or ext4 or btrfs or whatever if you’re on Linux or APFS on MacOS). (A USB flash drive formatted as FAT doesn’t count as a fast local drive either.)

So I don’t understand why anyone would take issue with this. We’re not in the '90s anymore so don’t format your main system drive as FAT! (Then again, Linux users were using ext2 at the time which would probably work fine, even with its 2TB file size limit.)

OK so I’m using win 10 and my external storage devices are all formatted recently so probably a recent fat file system and I still get an issue with saving an aud project (660k) to my external drive (fine) and then later going back to do more editing in Aud 3.3, trying to open my project from the external disk, I get the error message can’t access the database before audacity either doesn’t load my project or crashes (take your pick). So, my temporary work around is to export a working file as a wav and then when I’m working on my project, I import it (no problem). Now, I got used to this with audacity for years, finding work arounds in windows for various issues that pop up, but reading the discussions, I guess my problems are small, compared to some. But I’m including my work arounds here in case other (less techy) people might need the suggestion.

thanks, Rick

And BTW: Along the way in various iterations of Audacity and the issues with saving and retrieving aup files we lost some data files, and it was frustrating, but we learned from the process. So, all I can say is we are still in this process with you DEVS and thanks for all your work. It can be difficult with so many people and so many possibilities and I for one am grateful. I have friends who swear by their proprietary audio software but I’d rather be doing my important audio work here, open source. Unfortunately, we have those at our radio station, that would prefer to use proprietary software to run our broadcasting (Radio Boss) vs. the open source (Radio DJ) software because of time constraints in using and attempting to understand the software.
But, again thanks for all you do.