Now, a question

Is there a way to lock album art to now playing song only?

It's follow cursor only right now. and i don't see any setting anywhere.

Every 2nd row in the playlist is a bit lighter/darker. The difference between them is too small for my taste. Can this be changed?
Yeah the new playlist grouping layout, isn't that exactly what musicmusic started a couple of weeks ago?

What files does the album art element look for, if none is embedded?

How does the albumart feature work for non-embedded art work? I am assuming that it is set up in Advanced -> Display, but nothing I try shows me the file in the viewer. My file structure is: "E:\My Music\Artist\Album\AlbumName.jpg"

Thanks in advance for the help.

I'm impressed that embedded art works so well with my FLAC, M4A & MP3 files.

The new default UI is very nice, I'm playing with various things now. Only one drawback -- seems slow at the moment. Takes a second to restore from minimised state, slow when dragging windows over it. (900 Mhz processor here.)

What I found about Album Art Viewer's behaviour is that it works for the currently selected track, and only if cover filename is "cover", "front", "back" etc. I'd like to have more options, at least list of used paths with wildcards. Well, it's beta.

The way layout editing mode works is just great! What you're editing is easily visible, the mode is more intuitive than component tree in Columns UI preferences. Copy/paste is sometimes very useful.

Album List maybe needs an option to automatically create playlist of what's selected in it, like the panel in
Columns UI.
EDIT: okay, I can live with middle mouse-button for that!

Thanks Peter for many updates, like tracks grouping, Restore Playlist, improved Playlist Search, massive File Operations dialogue and, of course, Spectrum! (Which is slow too -- needs 7 sec to open).

It doesnt need any setup. It will automatically locate most typical external album-art. If you want to make absolutely sure, then just let your album art filenames end in "cover".

Rest assured this feature of 0.9.5 has been in development for quite awhile.
In the Advanced options pane, You have a setting for the default album art image.

I'm also curious about what files albumart is looking for.

Embedded covers in APEv2 tags (Mp3Tag syle) doesn't seem to work. Image files are recognised when they have the file names "folder, front, back, disc,..." I guess.

Would be nice to show images which names include these keywords, so we can still have the artist, album, etc in the file names...


What does "Album art stub image path" do exactly? Default image file name? Can I use TAGZ here or field names like %artist% and %album% and so on?

@Fandango: An absolute path to an image file, I believe. Not sure if title-formatting works or not.

I'd like to know that too. I keep all my covers in one folder and so far I had no luck setting up this feature.

Apart from that, I'm really glad to see custom grouping and all the other improvements that this beta brought: thank you!

Alessandro

"Album art stub image path" (Edit: located at Preferences, Advanced, Display) sets an image that is displayed when no album art was found.

In other words, it's intended for pictures like you find in this thread.

The entered value has to be an absolute path to an image file, without any title formatting.

Works fine with FLAC embedded covers (especially with the correctly added covers, it means --picture flac command-line option with TYPE param).

Then I guess this hasn't been added (yet). Although Mp3Tag generally doesn't support editing the type of embedded covers, the default seems to be "Front". So it should work, if fb2k were able to read APEv2 covers.

maybe a (small) bug:

When I add (or rename) a file as folder.jpg or cover.jpg for an album already present in the current playlist, the cover doesn't display even if I double click on any song (of the playlist). I either have to restart fb2k or to use another playlist and then return back to see it.
Minor inconveniance... discovered while trying to check which name I should give to external album art.

People wants to configure it properly before they use it. Doesn't that make sense?


+1

Yes. Also when you add another/new album art UI element then it displays the new image whereas the old still won't.

Images are not reloaded when the old and new path are the same after selecting a different track (or set of tracks). I usually just select a song from a different album and change the selection back to get the new or changed image to load. Of course, you have to have tracks from different directories in one playlist for this.

Would be nice if the covers will change on mouse click or double-click (front-back-disc)

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$")

I have embedded cover art in my mp3 (some lame some fhg) files. 0.9.5 works fine with many (most) of these in terms of displaying art work. But with some files, it displays the wrong art work. When I look at these same files within mp3tag or itunes for example, the artwork is correct, there is only one item of artwork embeded in the file (front cover only). Yet in the new foobar configuration, the wrong artwork is displayed (again only in some songs). The wrong artwork is ALWAYS the same picture (which is the correct artwork from another file). I've set the default artwork in preferences/advanced/display to show a particular jpg, and this works just fine.

If I take one of these incorrect files and use mp3tag to change the album art to a new jpg file, the new art file shows up correctly in foobar. I'm thinking that this "incorrect" album art that is showing up inappropriately with the wrong file is somehow sitting in a database, directory, etc. as a cover.jpg type file that foobar is reading by default. I use all embedded art in tags, so not sure where this directory might be and nothing seems out of place in my foobar subdirectories. Any suggestions?

Edit: Followup. I was doing this with one subdirectory of recently ripped files just as a test. I copied to a new subdirectory and reloaded into foobar. Now I don't get the "wrong" artfile on some of these. Instead I get the art file that I've selected for missing art. However, the files in question do in fact have art and I can see it in MP3TAG (these are jpg files and nothing seems odd about them). Still not sure why this is happening. Many of the other files display correct art work with no problem. Also jpg files.

So there's a stub image for missing album art ([no image]), but then "[multiple items]" needs a stub image too.

New information related to my post yesterday on foobar not reading some of my embedded art files. The album art works fine for only some files (all have embedded art in mostly lame files). Foobar thinks I don't have artwork embedded even though I do (can see in mp3tag and itunes). If I open files in mp3tag, save the existing art file, delete the existing album art from the mp3, then re-add the same exact art back to the mp3, the correct art work shows up fine in foobar 0.9.5. I've checked and the size of the jpeg file is not different before and after removing and adding back to the mp3 file. Seems quite odd to me that many of the art files are not read properly by foobar when they are shown OK in mp3tag, itunes, and other places. I'm sure it is something simple I'm missing but for the life of me can't determine what could cause this behavior. Otherwise, I'm quite enjoying the new version and have easily configured the setup I wanted without all the additional add-ins and programing I'd previously done. Very nice!

Will this component get an option to set source paths with TAGZ?
I have a cover folder in which %artist% - %album%.jpg exist.

I have my cover art named "00 - Cover.jpg" and foobar doesn't see them. It only detects them as cover art when I rename to "cover.jpg". I think it would be great if we could configure cover art filenames or possibly foobar detect wider range of such cover file names.

Any updates on this?


For me it worked to rename all album_art.jpg to folder.jpg, but a more detailed description would be nice nevertheless.

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.*

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

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?

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:



I hope we will get an editable patterns in future

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.

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.

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.

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

Configuration for all !

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.

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.

[/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!

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.

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

+1 nofolow for album art (and file info)

+custom background color

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

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.

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.


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...

Why regular expressions when there's TAGZ already?

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.

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.

(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):
But perhaps I want to give a different priority to some items, so the pattern list would be this:
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:

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.

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

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).

ID3v2.2 and the PIC frame?

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