Look in “File menu > Check Dependencies”. If Audacity reports that there are dependencies, select the option to copy all files.
Avoid working with really long files. If the book is over an hour long, consider splitting it into half hour sections.
How much free space is there on your SSD? A one hour project can easily grow to many gigabytes of data while you are working on it.
There is no “real time” way to slow down playback without lowering the pitch. There are the “Change Tempo” effect and the “Sliding Time Scale / Pitch Shift” effects that can do this, but these are “applied” and change the audio.
The nightly builds are probably the same speed. They are not intended for “production” work as they may contain experimental code that is being tested, so there is no guarantee that they will be stable.
Regardless of the drive type, the difference between having dependencies and copying in the audio data on import is “when” audio data gets copied.
Audacity has an “on demand” import feature which allows Audacity to access the audio data from uncompressed audio files (such as WAV files) without copying the data first. On (slow) hdd drives, this can make the initial import quite a lot faster because Audacity only needs to calculate the waveform and does not need to copy the data. However, if the audio data is changed due to processing the track, then the audio data will need to be copied at that stage, which can be slower than if the audio data was copied in initially.
The audio data in the Audacity project _data folder is as “blocks” of data (there may be thousands of data blocks for one file). This allows Audacity to access any part of the audio track very quickly as it can load and process the relevant blocks rather than processing the entire file.
For an SSD drive, copying the data on import should be very much faster than on a conventional hard drive, so importing in this manner should be virtually as fast as “on demand”. The major time usage here will be in calculating the waveform display. Copying the data on import will allow Audacity to create the block file structure, which is indexed, and so take advantage of fast access to arbitrary parts of the audio data.
On modern machines there is little advantage to keeping all of the audio data in RAM. For very slow machines drives it can avoid the situation of the computer waiting for the drive, but on a modern machine the hard drive should be able to keep up. With an SSD the drive should easily be able to keep up with read/write demands.
The disadvantages of keeping all of the audio data in RAM are that the machine may not have enough free RAM for all of the audio data. Some Audacity users have less than 1 GB of RAM total on their machine, Even for users that have large amounts of free RAM they can run into problems on large projects as Audacity has an unlimited Undo history, which can make the project audio data many times bigger than the original audio. As a rough approximation, 4 hour of audio data at 48 kHz, 32 bit float, stereo is about 4 GB. Apply 10 processes to the audio and the project data will grow to about 40 GB. It is important that Audacity has enough free RAM when processing data. When processing, Audacity will read data from the disk, process it and dump it back to disk. If there is insufficient RAM to do that, then data will be swapped between RAM and disk just to make enough space for the processing and this has an extremely bad hit on performance. There is also a problem that some machines report their free RAM incorrectly, which can cause Audacity to freeze or crash if available RAM is exhausted, so the “record/play directly from RAM” option has been disabled for safety.
You were asking about how to make Audacity run faster. I’m just giving some hints for how to do that.
Audacity needs to regularly refresh the waveform image to keep it in step with the audio data. It also needs to regularly update the Undo history, back up the current state, and many other “background” operations. These operations all take time and tend to get slower the more data that there is.
There is a major problem if you hit the 13 hour mark (noted in the Audacity release notes), which is that the project runs out of numbers. Audacity is a 32 bit application and each audio sample has a position value. The largest positive 32 bit number is 2147483647, which at 44100 Hz works out at a bit over 13 hours, so this places a limit on the largest Audacity that can be saved (as a project) and reopened successfully. Other problems that can affect very large projects is that the largest possible WAV file is 4 GB.
Audacity is without doubt the leading open source multi-track audio editor. There may be specialised software for editing very long audio files that is better for that application.
Are you sure? The largest SSD drive that I can find is 2.4 TB and costs over $30,000.
That depends on how long the audio selection is (which you have not said) and how fast the machine is.
“Change Tempo” is a lot faster than “Sliding Time Scale / Pitch Shift”. On my (budget) laptop, Change Tempo -20 % on 1 hour, 32 bit 44.1 kHz mono takes about 50 seconds. “Sliding Time Scale / Pitch Shift” takes much longer.
You’re asking about a spell checker for the forum? Yes you could suggest that on Maintaining / Improving this Forum, though I’m not sure if it is possible to spell check in phpBB (the forum software) in different languages for different boards (we have forum boards for French, Spanish and Russian in addition to the English boards).
“Firefox” was also a serious suggestion. My spelling is hopeless but Firefox checks while I type. I can also set it to US spelling when writing Audacity documentation as US spelling is the “official” form for Audacity documentation.
Again you can make suggestions on the Adding Features board: http://forum.audacityteam.org/viewforum.php?f=20
One of the main limitations for “labels” is that it was originally designed for just adding a few “markers” to aid with audio editing and it was not anticipated that users would want to enter large amounts of text, so it would probably be quite a major (but worthwhile) project to restructure label tracks to be able to handle an unlimited amount of text. As labels are also tied in to other (audio related) functions, it may actually be better for there to be a separate “lyrics” track that is designed specifically for handling large amounts of text without needing to worry about other audio related functions.