Establish Primacy of User's File Tag Edits

Here’s a maddening sequence that happens all too often:

  • You are cruising through your albums and notice that it doesn’t display one or more compositions correctly, or it isn’t linking with any similar performances. And the album is recognized by Roon. (Or it may not be. Either way.)
  • You manually search Allmusic for the “correct” name and discover that the phrase “…for piano” has been omitted from the track title. You know from prior experience that this can make all the difference between success and failure for IDing purposes.
  • While you could make Roon edits, you decide to use your tagger because of its efficiency. Plus, tagged edits, unlike Roon edits, are visible to you after the fact.
  • You decide to make use of Roon’s own WORK and PART tag here (after all, what could be better?). This particular album was ripped some time ago, so they weren’t part of your ripping workflow.
  • You carefully enter identical, canonical names (copied from AllMusic) for each track’s WORK tag, and enter numbered movement names into the PART tags. This is not a huge time suck at this point; maybe 2-3 minutes if you know what you’re doing.
  • You save changes, wait, and…NOTHING. Roon has either not reacted, or has rejected the changes. You can’t know which. What irks at this point is not whether the ID has been made. You wonder, “why on earth is Roon doing this?”
  • Now the time suck begins. You first tell Roon to use File’s multi-part grouping, although that is already a global setting. Nothing. You then tell Roon to RE-scan Album (although it seems like any tag change should automatically trigger that.) Nothing. RE-Identify, RE-Analyze. Nothing, nothing. Select just the subject tracks, and try the Three REs that way. Nothing. Nothing. Nothing. “Why are you doing these things?” I ask myself. “Well, it can’t hurt and may help. Besides, there’s no troubleshooting procedures in Roon, so I have to be in Unguided Discovery mode”
  • Based upon prior episodes, you’ve learned some other tricks. You un-ID the album, then re-identify it. You choose a different album version perhaps, or you might just leave it un-IDed. You Revert User Edits made in Roon so that nothing untoward is interfering with the ID process. Ultimately, you might go with “the Nuclear option”: make a local copy of the album; delete the album; clear up the library; then re-import the album.
  • By this time, fellow users chime in (with quite good hearts, IMO) trying to help this desperate person. Does the album have a Category number? “It won’t accept edits if there’s a recognized Category number,” s/he says. Anyway, you try all such things to no avail. By this time, 30 minutes of your life has been lost forever. “Your own fault,” I tell myself, I’m That Guy.

So, my Bug Fix requests are these:

  • Make the content of WORK and related PART tags an automatic #1 priority for IDing and displaying any composition. (Of course, IF they’re populated). WORK should even be used on one-movement WORKS for ID and display. After all they are WORKS too.
  • Decide what, if anything, is required in PART for a single-movement Composition (I vote “nothing”, but if present, then concatenate it with WORK for IDing and display purposes).
  • Whenever WORK or TAG edits are made, reflect those changes immediately without exception. If Roon anticipates disastrous results, warn as necessary, but still make changes if the user insists. “It is Roon’s intent to honor all user edits”, said one Roon employee. [I would extend the request to include any file tag edits, but these two are particularly critical.]
  • Roon should choose the correct RE- and perform it after a user edit of tags.
  • Collapse the three REs into one command called “Fix”. If Roon can programmatically avoid unnecessary work or analysis, please do so.
  • Lose the language “Roon has queued your [album] for another round of analysis.” Too vague. Missing time window, no notice of when completed. What queue? A throwaway phrase. Don’t put me in a queue.
  • IF there are good and proper reasons why Roon should ignore user tag edits, definitively state these in an FAQ, KB, or manual. This aids users in deciding to spend the time making such edits. And please do not think that those reasons have been revealed simply because of one comment made in one community conversation thread.
  • Create a programmatic alternative for “the Nuclear option” mentioned above. If that’s a possible or effective fix, make it a selectable option.

All of this begs the larger question of fixing Metadata generally. I thought it more useful to suggest concrete changes that, IMO, could and should be done.

There may be pushback to these changes saying these emphasize editing tags too much, or “that’s Sooo yesterday.” Well, perhaps so. But Roon hasn’t yet achieved the magical, mystical stage where everything just works. Not in metadata, not by a significant margin. So in the meantime, we should have coping mechanisms that are more efficient and definitive than at present.