Album art support in 0.9.5 (thread split), Album Art viewer, source patterns, stub image, embedded images etc. Options

[Rozzo]

Here Album art doesn't go to its place, i.e. Albumart ui element. Instead, it goes to the left superior angle of user interface, covering the elements under it. Albumart ui element stays void.

Any hint?
Rozzo

[Fandango]

• Front cover: folder.*;front.*;cover.*
• Back cover: back.*
• Disc picture: medium.*;media.*;disc.*;cd.*;dvd.*

How about changing it to:

• Front cover: *folder.*;*front.*;*cover.*
• Back cover: *back.*
• Disc picture: *medium.*;*media.*;*disc.*;*cd.*;*dvd.*

...but TAGZ support for front, back and disc would be nicer. I think almost every person is naming and storing his album art differently.

Also, I've noticed that images added to MP3s in a APEv2 tag (done with Mp3Tag) aren't recognised... on lossless files with APEv2 the front image is shown (Mp3Tag cannot specifiy a picture type yet so it's always the front, i.e. first image is the front image/only image shown by AlbumArt, I hope Florian adds this sooner or later...).

I know it's not the standard way to use APEv2 in MP3s, but I prefer it over ID3v2 because it's faster. And since fb2k does not reject normal tag fields in APEv2'ed MP3s, why shouldn't it handle embedded images also?

This post has been edited by Fandango: Oct 22 2007, 13:59

[Peti]

Would it be possible to search one directory higher if %disc% tag is used? Eg. if the music files are in Artist - Album\Disc1 but the covers are in Artist - Album directory.

[Kirya]

Would it be possible to search one directory higher if %disc% tag is used? Eg. if the music files are in Artist - Album\Disc1 but the covers are in Artist - Album directory.

I've solved this issue in foo_uie_albumart. Something like this:

CODE

-$substr(%path%,1,$strrchr($replace(%path%,\%filename_ext%,),\))cover*.jpg

I hope we will get an editable patterns in future

[Bad Monkey]

Album art plug in still does not recognize images embedded in any files with non-standard alphanumberic characters in the filename.

à á â ã ä å æ ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ø ù ú û ü ý ÿ
etc.

Works fine for me for any "normal" filenames.

[vlada]

Fandango
Absolutely agree with you. My naming scheme is %album% - front.jpg, %album% - back.jpg etc. It's because sometimes I store more albums in one folder (if I don't have complete albums).

Why not simply copy the sources scheme from foo_uie_albumart? Most people have their own sources list ready to use.

Also have anyone figured out how to set up the default (missing) album cover? I have a file called default.jpg in components directory. I tried everything imaginable, even full path, but nothing worked.

[foosion]

Album art plug in still does not recognize images embedded in any files with non-standard alphanumberic characters in the filename.

à á â ã ä å æ ç è é ê ë ì í î ï ð ñ ò ó ô õ ö ø ù ú û ü ý ÿ
etc.

Works fine for me for any "normal" filenames.

To me this sounds like you are talking about a third-party component (foo_uie_albumart?), not about the Album Art Viewer UI Element in 0.9.5. The album art reading backend is new in 0.9.5, so installing it does not magically enhance existing plugins, simply because they are not (and cannot be) aware of it.

[sPeziFisH]

How about changing it to:

• Front cover: *folder.*;*front.*;*cover.*
• Back cover: *back.*
• Disc picture: *medium.*;*media.*;*disc.*;*cd.*;*dvd.*

...but TAGZ support for front, back and disc would be nicer. I think almost every person is naming and storing his album art differently.

Musthave! We also need a cyclomat We are skilled dev-team

Configuration for all !

[garym]

FILE/PREFERENCES/ADVANCED/DISPLAY.....then click on "album art stub image path" and enter path and file name for file you want to show up when art missing. I did this and works like a charm. On the other hand, I still have over 1/2 my files showing up as if embedded album art does NOT exist (even though there in MP3tag just fine). See my question on this above. Still waiting for ideas on that one.

