Not sure what your problem is with this,
You seem to be unable to break the concept of the album.
FIle Tags are defined at track level. You are able to embed different artwork in each track of an ‘album’,
If you want to embrace the ‘album’ concept you can embed the same ‘album’ artwork in each track.
I don’t play ‘albums’, I play playlists of various tracks from around my collection. I’d like the associated artwork displayed for each track.
If you want to play albums and display album art, great.
But why not also allow for other preferences. Particularly as people seem to be moving away from albums to tracks and playlists. Most of the young people I know are certainly going in that direction.
But why not also offer the alternative of individual track art.
This may be a Roon database issue. For a fairly typical library, a Roon database already runs several GBs. If Roon were to extract embedded art on a track by track basis, that very well could balloon the database to an unwieldy size, thus requiring even higher spec hardware to run Roon.
I agree with this. Just because Roon’s model depends on metadata from other providers (although both discogs and musicbrainz provide individual album art for some box sets that Roon doesn’t pick up) doesn’t mean Roon can’t use what we have in our files – individual album art for each album in a box set. Model purity seems to be a silly reason not to include this – a model should accomodate to the needs of the users.
You’re already accessing the file to get the audio data. Would it be that difficult to get the embedded artwork at the same time if the use file flag was set.
It dosn’t seem like a insurmountable problem to me.
Uh, no. Roon is not apt to change away from its database paradigm. That is one of its foundations.
If you really want a player that pulls artwork and metadata from the file on the fly, you probably ought not to use Roon. Go with a typical file/folder based player instead.
I’m not suggesting it changes it database paradigm.
However it’s going to slowly die a death if it doesn’t adapt to changing requirements.
The current database model cannot be set in stone.
And i’m not sure how pulling artwork from the file on the fly would be a problem.
I imagine it works something like this.
The app wants to play a file. It currently looks in the database to find the location of the artwork, which is either embedded in the database, or contains the location of an image file on the disk. It reads the image data and displays it.
So just add an extra level in the database for the image - get from location or get from file. So it either loads the image from the location of the saved image, or gets the image from the music file,
That doesn’t damage the database paradigm.
“f you really want a player that pulls artwork and metadata from the file on the fly, you probably ought not to use Roon.”
No, it is not condescension. It is good advice. Life is not Burger King. In many cases, you cannot have it your way. And Roon may be one of those cases. If so, use something else, or write your own software.
I think you exaggerate a bit. This has nothing to do with database. The request is to display information that is in the file. This is the same as to play the music that is in the file. The Roon metadata is an additional offer that we appreciate, but Roon can or could reproduce what the user feeds in. It does so with the music data why not with the visuals? Specifically now that lyrics etc. are streamed to output devices. Of course Roon could always play an mp3 version of your music to keep the database leaner???
I happen to have more faith in the Roon software developers that you do. I believe they are more interested in making a good product that meets the needs of their users. All their users.
That is possible. Roon’s objection to incorporating individual track embedded artwork may have much or little to do with Roon database size. This is informed conjecture on my part.
But what you post below demonstrates a poor understanding of how Roon fundamentally works.
Yes, Roon plays music from your files. But as far as on demand access from your files goes, that is about it. Metadata and artwork from your files alongside metadata and artwork from third party providers are ingested into the Roon database at the time of import, then accessed on demand from the database, not from the files. That integration is why a typical Roon database runs several GBs in size and that on demand access is why Roon recommends that the database be stored on SSD, not HDD.
As for MP3 music files somehow leading to a “leaner” database (than implied lossless music files), that is wrong. The music files are not stored in the Roon database. The size and/or compression of music files is not relevant to the size of the database.