Dear All,
I have a peculiar situation here that I would like to get an answer to. I am running our own version of Audacity 2.1.2 - on Windows 10, which I compiled with Visual Studio. All of the core code is the same - we just have a component which connects to a database to show current content files in our system.
My executable interfaces with this db and provides functionality to import/export files from our database system and because of this when I need to Import a file - I pass it the file name to import from (via db info). Audacity imports the file (via the Project OpenFile method call) and the waveform shows up in the Audacity track(s) window.
I then tried to delete the file - because it’s been successfuly imported into the project, but after trying to do that several different ways - I eventually tried it in a command window and got an error that another process is using the file… - ah - Audacity still has it… I looked at Project methods and dont see a way to close the file handle( maybe I missed it?.
My question is - am I correct that once Audacity opens a file - it holds on to the file handle? Why would it do that - since I though it put all of its information into the project structures. When does it actually release said file handle? Is there an easy way to get it to release it’s file handles so I can delete them.
This is a problem because the files being imported are being created by a completely different application - for the sole purpose of giving it to Audacity. I need to clean these files up - or end up having who knows how many .WAV files sitting around for no reason…
Any information on how or why Audacity does it this way and how to get around it would be greatly appreciated.
Hmm… well, that actually still creates a file, but I see now that our code is actually opening the file, and thus
doesn’t appear to release it even though the import has happened…
Guess I need to look at the Audacity source and see how this happens for Imports that don’t come from our system…sigh…
Thanks,
I don’t use Windows, so you probably know more about file handles in Windows than I do.
I may be able to cast a little light on what Audacity does.
When the “copy / safer” method for import is used, Audacity copies the audio data from the selected files and creates a bunch of “blockfiles” in the project data folder. If the project has been saved at some point, the project data folder is the folder that has “_data” at the end of the folder name. The “blockfiles” are PCM (by default, 32-bit float) with .AU as the file extension. If the project has not been saved, the data folder is in Audacity’s temp directory (see: Edit menu > Preferences > Directories).
When the “fast” method for import is used, Audacity creates a bunch of “alias files”, which act as place-holders and point to audio data in the original file. The alias files are stored in the project data folder in much the same way as blockfiles.
In order to maintain the “Undo” history, Audacity has to keep track of all files, edits and processes that have occurred since the start of the current project session - that is, since the project was opened or a new project created. This internal bookkeeping persists until the project is closed. If you simply delete all tracks in a project, the project does not suddenly become a “new” project because deleting is just a command within the current project session (and in this example, you can undo the action with Ctrl+Z).
To close the current project, you can either shut down Audacity (example: File menu > Exit), or just close the current project (example: File menu > Close). “Closing” a project automatically spawns a new project. Audacity ‘should’ clean up all of it’s internal bookkeeping for a project when the project is closed.
From version 2.0.6 onwards when we updated Audacity to use a later version of FFmpeg, Audacity keeps a handle open on files imported using the FFmpeg importer.
FFmpeg is not the reason for your issue if you see the warning about importing uncompressed files when importing WAV, because that warning only occurs when you import using libsndfile.
If you are running Audacity from within the Visual Studio debugger, or from a build folder that has all the lib files, it’s possible that is the explanation.
Thanks Steve, Gale et.al,
I think the FFMPEG stuff is probably the culprit here, as well as the functionality for Undo’s. I recognize that we are using Audacity in a different way (as in our input files are being force fed into Audacity), and so, since Audacity assumes it doesn’t needed to worry about file handles it has open, it on us to handle it (no pun intended).
We are going to have to figure out a way to house clean these ourselves me thinks.