without being able to compare to the other songs, I won't easily be able to do the rest of the steps.
It would be cool to be able to compare values between files, but that would add a whole order of complexity to designing how data is to be collected and presented. Just taking advantage of relational fields requires careful planning. It pays to consider carefully the exact nature of the data available, how it's going to be obtained, it's integrity maintained, and how it's going to be used.
I'm not familiar with the sources you're using, so let me make up my own example to illustrate. Let's say Source1 assigns moods (list items) to albums. Since there's one value per
album, it would make sense (mainly for data integrity) to store this in an album-relational field [a.Moods.1]. Now let's say Source2 assigns moods (also list items) to
tracks. Those aren't related to albums, and maybe the data won't even be retrieved by album, so there's no point in trying to associate these values with albums. It's best put in a regular non-relational field [t.Moods.2].
So now I have two similar sets of data, each in their own fields. This way, I know exactly what they are and will find it easier to keep them up-to-date and maintain their integrity. This, however, is probably not how I want to use them. That's okay—they're just "raw" data—I'll use expressions to manipulate and present them any way I please. Exactly what that is depends on the circumstances and my preferences. For example, if the data from the two sources is very similar and two sources are used simply because neither are complete, an expression might use one source just to fill gaps in the second. Or they could be combined together into one list without regard to the source. Although it can't be done automatically, [t.Moods.2] could be combined by album and used to fill [a.Moods] in cases where there is no data from Source1.
In the end, the objective may be to fill [Moods]—an expression field that in some way combines the data in the other fields. And this may be the only field used or displayed. Or expressions might be used wherever necessary to display exactly what's required for a column, caption, info panel, etc.
This can also be a good approach for the situation where one source has data for most of your files, but not all. Rather than "filling the holes" manually, it might make sense to keep the data from the source and that which you enter manually in separate fields. Doing so allows you to update from the source without fear of losing the manually-entered data (should it remain "better"). And the two can easily be combined with an expression.