Also have anyone figured out how to set up the default (missing) album cover? I have a file called default.jpg in components directory. I tried everything imaginable, even full path, but nothing worked.

[vlada]

That's exactly what I did and it didn't work.

[eevan]

That's exactly what I did and it didn't work.

Try without double quotes. Even if the path contains spaces, don't use double quotes. Than it works.

[linus]

[/quote]
Try without double quotes. Even if the path contains spaces, don't use double quotes. Than it works.
[/quote]

yes, it works.

But why we can't use again path relative to foobar2000.exe?
Using foobar from a removable drive, we don't have a constant absolute path!

[Fandango]

But why we can't use again path relative to foobar2000.exe?
Using foobar from a removable drive, we don't have a constant absolute path!

Yep, it's not uncommon in such cases that when there's no drive letter in the path, then it is assumed by the application, the path is relative to the application's working directory.

So "missing.jpg" would be actually be "C:\Program Files\foobar2000\missing.jpg" (on a default installation).
"themes\missing.jpg" would be "C:\Program Files\foobar2000\themes\missing.jpg"
"..\..\missing.jpg" would be "C:\missing.jpg" and so on...

Of course, absolute paths would still be recognised as such and work like before.

[radio_cascara]

+1 for multiple custom "search for art" file masks.

+1 nofolow for album art (and file info)

+custom background color

[purged]

*back*, *cover* and *cd* as matches would be great

[Alex B]

The recognized filename patterns for the different kinds of album art that can be selected are as follows:

• Front cover: folder.*;front.*;cover.*
• Back cover: back.*
• Disc picture: medium.*;media.*;disc.*;cd.*;dvd.*

I wonder if I am the only one who wants to identify the album art files by the filenames too and hates generic names like "folder.jpg". I also don't want to create duplicated image data and add tagging complexity by using embedded art in my main music archive.

Since I move my CDs to a storage room after ripping I have scanned most of the printed art elements so that I don't need to find the CD case when I want to read the liner notes (...or just enjoy the artwork).

Currently I have over 10000 scanned cover image files and I often browse them with an image-handling program like ACDSee. Instead seeing over 2000 small thumbs named as folder.jpg it is nice to be able to see the album name directly from the filename.

I have used an audio file tags based naming system and organized the images next to the music files in the album folders as follows:

path:

"album artist"\"album"

filenames:

-- a smaller cover art file (500x500) which I use as the standard cover art image:
"album artist" - "album".jpg

-- high resolution scans (...for example - naturally different albums can have different cover art elements):
"album" - Front.jpg
"album" - Back.jpg
"album" - CD1.jpg
"album" - CD2.jpg
"album" - Booklet 1.jpg
"album" - Booklet 2.jpg
"album" - Booklet 3.jpg
"album" - Booklet 4.jpg
"album" - Inlay.jpg
etc...

(I have dropped the "album artist" tag from the hires filenames to keep the filenames a bit shorter.)


I understand that tag based filename patterns would add some complexity, but would that be too difficult to implement? Ideally the filename patterns should be fully user configurable similarly like the other tag based strings in foobar2k are. Also, the image list should not be limited to a certain amount of items and it would be good to be able to somehow detach & enlarge the image viewer, so that the liner notes could be read directly from foobar.

I have a music & image file database program which can automatically associate my "album artist" - "album".jpg files as main album cover art. So far, I have happily used foobar without cover art support and will continue to do so, but it would be nice to be able to use my cover art naming scheme in foobar too since the built-in cover art feature is now available.

If my feature request is not possible to implement a workaround would be to optionally to list all image files from the audio file folder and simply show the filenames in an alphabetical order in the right-click menu. Then the user could always manually select the displayed image. The old and banned footunes user interface had a feature like this.

[Hirvine]

How about changing it to:

• Front cover: *folder.*;*front.*;*cover.*
• Back cover: *back.*
• Disc picture: *medium.*;*media.*;*disc.*;*cd.*;*dvd.*

...but TAGZ support for front, back and disc would be nicer. I think almost every person is naming and storing his album art differently.

