VOCALS made the cut because we did a data analysis of a few million real world files and found that it was both common, consistently used. BASS and DRUMS are significantly less common.
In a system like file tagging that lacks well-established standards, all we can do is make e a judgment call for each case and a decision about where to draw the line.
There is nothing that you can put in file tags that will cause a “Bass” credit to appear in the UI today.
In the future, you’ll be able to do that via Roon’s editing features.
It’s possible that we will make our file tag comprehension richer over time, and that you will eventually be possible to do this purely with file tags. That’s always a case by case thing. Covering BASS and DRUMS means covering hundreds or thousands of other roles (KALIMBA, TIMPANI, …) coming from tags, and making judgements about how to handle them, and map them to Roon’s credit roles, one by one. Trying to do a full-fidelity import of track tags might not be as good an application of our efforts as investing in our metadata system, or improving editing capabilities.
Well the linked page does not reference VOCALS being accepted, and yet ROON does grab that data and show it, so if it is simply ROON being able to ‘recognise’ the VOCALS data, why on earth would BASS, GUITAR, DRUMS, KEYBOARDS etc not be a recognisable metatag as well?
To be clear, I said pages like that one, and did not mean to imply that we have implemented the list on that page directly.
I also acknowledged that there are other pieces of evidence (like popularity and consistency of usage) that we use to decide what to support.
OK Brian, I now full understand your (ROONs) stance on metadata display.
I can not however agree, that DRUMS, GUITAR and or BASS are not common enough to be included as there is not a rock or pop song on the planet that does not include those instruments. (OK, there are a few exceptions of course)
I look forward to the ability to add data in the future, thanks for your patience.
I would appreciate if an option to use alternate delimiters, in particular “,”, would be added.
I have a library of about 96.442 titles in about 6.698 albums with about 19.164 artists (according the counting done by Logitech Media Server (LMS)), and used normally “,” as delimiter and only rarely “;” as delimiter, as both is fine with LMS. In LMS you can define the delimiter which can be used. Huge time investments were necessary, so that a re-editing of the metadata to use always “;” is no realistic option.
[quote=“Otto_Wilhelm, post:24, topic:8289”]
Huge time investments were necessary, so that a re-editing of the metadata to use always “;” is no realistic option.
[/quote]@Otto_Wilhelm if you’re prepared to do a little work in a database this is easily solved. I can point you to a python script that’ll read all tags for all files and write a record for each file to a table. A simple SQLite replace statement to replace all ‘,’ with ‘;’ for the fields you’re interested in and you’re sorted. The same script will write the db changes back to your files. I’ve run it against over 330k files without glitch - it was written by the developer of puddletag and leverages the puddletag code base…which was first released in 2008.
@evand: Thank you for your offer. Since I am not familiar with SQLite and its language I am unsure whether this is indeed a realistic option for me. Or can this also be done by a novice without substantial risk that something could go wrong? Is a guidance available?
@Geoff_Coupe: I just asked for the option to define additional delimiters. This would work good for me since I do not use the comma in my tags to differentiate between “last name and " first name”, since I always entered artist, album artist, composer and conductor names as “first name” “last name” without any delimiter there between.
@Otto_Wilhelm, it’s simple to do and I’m happy to guide you through it via pm. One proviso… You must be running Linux or OSX as the script uses UNIX style file paths.
Thanks again. My FLAC files are hosted under Windows Server 2012 R2 Essentials on a server machine, nearly 2 TB. Would this work also over the network from a Mac, when a corresponding share with rights to write is defined?
The same music is also present in AAC format (for IPod and the like) and in ALAC format (currently no particular purpose besides as a kind of backup), which have (or should have) the same meta data. Would this approach also work with these formats?
The approach will work for any file formats supported by puddletag. You could run it from the Mac and point it to a network share. To build the db table it needs read access, to write any db changes back to the underlying files the share must be writeable.
Remember that for FLAC files the correct answer is to write multiple entries of a tag rather than to use a delimiter. Puddletag sees ‘\’ as a delimiter internally so if you replaced the current delimiter with ‘\’ instead of ‘;’ the python script will write multiple entries to flac files for you. If you just use ‘;’ or some other delimiter it’ll write the field with whatever delimiter you use.
[quote=“evand, post:31, topic:8289, full:true”]
Remember that for FLAC files the correct answer is to write multiple entries of a tag rather than to use a delimiter. [/quote]
Is that so? Another tiny piece of the jigsaw slots into place. I just wish that all the pieces were gathered together in one place and documented into a “how-to and best practices for audio metadata”…
OK it is now some nine months later, are we any closer to being able to add our own metadata?
For those of us with ‘real world collections’ that include music that is not at all, or incompletely listed on some third party metadata supplier that feeds Roon’s databases, this is a must have option and WAS promised to be forthcoming…still waiting, so an update would be great!
Metadata upgrade is one of the main features of 1.3. There is likely to be one more release for 1.2, which will start preparing our systems for 1.3 so that when it goes live we can enjoy the new features from day 1. As befits a new 1.x release number the modifications to metadata handling are substantial and will bring Classical in particular much closer to where the devs want it to be.
Plenty of metadata editing programs are available. You need not rely upon Roon for that function. Rather, you [Moderated] can edit/curate your metadata to your satisfaction before the files even enter the Roon ecosystem.
Andrew, [Moderated] that’s not the problem here. I DO EDIT ALL MY METADATA PRIOR TO ADDING TO ROON. The problem is ROON not acknowledging it.
Roon 1.3 is going to allow us to edit and add metadata such as who played bass, drums etc, because as it stands right now it ignores MOST of that type of data in the files.
I am not aware of Roon not acknowledging user edited/supplied metadata. I have several Roon unidentified CDs that do not appear in any third party metadata databases, and Roon had no trouble accepting my user supplied metadata that I entered with a CD ripper or a metadata editor. In more numerous instances, I have Roon identified albums for which I prefer my metadata to Roon’s metadata. No problem. One or two button clicks replace Roon’s aggregated metadata with my own metadata.
So, I do not experience your problem. But, while conscientious, I am not [Moderated] into 100 percent accuracy and inclusion of metadata. [Moderated] Roon should not try to be everything to everyone. [Moderated].
As for Roon 1.3 adding a metadata editor, I see two problems potentially arising…
One, if Roon allows editing of metadata and – per standard Roon practice – stores those user edits only in the album entries in the Roon core database, then all of that metadata curation work is lost should you ever use your files outside of Roon. Upon discovering this, I guarantee that some current or former Roon users would be up in arms.
Alternatively, if Roon allows direct editing of metadata on the files themselves, then Roon has acquired permission to modify your files. And that opens up a whole new can of worms, rife with opportunity for user error or software malfunction. Personally, I am most happy that Roon takes a hands off, read only approach to my files. Do no harm.
