Audio file artwork rules

[simbun]

Hi @simoncn,

I think their may be an issue with the audio file artwork implementation.

Quote:1. A file named filename.jpg or filename.png (exact-case match only) in the same directory (folder) as the audio file, where filename is the filename of the item without its file extension suffix. For example, the audio file Magnificat.flac could have artwork in the file Magnificat.jpg or Magnificat.png.
2. Artwork in JPEG, PNG, GIF or BMP format embedded within the audio file

I have a jpg with the same name as one of my files but MinimServer is telling the control point to use the embedded image instead.

I'm using this setup purely to test mconnect - which pulls artwork directly from the file being served regardless of what the server tells it - but couldn't get it working.

Thanks

[simoncn]

I have confirmed that the behaviour doesn't match the description, as you say. I checked back and it looks like the code that does this hasn't changed since MinimServer 0.8 update 124 in August 2018. The custom artwork file is applied only if there is no embedded artwork.

I think the code might have been written this way because embedded artwork is part of the UPnP standard and custom artwork files are not, so the standard mechanism should take priority if both have been used. It appears the authors of mconnect came to the same conclusion.

I would welcome opinions and rationale for which image should take priority when both are available. Is the ability to override an embedded image only useful for testing or are there other situations where this would be needed?

There was some discussion in this thread which reached a conclusion that this feature (if it worked as described) would not be very useful. I also found a discussion in this thread which proposed using hi-res filename.jpg files to override low-res embedded images. This does seem like a reasonable use case for the priority described in the user guide.

[simbun]

I was looking at these rules to see if using the embedded artwork during playback could ever be the wrong thing to do. The current MinimServer documentation describes a scenario where that could give incorrect results, but the current implementation differs from that.

Within MinimServer, the only reason it may be beneficial for an external image (filename.jpg) to override an embedded one is because the embedded image forms part of the album artwork ruleset (which trackname.jpg does not), so the only way to implement a track override would be at the filename level.

I only have a few instances where I've needed to use embedded artwork (and that's only because I'm using a pseudo album tag to help with attribution), so I'm more than happy with simply modifying the documentation.

[simoncn]

(14-03-2024 10:27)simbun Wrote:  Within MinimServer, the only reason it may be beneficial for an external image (filename.jpg) to override an embedded one is because the embedded image forms part of the album artwork ruleset (which trackname.jpg does not), so the only way to implement a track override would be at the filename level.

I think this is a valid point in favour of changing the implementation to match the description.

Turning this around, I have been trying to think of a situation where using filename.jpg to override an embedded image could cause a problem. The only one I can think of is where a track named the same as an album, group, or disc in the same folder. In this case, the filename.jpg file might be intended to override artwork at the album, group or disc level and the user would be surprised to see it also overriding artwork for an individual track. The user would have no way to change this (other than renaming the track file) and this seems to be a significant point in favour of changing the description to match the implementation.

[stefano_mbp]

(14-03-2024 11:46)simoncn Wrote:  …. The user would have no way to change this (other than renaming the track file) and this seems to be a significant point in favour of changing the description to match the implementation.

Please leave the implementation as it is.
Thanks

[simbun]

(14-03-2024 11:46)simoncn Wrote:  

(14-03-2024 10:27)simbun Wrote:  Within MinimServer, the only reason it may be beneficial for an external image (filename.jpg) to override an embedded one is because the embedded image forms part of the album artwork ruleset (which trackname.jpg does not), so the only way to implement a track override would be at the filename level.

I think this is a valid point in favour of changing the implementation to match the description.

Whilst it does offer greater flexibility, given that a control point could choose to use the embedded artwork I think it makes sense for MinimServer to align, and keep the implementation as is.

I guess you could add and prioritise filename.jpg over embedded in the album search rules to recoup some flexibility, but if there isn't a real-world use case I'd be tempted to just modify the documentation.

[simoncn]

I have updated the user guide page to match the implementation.

[simbun]

(23-04-2024 20:50)simoncn Wrote:  I have updated the user guide page to match the implementation.

Thanks Simon.

[lyapounov]

As for me, I made a decision to always delete the images embedded in the file, and to have always a Cover.jpg in my folder.

Reasons:

1) sometimes embedded images are low rez

2) it takes more bytes (though nowadays, who cares... But I have already 9TB of music)

3) I have seen cases where images were different within the same album, and I want only one image for the album

But again, that is only me...

[paultaylor]

Im glad you have chnaged the guide rather than the implmentation. This is because the image file is more likley to have been superceded by the embedded file rather than the other way round.

For example user has an album with existing filename.jpg in album folder they run tagger tool to search for higher res artwork, most tagger tools will always embed the artwork in the music file, only some will optionally save the image to the folder and if they do this is more likley to be called cover.jpg than filename.jpg.

So now the new image is in the file, filename.jpg refers to the old file.