Where is album version information retrieved from?

I have my file tags arranged so that Roon imports most of the information I want to see. Titles, artists, dates, release country, catalog number, label, genres etc are all being reliably retrieved from my files. The only thing I am having trouble with is “Version”. It is always blank, and I have to fill it in manually every time. The option to “prefer file data” is there. But nothing ever comes through from the file. Anyone know where Roon looks for this information and how it should be structured. Is there a tag, or is there something else it looks for?

Cheers
Paul

Can you give an example of what you’ve captured as Version?

Hope this helps… If I want the version label on the cover graphic to say “2011 CD remaster” or perhaps “2015 HDTracks”, or “1963 mono vinyl” for example, is there a tag where I could put this information in my FLAC files, which would then be read by Roon on import. Or is it a case of re-structuring the file name? As mentioned, this type of information is the only thing that I have to manually type in Roon for each album import.

If you put in brackets in the album title it’s then shown on the face of the album cover. I’m not sure if there’s another metadata field that Roon would reference in this regard.

Tried it just now. It works. :slight_smile: Thanks for your help. I would have preferred it if there was a specific FLAC tag mapped to the version, but this will do.

Cheers
Paul

@brian @evand @paulgh fyi this is broken in one respect. If all you want is the date, and you put it in brackets in the album field, like this: [1985] it will not show up. You have to put some non-numeric punctuation in to make the date appear, like this: [1985.] Anything non-numeric will work, with the period being the least visually obtrusive. This is obviously a bug.

Also, you can use [] or {}, which is nice for sorting purposes. Unfortuantely, Roon also shows stuff in (), which has some really unfortunate side-effects when the actual album title already uses parens, which is fairly common. This may be a bug, or it may be a design choice, in which case I’ll start another thread sometime and endeavor to show why it’s a bad design choice.

Just figured I’d use this thread to bring these things to Brian’s attention…

The exclusion of dates is deliberate: Roon already has fields for release date, recording date, original release date, catalog number, and format. Automatically populating the version field with “24/96” or “1992” or “FLAC” would duplicate information that is already managed and displayed in a first class fashion.

There’s nothing stopping you from putting whatever you like in that field using Roon’s editing features, but auto-importing indiscriminately would create clutter for the majority of people (remember: most people do not edit at all and will never fix it manually. The default behavior must be clean and sane).

Recognizing content in () is by design, too. It does pick up useful information sometimes. This will be a difficult thing to disable if people have come to depend on it, but we could be convinced if the problems it is causing are doing more harm than good overall. This is also something we could consider making into a setting.

1 Like

I had looked at it thinking "well, there’s never a [] in an official album title, so what harm can it cause? But I totally forgot how often ripping software adds descriptive info in [] at the end of album titles, and, yep – you’re right, most people don’t edit those. So an ugly disaster would ensue if you didn’t throttle it back. Makes sense.

And yes, Roon does a nice job of displaying the info you list after you’ve navigated to the album in question.

However, many pop-rock enthusiasts have multiple releases of certain albums. For instance I’ve got four versions of Jimi Hendrix’s debut Are You Experienced?

When I go to Hendrix, click on him to see his albums, and then go to choose which version I want to listen to, here’s what I see (if I leave the album title in its official form, un-amended):

Even when grouped together, there’s no way (without changing folder names) to differentiate between them:

Wasn’t trying to suggest Roon’s data display was less than stellar, just pointing out an area which might be able to benefit from some tweaking.

Anyway, adding a period after the date works well enough, and it’s less obtrusive than adding [1993-MCA] or similar.

Click on any one of the Albums listed above

Then click on the Edit Arrow over on the right hand side of the top half of the screen

Click on the Edit Fields tab

Scroll down to the Version option

Enter ANY text that allows you to distinguish the Version of that album

This text will now be displayed on both the Album Browse and Detail screens…easily allowing you select whatever version you want to play

Yes – I’ve used that sparingly. A good solution when you only have a few albums that need the differentiation. When you’ve got a couple hundred or so, it’s certainly easier to leverage info in the tags though. Thanks for the reminder.

One of the things we shied away from in 1.1 was building a control panel of “library settings” that let you tweak/tune this stuff. We did one screen–the genre mappings editor–and we made everything else (file tag genres vs roon genres display) a display setting.

In part, it was because we really don’t like the idea of settings that take a long time to apply. A lot of this stuff requires going back to the tags in the files to re-evaluate what that data means globally, then distributing the results of that re-evaulation to hundreds of thousands of impacted records in the database. This is roughly equivalent to the work done during “updating databases due to software update”–which can take several minutes or more, depending on library size.

So the settings that we did expose in 1.1 were settings that could be applied instantly–so even though they have global effect, they can be flipped off as quickly as you flipped them on with no ill effect and a very smooth user experience.

We have become less afraid of building features like this over time. Yeah, it’s annoying that clicking “save” on the library settings screen will take a few minutes, but that’s probably an inconvenience that will be tolerated in return for more fine-grained control. And since these settings are largely there for power users, the undesirable UX is something that most people won’t be faced with anyways.

I think we are going to revisit that “library settings” idea again and make it easier to make high-level choices about how files are handled.

Some of this will just be about changing the global defaults for existing features (genre display settings, prefer-local-metadata, import date handling preferences).

Other things will likely be small ways to satisfy common requests. For example, some people find AllMusic’s editorial data (Rating, Review, and/or Picks) offensive. I’d rather say “you can turn it off over there” than have to have the argument every single time about why our default behavior is sane. We effectively did this for genres in 1.1, but we could go further with the idea.

