07-01-2020, 04:24 PM
(This post was last modified: 07-01-2020, 04:29 PM by TheOldPresbyope.
Edit Reason: fix redundant entry
)
[If there are any mistakes in the following I'm sure Tim will correct them, but here's how it looks to me from my seat in the bleachers.]
Images which are embedded in individual track files as part of their metadata are treated one way. Image files which are in the album directory containing the track files are treated another way. The "Cover search priority" selector in the Appearance configuration screen in moOde tells which to choose if both are present.
For embedded images, let's look at two common metadata schemes (there are other schema and other music encodings; I just chose the ones I usually see):
The ID3v2 scheme (commonly used to tag MP3 files) allows the embedding of none, one, or many images in individual "APIC" frames, each with a Picture Type code like "$03", which is the code for "Cover (front)".
Likewise, the Vorbis Comment scheme (used to tag FLAC file and various OGG encapsulations) allows the embedding of none, one, or many images in individual "METADATA_BLOCK_PICTURE" blocks, each with a Picture Type code copied from the ID3v2 scheme.
From what I see in the moOde code it appears that, for both types of files, Tim's coverart.php routine extracts only the first image, if any is present in the track file, without regard to its Picture Type. This is not unreasonable to do given the state of metadata markup in the real world.
What this means for you is that at best only the first image encountered in a file's markup would be used.
As for image files in album directories, there is no standard for it, only conventions observed by some software and broken by others.
The current coverart.php code requires a cover image in an album directory to be JPEG, TIFF, or PNG encoded, to have one of four basenames: ("Cover" | "cover" | "Folder" | "folder"), and to have an extension to match the type: (".jpg" | ".jpeg" | ".png" | ".tif" | ".tiff"). Again only one image will be used.
So, to consider your question about more imagery.
Among the decisions to be made are:
dealing with URLs is awkward IMHO because anything less than a popup web browser is likely to be inadequate in handling them.
Just my 2 cents worth.
Regards,
Kent
Images which are embedded in individual track files as part of their metadata are treated one way. Image files which are in the album directory containing the track files are treated another way. The "Cover search priority" selector in the Appearance configuration screen in moOde tells which to choose if both are present.
For embedded images, let's look at two common metadata schemes (there are other schema and other music encodings; I just chose the ones I usually see):
The ID3v2 scheme (commonly used to tag MP3 files) allows the embedding of none, one, or many images in individual "APIC" frames, each with a Picture Type code like "$03", which is the code for "Cover (front)".
Likewise, the Vorbis Comment scheme (used to tag FLAC file and various OGG encapsulations) allows the embedding of none, one, or many images in individual "METADATA_BLOCK_PICTURE" blocks, each with a Picture Type code copied from the ID3v2 scheme.
From what I see in the moOde code it appears that, for both types of files, Tim's coverart.php routine extracts only the first image, if any is present in the track file, without regard to its Picture Type. This is not unreasonable to do given the state of metadata markup in the real world.
What this means for you is that at best only the first image encountered in a file's markup would be used.
As for image files in album directories, there is no standard for it, only conventions observed by some software and broken by others.
The current coverart.php code requires a cover image in an album directory to be JPEG, TIFF, or PNG encoded, to have one of four basenames: ("Cover" | "cover" | "Folder" | "folder"), and to have an extension to match the type: (".jpg" | ".jpeg" | ".png" | ".tif" | ".tiff"). Again only one image will be used.
So, to consider your question about more imagery.
Among the decisions to be made are:
- what image types will be accommodated (ID3v2 defines 21 different ones, including Type "$11" - A bright coloured fish !)
- how they would be extracted from embedded metadata, given the state of the existing specs, and how they shall be named so they can be extracted from directories.
- how they shall be displayed and otherwise used in the moOde UI.
dealing with URLs is awkward IMHO because anything less than a popup web browser is likely to be inadequate in handling them.
Just my 2 cents worth.
Regards,
Kent