Yup, that's a bit better than just cover.* .... At top of that I hope an custom option, like the column headers has. Some fixed sets and custom sets. I prefer the regular expressions like Squeller describes.

Can we have a technical definition (maybe a perl regular expression) of what files are parsed as album art? All I read was just guessing (like [regex] ".*folder\.jpg$")

So, like the column headers some fixed, embedded album cover search lines, and optional regular expression lines. ... That would the trick.

This is really the only stitch I'm in with 0.9.5b. So, good job.
Hopeful this get's implemented asp...

[Fandango]

Why regular expressions when there's TAGZ already?

[TedFromAccountin...]

I don't think anyone has requested this yet, but I think it'd be a good idea to have an option to enable/disable automatic resizing. I have some covers that I cannot find in higher resolution and I'd rather keep them smaller but at higher clarity. Two options, one for images that are too big and another for images that are too small would be ideal, but mainly its just making smaller images bigger that I don't like.

[Hirvine]

Why regular expressions when there's TAGZ already?

Regular expressies are designed for these kind of purpose. How would you for example handle this
^(../)(scan(s)/)?*cover*.(jpg|bmp|png|gif)$
The Tagz are more likely to obtain and display id3 information I guess. Also, regular expressions are more common than Tagz, I'm not really familiar with Tagz.

[foosion]

(Edit: removed full quote)

The main reason why regular expressions will not be used for the purpose of specifying the album art location is ease of use. We are constantly trying to reduce the necessity to use title formatting in the official components, and to reduce the average complexity of title formatting scripts in places were they are used. We are not going to sabotage our own efforts by introducing regular expressions which are even more arcane to the average user. The other reasons are only technicalities.

Regular expressions do not solve the case when album art is stored in a central directory. In this case it is necessary to use metadata to resolve the image path. Using title formatting to generate a path and filename pattern is easy and efficient. A filename pattern in this case is a string with ? as placeholder for a single character and * as placeholder for an arbitrary number of characters.

Picking up on the word "generate". The - by far - most common use-case for regular expressions is to describe an acceptor which means a function that reads a given (text) input and returns either yes or no. For example, this can be used to filter a list of input strings. But what would these input strings be in your ad-hoc example? A list of paths to all files in the filesystem relative to the audio file? A solution could be to interprete a regular expression as a grammar and use it to generate filename patterns. Your example could then be represented as the following list of filename patterns (ignoring extension, also using backslash as directory seperator as is usual on Windows):

CODE

*cover*;..\*cover*;scan(s)\*cover*;..\scan(s)\*cover*

But perhaps I want to give a different priority to some items, so the pattern list would be this:

CODE

scan(s)\*cover*;..\scan(s)\*cover*;..\*cover*;*cover*

How do you represent that with regular expressions?


As further proof of hard to use regular expressions are, I think your example is broken and should be properly written as follows:

CODE

^(../)?(scan\(s\)/)?.*cover.*\.(jpg|bmp|png|gif)$

This post has been edited by foosion: Oct 25 2007, 16:10

[Hirvine]

Hehe, I wasn't in for real writing a regular expression, just an dummy expression to show what I want. If your example code works fine it would be great. As I've told I am not familiar with 'tagz'. I'm a technical ICT specialized in games development and software engineering. I probably wandered in my domain too much this time. Your code is way easier to read.
So foosion, your 'example' code looks great and convinced me. Hope it get implemented that way you describe.

[halabund]

Will any of the album-art related functionality be exposed in the SDK, for third-party components that also display album art?

[Prodoc]

Album art of most file is being displayed properly. There are, however, a few releases in my library which don't seem to work. Other applications as Mp3tag and iTunes are able to display the album art of those files correctly.

An example file can be found in the uploads section (hidden, only accessible for staff members).

This post has been edited by foosion: Oct 26 2007, 13:47

[Alex B]

ID3v2.2 and the PIC frame?

Check my reply here: http://www.hydrogenaudio.org/forums/index....st&p=525400