Grouping msuic art works

[zluo01]

Feature request

Currently, to read album art, need to rely on either have physical copy of image in correspond format under the song folder, or read image of a song from tag at runtime.

This produce some burden on displaying album images from the client end since it would requires multiple fallback handling and a few communication from clients to the server.

It would be better to have a dedicated location to store all album arts in a single directory similar to playlists which I think produce following benefits:

• Better album art retrieve logic, if such a place does not have image then client end is safe to assume music does not have any album art.
• Many music bought online can have album arts differ in dimension, shape or size, it creates burden on the clients end to handle different dimension of images. Also, large size album art take times to transfer. If it is stored somewhere centrally, would be easy to additionally to apply augmentation to album arts dimensions or convert to other format (png -> webp/avif) to further reduce the image size.

Thanks.

[MaxKellermann]

I don't understand. You want one directory that contains all the pictures? How is this directory organized? How does it look like? How does MPD pick up the files? Who manages that directory?

[zluo01]

Yes, I want to have a central place to contains all the pictures, either directory or in db

How is this directory organized? How does it look like?

I am thinking something like following for directory:

Directory strucutre

root folder: .cover.

cover files path: .cover/<SONG_URI_FOLDER>/cover.<FORMAT>.

Request image binary

To get the cover file binary, requests with api similar to following
albumart foo/bar/music.ogg this will translate to path .cover/foo/bar/cover.<FORMAT> and we can return the cover binary.

How does MPD pick up the files?

MPD scans the audio files to construct a db, so I think we can get cover binary from tag when reading audio files at the same time and save to certain place.

Who manages that directory?

I expect MPD will manage the direcotry. Since MPD do increment scan, so it can save the album art to the directory as well.

I think save the album binary to db should also work but by saving it to directory, it allows additional augmentation such as downscaling/compression more easily.

Please let me know above approach is feasible.

Thanks.

[MaxKellermann]

If MPD writes to that directory, where does the data come from? You said from the music file, but MPD already supports reading pictures from music files. Why not keep it in the files, why create a copy?

[zluo01]

Today, per my understanding, for a client to display a screen for albums with album arts that cover all cases, we need to do

get the list of albums -> retrieve songs from albums name -> use URI to search if there are covers image from URI directories -> if not fallback to check if one of songs in each albums contains pictures within the metadata -> if neither fallback to some default -> client side cache to reuse the image.

in this route, we need to request server two times on different thing, and on server, there will be one file read and one directory search.

If we can save all image to a central place, either directory or database, then we can reduce the step to one requests on client and one binary transfer on server ?

If MPD is already doing precompution on song metadata, why not also precompute album covers to save some ad-hoc CPU usage ?

[MaxKellermann]

With your feature, how will the communication and the I/O look like?

[zluo01]

I might need more context on what exactly is communication and I/O mean in your context. But I think communication and I/O should be the same as readpicture, instead of try to fetch image from URI folder, we read image from the new central place instead.

[jcorporation]

This feature request does not make sense to me. What I can imagine is a new protocol command that uses readpicture and falls back to the albumart command in a transparent way for the client. This will reduce the complexity on the client side to implement the fallback and reduces one protocol round trip in the fallback case.