Your ramblings are enough to go on. Unfortunately there are so many things working at cross purposes here 🙁

We can forget about Track databases as they work as intended ... pretty much because one db row is one track.

Album databases were initially created as a means of representing album groupings. Unfortunately the structure and all the associated code uses the fact that each row of the db contains a single folder.

Yate Track/Album IDs were created to act as a file system independent means of locating an item (track or album) in a database. This would mean that relocated items could be found regardless of their retained folder in the databases. For example I change an album name, relocate the album, and the db could update to fix the new folder names. I use this all the time. The M3U suite uses Yate Track IDs to update m3u files after tracks are moved.

The Album IDs also serve to differentiate two occurrences of the same album, possibly with identical metadata. For example, original and possibly remastered versions or multiple versions within different audio file types.

When running the Create Database Utility, the batch processor is used. The batch processor only sees a single folder at a time so each folder gets unique Yate Album Ids and a separate row in an Album database. This was certainly not the intention. Each album should have a single Yate Album ID.

When you update (add) via the UI, all tracks are available and a single Yate Album ID is used as a grouping causing a single row in the database to be created. Unfortunately only a single folder is available on the row ... which is also incorrect.

Possible remedies include looking to see if content is contained in a Disc folder. However I've Seen Disc #, Disk # and localized variants. I could also change the (UI) code to always add a single row for each folder but then the Yate Album IDs would have to be differentiated.

I have to think on this a while but the best solution might simply be to document that Album databases require one album/folder/Album ID per row in order to work correctly. This means a flat file structure without the use of Disc subfolders. I'm loathe to document away a design flaw but I can't think of a solution which solves all scenarios. As I said, I have to think about it.

In the meantime, I'll productize a get rid of disc folders action. I've done many over the years. Both Audirvana and Roon and I assume other players, really work better when an entire album is in a single folder. I've supplied the actions to users who had issues other than the Album database ones.

I'm open to ideas.

For others reading this who didn't see corresponding emails.

I’m toying with the following fix.

When Yate Album IDs are created they must be unique per folder. When updating (actually adding rows) in the UI, a separate row must be created for each folder.

I'm going to test the above. It should at least make things consistent and will not affect anyone who has a one disc/one folder structure.