koz,
See, you’ve got your thinking cap on… I knew if I asked nicely, you would design this for me. All I have to do now is implement it.
Jack/Dave,
OK, one of the ideas we were exploring was the possibility that for some reason, the file names in your project got scrambled. I took at look at all file names mentioned by the four aup files you supplied and in the mack_data directory to see if there were duplicates. In reviewing the 7,185 file names, there were 278 duplicate file name names (which duplicates were mostly of a random nature). And I confirmed that none of the files named in the mack aup file were actually present in the mack_data directory. This confirms to me two things we already suspected (or knew): (1) The project files did not seem to be “crossed”, and (2) the file names are assigned completely randomly.
Speaking of random: I did some research on the (now obsolete naming convention used in 2.4.2 and confirmed some things we mostly already knew. The file name consists of eXXYYZZZ (not ZZZZ) held under XX then YY subdirectories. ZZZ is the random number, YY get incremented by 1 after every 256 random files get generated. Ditto for XX. The idea is to keep fewer than 256 files in a directory as certain OS’ had directory performance issues. The “ZZZ” I believe was partly to keep performance relatively consistent by randomizing directory position (generally file “000” could be retrieved faster than “fff”). Of course, today’s file systems have better performance and for Audacity 3.x.x, SQLite3 changes everything so we no longer need be concerned with the directory structure.
One issue that puzzles me is that your AUP file named only 1211 block files, yet the _data directory contains 2375 block files (about double). Also, about the half of these latter looked to be all zeros but when I amplfied them by 45-50X I found (noisy) conversational audio.
Anyway, I am continuing my efforts… remember, koz has told us about the baskets and the musical matching.
This may prove to be an issue. There were certainly many (not excessive) envelope control points that we’ll probably need to skip.