James_I
(The truth is out there but not necessarily here)
41
I agree 100%. And I had been posting in a number of feature request threads etc. that I would really like to see Roon have the capability to focus on custom embedded metatags so that I can apply Roon tags as a functional equivalent to how other sophisticated media players interact with the custom embedded metatags.
But those posts didn’t seem to gain any traction - users didn’t seem to be interested – so I figured perhaps use of custom embedded tags isn’t as widespread as I thought, and thus it seemed that I’d instead need to work inside Roon to re-create what I can get out of Foobar2000 from scratch. But that’s a mountain of work. If I do that, I don’t want to lose it.
Reasonable minds may differ on these points, but I’ll bet you’d be wildly surprised at how sophisticated some users’ Foobar2000, MediaMonkey, or JRiver implementations are. Using filters in Columns UI in Foobar2000, I can do a much better job of auto-DJ’ing for myself than Roon does for me right now. I’d like to be able to use that work and it’s just awaiting Roon’s ability to Focus on non-standard tags within files so that I can rebuild those processes inside Roon.
With due respect, I think I could be a lot more confident that I’d be able to find a CD player somewhere if the one I had stopped working than I can that Roon, as a service as much as a permanently functional piece of software, will survive indefinitely. All I’d need to worry about is finding another CD player. Not going to find another piece of software that can read Roon’s database.
Actually, this will solve the vast majority of my concerns, as long as it can export tags in a way that the other media software being mentioned in these posts can use. I just mean multi-value fields delimited by semi-colons, etc. When you do build this export function, I expect that’ll be the way it does and that will be excellent.
I have a custom embedded metatag field called “Best Version?” and I just have to add “yes” or “no” as a value to determine which version is the one I want played. Identifying albums could be similar and might even fit into multiple fields as you suggest - label, code, etc. – and other software could definitely read off of this.
Not everything would work well this well. But if we could save the large majority of our work in some exportable format, or in the alternative, import IN to Roon our existing work and then keep using that process to update Roon, either would work.
Let me also say that I love how alive and engaged this community is. Debates can get a little hot at times, but that speaks volumes about the passion and interest we all feel about this wonderful hobby. So thanks to everyone who has responded to me - doesn’t matter if you agree or disagree with me - I’m sure we would very much enjoy having a beer together while listening to our tunes.
James_I
(The truth is out there but not necessarily here)
42
Ah, Slim, now I see why you think my posts are so crazy! If that is what I meant, you’d be right, I’d be crazy to ask for that.
What I’d like is one of the following:
(1) Roon allows me to Focus on custom embedded metatags that already exist in my media files, and allows me to quickly and easily then apply Roon tags as a functional substitute. Then I can simply keep on grooming my collection within the files as I always do and then batch update within Roon.
(2) Failing #1 (and per my post above, it seemed when I suggested #1 very few were interested), allow me to EXPORT my media grooming work within Roon back out to custom embedded metatags within media files, in a format reasonably workable with how other current media software works with those custom tags. One can get quite sophisticated with Foobar2000, among others, to leverage this. The data just has to be there.
Sounds like the Roon team is working on some of this. When done, we will both be happy
Again, I don’t agree with this. Sure, the experience may not be as rich, but your existing DB is there once established and additions would be limited only by what Roon is able to ingest and make sense of from you tags.
1 Like
James_I
(The truth is out there but not necessarily here)
45
I agree it might still function. But the idea of being tied to a dead-end software no longer being developed (should the worst happen - and I sure hope not) that was created primarily in reliance on services and content that are no longer available is not very attractive. I’d probably want to move on to something else at that point. You’re just in an ugly workaround, and for what reason other than trying to salvage what I’m saying ought to be exportable.
Plus, that assumes a whole lot about Roon even continuing to work. What if Roon is bought by a huge company that doesn’t care much about Roon’s niche community, and they tie its use to a service we don’t want to pay for, and that buyer simply does not allow Roon to function anymore unless it’s used with that service? Roon does check for license rights every time it boots. That buyer could just shut us down.
And that brings up an interesting point - are we sure that Roon would even work if Roon itself ceased to exist? Are we sure that the software would boot and work? I have my doubts.
I assume those with lifetime subscriptions might get something functional in that context but us annual license folks would have no claim to any continuing access to it.
In that scenario, I want to move on to something else, and take my work inside Roon with me!
A lot of whyat if’s here of the glass half empty kind.
What if we all use and promote Roon and make it the ‘Go To’ software that every body wants and needs.
Sure stuff happens, but lets no talk it into existence.
1 Like
James_I
(The truth is out there but not necessarily here)
47
No argument there. But to me that includes it having the import or export functions discussed here.
James_I
(The truth is out there but not necessarily here)
49
Thanks I appreciate pointing us to this information. It’s no guaranty, but it is good that these issues have been discussed. I don’t think that addresses my desire for the features discussed above, but it is good to see that the longevity issue is on the table.
Sheesh, the music equivalent of the best thing since sliced bread comes along and you’d rather sit on the sidelines than enjoy it. There are no guarantees in life. Keep tagging the way you always have and enjoy Roon for what it is as it offers things today. In time what you desire may make its appearance and you can then go nuts making it leverage whatever you have created to that juncture…
6 Likes
James_I
(The truth is out there but not necessarily here)
51
Evan, dude, there is a whole section titled “Feature Requests.” What exactly should we be doing here?[quote=“evand, post:50, topic:24934”]
best thing since sliced bread
[/quote]
Well, it will be, when I can customize Roon playback to the extent I was able to with some of the other media players. That takes work. I just don’t want to lose it. Asking people to invest their time in a proprietary database is a big ask. Although, as mentioned, Focus by existing custom metatags would be just as acceptable as exporting grooming work within Roon - we just need one or the other.
As in any software development there are trade offs for each feature improvement and new request. The investments have to go to the biggest bang for the buck, not break existing usages and benefit the most users.
I think one of the reasons roon is succeeding is that it is aimed at a core of users who want to have the rich information that roon provides but who specifically don’t want to invest hundreds of hours in making their collections more “accurate” to their own versions of accuracy.
Having worked in a global software supplier for many years and seeing the balancing act that is required to keep some of the users happy some of the time never mind the edge users that are being expressed in this thread. I am amazed at how well roon are doing meeting the requirements given the youth of the core software.
All software houses have design guides and tenets of faith. One of those in roon is obviously to have a clean uncluttered interface and I’m sure roon are gathering use statistics so the most used commands are surfaced and the least buried in sub menus. So the meta data analysers and tweakers are, in my opinion, going to be serviced as well as they can be within a mainstream context but are never going to have a tweakers paradise.
( I haven’t used grooming as it has other connotations that I would like to avoid )
1 Like
James_I
(The truth is out there but not necessarily here)
53
I appreciate your perspective on this. I’ve represented many software companies but not been involved heavily in product development or prioritizing development queues.
Regarding your quote above, I really cannot argue, but there sure are plenty of tools within Roon already that indicate that Roon is also trying to please those of us who deeply curate our collections as much as possible. My point was just that these tools are great but if you spend a lot of time using them, it’s all within a closed system. Lots of risk in that.
That is probably best handled outside of this thread. If there are examples where our auto-identification is getting it wrong, they can be fixed/tweaked. If it’s just editorial differences of opinion…that’s a different thing
The “prefer file tags” seem to work for the standard tags but not for the custom tags like WORK, PART etc.
We have work in the pipeline to add prefer-file-tags for work/part structure.
The best place to fix localization issues at the composer or work level is in composer or composition entities, not track-level data in file tags.
The tracks should reference their composers/credits/etc using globally unique identifiers–not human names which can be non-unique or spelled (or localized!) different ways.
Data about those composer/composition entities should live in one place–not denormalized across dozens or thousands of tracks which might have data in disagreement. The choice about how to translate names for display should happen in one place too–tied to those entities.
To me, it is fundamentally disgusting that changing the spelling of a person’s name could affect the grouping of media attached to that person. I can’t imagine working with or living in such a system
And the same unique identifiers that describe entities in your collection should be relatable to unique identifiers in streaming content–so that your library can be linked/blended with content outside of it freely. Whether or not you’re a user of streaming services, they are slowly taking over, and our architecture must work gracefully in that future. Grooming a large library is something a few % of our users might be willing to do, but grooming all of the streaming content on earth is something 0% of our users are willing to do.
I understand that you don’t think the product is there yet, that you are comfortable doing a lot of work by hand, and that you have a huge sunk cost invested in a way of doing things–but that doesn’t necessarily mean that the solution to these problems is to make Roon more like the old way.
What we should do is continue to interoperate better, and push forward. I want people to have an experience like your groomed collection with zero effort, and I want you to greatly reduce or eliminate the amount of grooming that you have to do.
We have access to localized composer names from at least one source (I think work names too, but not 100% on that)–we just haven’t integrated it into the product yet.
We also have an ambitious plan for user-generated-content + globally collaborative metadata editing. It’s probably a year from being in front of users, but the first steps of the work have been underway since right after 1.3 went out the door. So even when data like this doesn’t exist, it could be created by our users provided people are sufficiently motivated.
I’ve had a few discussions with people about this, too, an they all fizzle when I ask: what are the specific use cases that you want to accomplish with custom metadata tags?
We need to look at what people are doing so that we can decide which of those deserve to be first-class features and which should remain via some generic/custom thing.
The problem with the generic/custom approach is that the experience can never be very rich or much better than a spreadsheet. If we make the generic mechanism before distilling the right use cases into first-class product design, most people will never have access to those use cases–simply because doing anything via a custom tag is too complex for most people.
In the end, only a very small % of our users ever touch editing functionality, groom metadata, or do anything like this. The great majority comes, accepts the automatic behavior, occasionally groups alternate versions, and that’s it. This is very important context to keep in mind–we are very happy to keep developing metadata/editing functionality, but it’s very important that when doing so, we do it in a way that brings those benefits to everyone with reduced effort, because the high-level strategy here is all about automation.
There are a couple of other sticky points, too: Custom tags are fundamentally a track-level concept, since they are tied to files–but to make them sensible in the context of this product, they need to not just be track-level. And how does this concept extend to streaming content in a reasonable way that provides parity in functionality/outcome?
I could absolutely be convinced that this is a good idea, but it will take more effort than asking for it to convince me–we need to actually understand the use cases in detail and take some time to think about them and solve some of those sticky points that I mentioned.
Happy to have a discussion about that (hopefully not in this thread)…but it’s not going to be an easy discussion because there is some difficult stuff to hash out in blending that idea with this product.
Those software lack basic support for representing entities orthogonally (i.e. artists and compositions by unique id instead of name), so it is hard to think of them as sophisticated …more like verbose. They offer a lot of unrestricted power within the bounds of some pretty catastrophic limitations.
The counterpoint to all of that unrestricted power is that it’s very difficult to evolve those systems past the local maxima that they’ve already reached. You can’t take a world where users have a ton of effort invested in such a simplistic data model and evolve it into something that’s properly relational/orthogonal without pain, lost work, and gnashing of teeth.
I’m sure you’ve noticed this by now–we are conservative with releasing metadata/editing functionality. This is because we are terrified of reaching a point where evolving the system means throwing away our users’ effort. We see how other software has fallen into this trap by taking the “easy way out” with file tags, and we are determined not to repeat their mistakes. When things are in the realm of automatic grooming, we can change/improve/evolve freely. Once we open up a model to editing within Roon, it’s “frozen” since people will have invested time in that model. We do not want to get stuck with bad decisions made hastily because in this domain, it is very expensive to backtrack.
From my perspective, getting it right requires nailing down user generated content + collaborative editing. That’s the only approach that can scale to streaming+local for all content on earth–which is what we have to do to make sense as a product in the long term.
The last product we worked on (Sooloos) also had a proprietary database. It was reverse engineered by the community several years ago. Nothing fundamentally impossible about doing this assuming the motivation exists.
The real problem is–the way we store your data doesn’t map very well at all onto what other software does, so it’s not totally clear what you’d do with it.
For instance, if you change the spelling of Tchaikovsky to your preferred spelling, Roon does nothing with that information at the track level–we record a small edit somewhere saying “edit the name of artist f4b5b2b4-1faa-4c84-85cd-9ae7f578f6d0 to My_Favorite_Spelling_Of_Tchaikovsky”.
So while we can export that spelling to tags in a lossy fashion (lossy because it is shedding the globally unique identifier for Tchaikovsky in the process), but it would take a lot of effort for other software that is not Roon to interpret and use that data effectively.
Try switching off the internet and using Roon. All the links and bios are there; if you have a large collection, and don’t use Tidal extensively then you could happily use Roon for years on a desert island so to speak . Adding new stuff would become an issue of course; as all subsequent additions would remain “unidentified”, but this doesn’t detract from the fact that it is entirely usable without internet after initial scanning has been done.
It’s pretty cool, especially if you have a large collection already and additions are not so high on the priority list, and anyhow, how long does anyone go without internet these days, really?
It’s making a lot more sense. I am slowly getting into the mindset of using the automation available to me rather than laboriously retagging stuff. It’s a HUGE boon.
It takes time for us some of us luddites to let go of the “old ways” and your comments really help in this regard.
I think the “Identify Album” feature is thus one of the most important features within Roon and is the heart of your ethos of minimising manual input.
I would ask you to have a look at the way this is implemented as, currently I have around 700 of 8000 albums which remain unidentified and, for the ones I have been checking and trying to manually identify using the Edit album feature, it’s mainly due to slight discrepancies in track listings and timings. For the most part, the tagging in the files is correct in terms of tracks names and such, so it would be GREAT to have a feature in the manual identification procedure which is "Ignore Tracks"or something, That way, we can manually identify albums with credits, album art and bios, etc. Even we could then use the focus aspect to highlight all unidentified albums and manually identify them in one fell swoop. I guess then out of 8000 albums, only a handful will truly remain completely unidentified as real oddballs. Can even put in a Focus criteria as “Manually Identified” to differentiate to those albums which are Auto-Identified.
Food for thought. I think Ill post this in the feature request section also
This exactly what I need. In my case I could then import my JRiver track ratings into Roon tags. These are the essence of my collection and I use them in most of my smart playlists every day. In the early days I had a CD Collection plus Excel tagging. Then I digitalized and consolidated iTunes, then I migrated everything to MediaMonkey and then - 5 years ago - to JRiver. If I cannot leverage and grow my collection within Roon I will never use it seriously although I own a lifetime licence. Allmusic.com, Tidal etc. can be used anyway seperately (Spotify must be) in order to discover the music we love.
