The way we manage subtrack metadata is decidedly suboptimal. We essentially take the entire CD's metadata, duplicate it for each track, and remove all other tracks' TrackMetadata. It works, and was a semi-deliberate decision to simplify {de}serialization. But, it makes the saved databases far more enormous than is reasonable. Even a small library (a few thousand tracks) now takes about a minute to load.
Let's rework this something like this:
- A single Metadata object is created for the whole multiple-track rip.
- The individual tracks know their index, and keep a reference to the Metadata in 1. Then they just refer to it with their track number to get all their metadata info.
There will be wrinkles in getting this to {de}serialize correctly. E.g., we don't currently have a way to handle references in the XML database schema. It might even be a crisatunity where we could look into having a real database backend again, with all their fun FOREIGN KEYS and such.
Also, decide once and for all if "subtrack" is the word we really should be using for the multiple tracks in a DAO rip.
The way we manage subtrack metadata is decidedly suboptimal. We essentially take the entire CD's metadata, duplicate it for each track, and remove all other tracks' TrackMetadata. It works, and was a semi-deliberate decision to simplify {de}serialization. But, it makes the saved databases far more enormous than is reasonable. Even a small library (a few thousand tracks) now takes about a minute to load.
Let's rework this something like this:
There will be wrinkles in getting this to {de}serialize correctly. E.g., we don't currently have a way to handle references in the XML database schema. It might even be a crisatunity where we could look into having a real database backend again, with all their fun FOREIGN KEYS and such.
Also, decide once and for all if "subtrack" is the word we really should be using for the multiple tracks in a DAO rip.