Does anyone know how to automatically put a label at the beginning of each of the tracks which have been aligned end to end? The label should contain the name of the track (which corresponds to the name of the file from which the track has been imported).
Yes, I need to put labels at the beginnings of tracks because I regularly import many audio files and then export them after bulk editing. But I do not know the Nyquist programming language.
The following Nyquist script which was given me a few years ago labels aligned tracks, but it has a limit of about 13-14 hours of audio from files imported into a project, so that the script does not run when the total audio of all the tracks exceeds this limit.
Do you know what needs to be changed in the script so that there may be no limit?
(setf id 'track-labels_2019-05-09_23:17:39)
(defun new-label ()
(list (get '*track* 'start-time)
(get '*track* 'name)))
(defun add-label (labels)
(push (new-label) labels))
(if (get '*scratch* id)
(let ((labels (get '*scratch* id)))
(putprop '*scratch* (add-label labels) id))
(putprop '*scratch* (add-label ()) id))
(if (= (get '*track* 'index)(length (get '*selection* 'tracks)))
(let ((labels (get '*scratch* id)))
(remprop '*scratch* id)
labels)
"")
Can’t you just Export Multiple based on Tracks (rather than based on Labels)?
and use the track names for the exported file names?
A sufficiently recent version of Audacity.
I’ve just tested with Audacity 3.1.3 and it works with a track that has a start time of over 25 hours.
The project also has a track at the bottom under all of the tracks:
During exporting, each of the tracks above which have been aligned is to be mixed with the audio in the track at the bottom of the project. That is why I have to use labels, because I do not know how the desired result can be achieved without labeling each of the tracks.
I use an older version because it has the option to read audio instantly from uncompressed .wav files, whereas newer versions take very long to load big .wav files into a project.
I don’t think a fix is possible in Audacity 2.x on Windows because it is a 32-bit app. The largest 32-bit signed integer value is 2147483647, which works out as 13 hours 31 minutes and 35 seconds for a sample rate of 44100 samples per second.
The current version of Audacity for Windows is a 64-bit app, and Nyquist has been upgraded to support very large sample counts when running in 64-bit Audacity.
Thank you for the explanations. Do you know why the newer version of the program does not have the option to read uncompressed files instantly? I regularly upload big .wav files into a project and therefore use the older version which uploads them instantly.
According to this thread:https://forum.audacityteam.org/t/project-preferences/61935/1 the “On Demand Loading” feature was removed in 2.3.3 for the following reasons:
- There were many reports of broken projects due to missing dependencies.
- There was a reduction in need as disks were getting larger, faster and cheaper.
- There was no benefit at all the moment the audio was altered.
I know “some of the reasons” but not “the reason”.
The technical name for the feature that you are referring to was “On Demand Loading” (also known as “OD”). It was developed at a time when most home computers had spinning disk drives, which had read/write speeds roughly in the ballpark of 100 MB/s. In Audacity prior to v.3.0, loading an audio file involved:
- Reading the data from the drive
- Writing the data as “blockfiles” into the project “_data” folder
- Calculating peak and rms levels for each block and for “summary data”
- Drawing the waveform
On Demand Loading allows the outline of the track (start and end of the track clip) to be drawn virtually instantly (the length of the clip is known from the file header). Audacity would then perform the reading, calculations and drawing in the background, giving priority to any region that user clicks on. Writing the data was deferred, using “alias blockfiles” as placeholders until such time as it was necessary to write the data to disk.
Because the actual blockfiles were not written on loading, there was an immediate and significant reduction in loading time, though this time saving was only temporary. Saving a project that contained alias blockfiles was considerably slower than saving a project that has already written the blockfiles to disk, unless it was saved without writing the audio data into the project’s “_data” folder. If the data is not written into the _data folder, then the project still depends on the availability of the original WAV files.
Sadly many Audacity users lost work because projects that use alias blockfiles require that the original audio files (“dependencies”) remain in the same place with the same file name. If a WAV file is a dependency of the project and the WAV file is moved, renamed or deleted, the project disintegrates → no data.
Roll on 20 years and most computers have SSD’s which are considerably faster than the old hdd’s. Much of the benefit of OD loading disappears due to the much faster read / write speed, but the main downside (more fragile projects) remains.
Then came Audacity 3.0 with its new single file “AUP3” format. The purpose of the new single file format is that projects become much easier for users to manage - the risk of the “AUP” file and its associated “_data” folder goes away. Projects are immediately more robust because there is only one file to worry about - the “AUP3” file. Against this model it would not be sensible to reintroduce external dependencies, especially as the benefits have become marginal on modern hardware.
While I can see that OD would still be some benefit for people that work on huge projects, the vast majority of Audacity projects are between a few seconds, and a couple of hours long. The risk to unwary users, and the additional work for developers to maintain OD loading, were considered to outweigh the benefit to the tiny number of users that work on massive projects.
Thank you for the detailed information. I use an HDD on a slow laptop computer. That is why on-demand loading is very convenient. But I may have to start using the newer version, even though that will mean waiting much longer for big .wav files to load. The newer version at least does not have the 13-hour time limit for Nyquist scripts.
In the latest 64-bit version of the program, I have tested the following Nyquist code on two tracks aligned end to end whose total length exceeds 13 hours 31 minutes. (To instantly create long sample tracks, the “Silence” command can be used by going to Generate > Silence and then specifying long duration.)
;version 4
;; Unique symbol for *scratch* property.
(setf id 'track-labels_2019-05-09_23:17:39)
(defun new-label ()
(list (get '*track* 'start-time)
(get '*track* 'name)))
(defun add-label (labels)
(push (new-label) labels))
(if (get '*scratch* id)
(let ((labels (get '*scratch* id)))
(putprop '*scratch* (add-label labels) id))
(putprop '*scratch* (add-label ()) id))
(if (= (get '*track* 'index)(length (get '*selection* 'tracks)))
(let ((labels (get '*scratch* id)))
(remprop '*scratch* id)
labels)
"")
The following error message appeared when I ran the code:
That’s due to a quirk in 64-bit Windows that has not been addressed yet. I sent a patch to the developers to fix it quite some time ago, but it is still waiting to be fixed.
If you’re able to build Audacity from the source code, it’s quite an easy fix. In /src/effects/nyquist/Nyquist.cpp line 113, change:
#define NYQ_MAX_LEN (std::numeric_limits<long>::max())
to
#define NYQ_MAX_LEN (std::numeric_limits<long long>::max())
Thank you. I do not possess the programming knowledge needed for compiling the program from the source code. If you have a compiled Nyquist file, can you simply attach it in a post? I will then substitute it for the file with the same name in the program’s directory.
It’s not the Nyquist file that needs to be compiled, it the Audacity app. As I build on Linux, my builds would be of no use for you on Windows. We can just hope that the Audacity developers fix it soon.
Can you also explain what program I should use to compile Audacity, and where its source files are stored on the Internet?
The source files are here: https://github.com/audacity/audacity
For the 3.1.3 release version, the source code is in the “Assets” here: https://github.com/audacity/audacity/releases/tag/Audacity-3.1.3
Compiling on Windows is usually done with Microsoft Visual Studio 2019. Details are provided here: https://github.com/audacity/audacity/blob/master/BUILDING.md
If you need help compiling, the best place to ask is on the Audacity Dev discord channel: https://discord.gg/zz4U58MF (time limited invite) and ask in the “#compiling” section.
Thank you very much for the instructions. If I understand correctly, besides Visual Studio, certain other programs are needed:
python
conan
cmake
If I am not able to compile the program, I may have to ask someone to do that. After making the change in /src/effects/nyquist/Nyquist.cpp and compiling the program, what compiled file will contain the change? Is it the program’s .exe file or some other file in the compiled program’s directory? If it is just one file, then if someone else compiles the program, I will simply have to substitute that file for the file with the same name in the program’s directory.
It will be the “audacity.exe” file that contains the change.
It may be worth (politely) informing the developers that you need this fixing here: https://github.com/audacity/audacity/issues/1607
(A free GitHub account is required to post.)