We also, sorely, need to support a mechanism for merging artists. This is a complex problem–because in Roon, references to artists can arise automatically, and are extremely numerous and spread out in all kinds of places you might not think of immediately. In iTunes, you can “rename” an artist by editing all of the file tags that name that artist. That doesn’t really work in Roon, since updated metadata can arrive on-the-fly from our servers at any time, and all it takes is one reference to the artist you “merged” to bring it back from the dead. We have a solution mostly worked out, but it took a lot of thought to get there.

We’ve had requests to support custom delimiters in file tags (despite the horror show that can result from using “,”, a character that can show up legitimately within artist names like “Crosby, Stills, and Nash”, some people really want to have Roon split their ARTIST tags on “,”). This could fit into the same set of preferences–it requires re-parsing all of the tags in all of the files to re-split them, so it takes some time, but there’s nothing technically difficult about splitting on a different character once you have the infrastructure in place to re-evaluate all of the tags + rebuild the library.

More towards your issue: another thing that we did in 1.1: populating many more fields in our data model based on file tags. We more than doubled the set of supported tags with that release, but we didn’t cross the line and start inventing tagging conventions on our own. I think it’s time to cross that line.

For example, for your Album Version situation, we could support an ALBUMVERSION tag that, when present, overrides all of the path-based logic and just directly populates that field.

Likewise, there are some people who struggle with getting import dates the way they want them to be. They could use an IMPORTDATE tag and manage import dates externally to Roon if they don’t like the built-in options.

Others have requested a file tag that just turns off automatic metadata handling for some tracks. Or ways to represent classical work/part structure, or album reviews, or …

File tags are an open mechanism–accessible to everyone, and there are good existing tools for manipulating them, scripting those manipulations, etc. We shouldn’t stand in between people and their ability to do that. And it seems like we don’t have to–we can expose a lot more control/power without impacting the out-of-box “Roon cleans up my messy pile of files!” experience for casual users at all. It will never rise to the expressive power of our data model, but for many, many use cases–particularly for power users–it is a very sane approach.

And of course, there are people who don’t like the idea of burying their data inside of a proprietary database, or who worry about data corruption, or don’t want to depend on our long-term viability as a business. Other people just have pre-existing workflows surrounding file tags that they don’t want to re-invent. They all have reasons to mostly-or-completely avoid Roon’s in-app editing features.

This mindset will also facilitate easier migration of data from other systems. I have 6 years of import dates buried in a Sooloos database that still aren’t in Roon. A lot of people have similar stuff with iTunes, or in other places. It’s a lot easier for us to support reading that data from tags, document the details, and let people handle getting the data from where it is into the tags, than it is to support each of those previous systems one by one. It means that anyone sufficiently motivated would be able to solve their own problems.

I know things have been quiet on the metadata/library management front for a while. It’s not because we aren’t thinking about it–it’s because we’re a small team and we can only focus on so many things at a time. Right now, we are deep into planning what the next major release(s) are going to look like, so a lot of this stuff is being woken up discussed again…

(@evand, @VirusKiller, @ncpl, @ludwig)

5 Likes

I just can’t :heart: this post enough times! :grinning:

I would be happy to see this. Roon is not a good choice for bulk editing of metadata. It was designed to relieve your of this “chore” (and that’s fine), but becomes very inefficient when you try to edit this information yourself. I much prefer to use a dedicated tag editor and have Roon read the information.

Regarding my original question, I am happy with the current solution (square brackets in the album title) now that I know about it, and it is something that I can fix using tag editors. It’s not something that I want to edit in Roon itself, as it is very slow and inefficient to do it for many albums. Good support for file tags is enough for me, so I can do the editing elsewhere and import the results.

The current solution for either “preferring file data” or “preferring Roon data” is absolutely fine with me and could be extended to other things. If you have a modest library of 2,000 albums and Roon nails it 95% of the time, you are still left with 100 albums that you might want to edit. Much better to do that in a tag editor than Roon.

Also, the recent Roon-side issue of disappearing genres makes me realise how important it is to have as much information stored in the files as possible. If I make the effort to “groom” my library, I want that information available should I ever decide to leave Roon (or if Roon leaves me).

Cheers
Paul

Absolutely. Heartily agree with this. Don’t let Roon become a “Jack of all trades - master of none”.

I agree with this, albeit believe it should become possible within Roon to make wholesale changes to all records meeting specified criteria e.g. add Guitar Virtuoso genre tag to all albums where main artist is any of Joe Satriani, Steve Vai, Neal Schon etc.

[quote=“brian, post:11, topic:11206”]
This mindset will also facilitate easier migration of data from other systems. I have 6 years of import dates buried in a Sooloos database that still aren’t in Roon.
[/quote]+1 for me … and I know many, many, others in the same boat.

There also needs to be an easy way to correct metadata errors in Rovi.

For example, for the Mercury Living Presence Colllectors Edition, Vol. 2, Rovi mislabels discs 42 and 43, so the album is listed as “Unidentified”. I had to manually change the numbering of these discs (even though this numbering is wrong!!) to match Rovi’s data and for the album to be identified.

I would love to bring in metadata that I created in other programs (musichi). This is especially helpful in creating classical playlists.

Hi

I would like to vote for making into an option picking up the stuff in ( ) as the version information.

Prior to moving to Roon I had noticed that I seemed to have a lot of albums
that had ( ) in their titles so I had been putting version information in [ ].

This is fine most of the time in Roon, as it picks up the [ ] stuff as version information,
but of course when the album title includes stuff in ( ) it’s not fine …

Mike

Yup, makes sense to allow more control here.

@brian Don’t disable (). I noticed Roon uses that so I have done so. Maybe there is a way to override the default use of (). Disabling it would be a mistake.