It looks like you will have to find an alternative way to fingerprint your files (in the future). Or even have a separate program that will do this.
MC already has a fingerprint, as confirmed by Jim, and it works very well with YADB. Perhaps a future enhancement could be for MC to use this during import to solve this problem.
Your situation is much more complicated to recover from than usual, as you say you can't use filename and paths etc.
The issue of using filepaths isn't really unique to me and it really isn't complicated - there just needs to be a single piece of information that maps a piece of data (the track) to the database entry.
Centralized online databases such as YADB, Freedb, etc can't use filenames either and need some other method to identify tracks. Fingerprinting is one method of doing this.
Depending on filepaths for recovering from loss is also not dependable, but it may work for most home users. If you depend on a central database such as YADB or FreeDB then there's no guarantee that the path you originally used will continue to exist and be returned for the same track.
Every ripping program needs some way to name files. You can choose to use 'track01', 'track02', etc and store files that way, but then you are entirely dependent upon applications to do runtime identification. If you lose their databases you've lost all metadata and can't identify those files. If you rename files outside of the app (move to another drive, etc) then you've again lost all metadata and can't identify those files (that's where the "fix broken links" feature of MC arises, but I don't know how it identifies files as matches for broken links or I might be able to make this work)
I look at the problem wholistically based on
knowns and
unknowns. The
only part of a media file that is guaranteed is the content itself. Everything else is transient. It isn't a new concept and absolutely is not uncommon - there has been a lot of research on this subject with a large number of papers published around this very topic.
I tend to think in units of album artists & albums or by radio show. So if such a thing were to happen at worst i would know which albums to rip etc. I never let MC organise the path based on Properties. Since MC can easily display this in panes, i prefer a simple way to represent how data is stored on HD.
I do know which albums need to get replaced and can rerip them easily. Matching the ripped files to the database is where the issue comes in.
How I name my files isn't entirely relevant - the ability to reproduce it is what is key. CDA doesn't have a concept of files or filenames, so ripping applications compensate. If you simply follow a schema [Artist]/[Album]/[track#] then the actual text you use is still relevant. Track01, track1, track01 are all different. When artist or album names contain characters not valid in filenames, what did you use in place? Or did you leave the characaters out altogether? Then there are tracks from data CDs with naming schemes already applied. These are generally not unique and some additional facility must be used for naming (an additional directory level for instance) to help ensure uniqueness. Again reproducability is the issue.
Computers aren't "fuzzy". While we all know "Mr. E's Beautiful Blues" and "Mr Es Beautiful Blues" is the same track, as far as your computer goes they are not.
In my case, MC has been dead-on in using YADB for identifying unknown tracks. I just wish it could do the same using its own local database rather than YADB since the actual text in YADB doesn't match my database.
I think the point may be getting missed by some - It isn't that I
can't get back to where I was, it is that it will take a significant effort over a long period of time. I know quite a few people that have had significant losses and most end up starting from scratch without ever saying a word. If only I had the time for that!