// archaeology
A ten year archive is not a problem, it is material.
The second band we want to try this on has roughly a decade of recordings: multi-hour rehearsals, first jams, successive versions of the same compositions, the takes that ended up on a record, and plenty that never came out. All of it sits in the cloud, some on old file accounts such as box.net, some in Dropbox, in a folder structure nobody remembers any more.
For the tool that is not an obstacle, only scale. An hour of material costs a dozen or so seconds of computing, so thousands of fragments are a night's work rather than a project. Connecting Dropbox or any other cloud drive is a simple integration, because we read the files one by one and change nothing in them.
A song's history on a timeline
First jam, later rehearsals, demo, album version. You can see when the riff appeared, when the chorus was written, and what survived from the very first run-through.
planned
Forgotten ideas
Songs you have not played in years, and fragments that never got a second chance. Not another batch of new riffs, but a reminder of the ones you already have.
planned
What to finish first
Instead of a list of everything: which songs are closest to done, by your own judgement rather than a number produced by a model.
planned
There is a trap here worth naming up front. Released songs have more recordings in the archive because the band played them more often. An algorithm handed the whole archive will learn to detect "this was played many times" and will get almost everything right, except that this is circular: the song was played many times because the band decided to develop it. For the test to mean anything, the prediction has to come from a single earliest recording, with no information about how many other takes exist.