Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Album art support in 0.9.5 (thread split) (Read 184994 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Album art support in 0.9.5 (thread split)

Reply #75

Mp3tag.exe ver 2.39  (www.mp3tag.de) don't assign names to embedded cover arts and I  don't choose it by right click of mouse.
You're right. Mp3tag lets you embed multiple images but they are all of the type "front". This means there's no way to display all of them in foobar2000 unless mp3tag lets you assign different types to the embedded images or foobar2000 implements a workaround.


That's right and becouse I say to  plugin autor - "it is possible release manualy cicle embeddes cover arts with middle click of mouse?"

Album art support in 0.9.5 (thread split)

Reply #76
Hi, I'm just curious. When I select more than one track, album art panel (in the new 0.9.5 ui) shows just [multiple items] even though the album arts are the same in all selected items. Is it standard behaviour or am I missing something? If this is normal, I would say it's quite a pity... Even if the album arts differs I would greet rather a random art than nothing. But anyway, thousand thanks for the new version...

Album art support in 0.9.5 (thread split)

Reply #77
You will not get[multiple items] when the songs are referencing the same art file.

So, if your album art is embedded (ie each song references it's own art stored in the tag), or you have a multi-disc album split across multiple directories, then you will get [multiple items] because foobar has no way of knowing they are the same image.



I have my albums sorted by directory with a folder.jpg in each folder and do not get [multiple items] for multiple items selected of the same directory.
elevatorladylevitateme

Album art support in 0.9.5 (thread split)

Reply #78
ok, then it seems that foobar prefers the album art tag rather than any file image in the appropriate folder, cause I've got them both and [multiple items] is displayed. Is there any way how to tell foobar where to take album arts? I'm really not interested in deleting all album art tags from my files...

Album art support in 0.9.5 (thread split)

Reply #79
i'm interested as well in setting foobar to display folder.jpg instead of the album art tag since i keep my high res album art in the folder.jpg and the low res in the tag. why i keep it that way? because of my stoopid ipod.

Album art support in 0.9.5 (thread split)

Reply #80
Dude, get Rockbox. All the cool kids are.
elevatorladylevitateme

Album art support in 0.9.5 (thread split)

Reply #81
I want to re-evaluate my proposal about how the artwork images are found in the current directory.

Namely it would be essential to be able to determine the keywords that are used for the four different cover images on your own. Currently they're:
Quote
Front cover: folder.*;front.*;cover.*
Back cover: back.*
Disc picture: medium.*;media.*;disc.*;cd.*;dvd.*


But IMHO there should be an option in the Advanced preferences dialog, where we can enter wildcards of our own. (Just like the ones under "Legacy title format settings" or "Properties dialog" or even those like "Media Library->File Types").

For example I don't have any image files that match "*back.*" (the back of what exactly?), I would need a match like "*tray card outside.*". And I probably won't rename all my scans, I'd rather wait for a better album art component I could use with the new Default UI.

Apart from the current directory search, an TAGZ based matching and an option to set an artwork directory, would still be appreciated.

Album art support in 0.9.5 (thread split)

Reply #82
It would be great if support for transparency was added, as well as the option to, when it displays an image instead of "no album art", tile or center the image instead of stretching it when the image is smaller than the display box.

Album art support in 0.9.5 (thread split)

Reply #83
It seems transparent PNGs always render with a background color of black. Why not use the PNG's defined background color, or even the background color of the theme?

Also, I find it really annoying that when Foobar's main window isn't active it shows [no selection] even when there was a selection. There's no reason the album art should disappear when entering preferences, looking at the console, etc. Very distracting.

Album art support in 0.9.5 (thread split)

Reply #84
I have few requests:

- Ability to embedding image file into audio file
- Option to save embedded album art into image file
- Trancoding between audio formats with preserve of embedded album art
- Gradual transition instead of flicker when changing image in Album Art component

Is it possible? 

PS. Sorry for my english...

Album art support in 0.9.5 (thread split)

Reply #85
the fact that the album art viewer can't be switched between "follow cursor" and "now playing" like the old album art panel greatly saddens me.

Album art support in 0.9.5 (thread split)

Reply #86
New interface is pretty sweet, wish i noticed it earlier this week when the settings for half my programs took a dump and i had already reconfigured my columns ui setup.

This is definatly a step in the right direction, i only have a few complaints at the time:

1. foo_uie_albumart offers a little more flexability with the cover art, mainly, cyclying through the images in the folder a song is playing in, or cycling through the nocover images.  I really miss this since i have a lot of randomly named art in the folders.

2.A minor gripe, the old icon was better.

3. I dont like the large playing icon, i prefer the colums ui setting where the currently playing song was just a different color.

4. I couldn't change the color of the text in a column, i probly have no more need to do this thanks to the track info panel but i was just annoyed that i couldn't do it.

Album art support in 0.9.5 (thread split)

Reply #87
Please consider at least adding an option to change the default filenames the Album Art Viewer looks for!
the current settings of

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

are very restrictive.
One issue I have with it - and I suspsect for many others as well - is that my Zune software only recognizes album art named as ZuneCustomAlbumArt.jpg, Im forced to make two copies, folder.jpg and ZuneCustomAlbumArt.jpg for foobar and zune to recognize album art, which im relaly not willing to do.
(they used to recognize folder.jpg too but they changed that for whatever retarded reason)

Album art support in 0.9.5 (thread split)

Reply #88
The topic is almost all about your fact @heycheckit. Though somewhere it's better to release the current beta and put it the feature into a brand new version. Just hope the developers feels to add/modify it. It's a pity but, I'm not really convinced they are willing to. I'm not sure what they do about it. So atm I'm lurking at this topic.

Album art support in 0.9.5 (thread split)

Reply #89
I second that : I'm really hoping for a lot more flexibility regarding album art file names and locations.

Album art support in 0.9.5 (thread split)

Reply #90
Wouldn't following match all possible name shemes?


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

Album art support in 0.9.5 (thread split)

Reply #91
It's not only about name schemes : it's about folders too. One should be able to choose a folder (or several folders) for all front covers, a folder (or several folders) for all back covers, etc.

Exactly in the same way that we can choose a folder (or several folders) for our music library !!!

Album art support in 0.9.5 (thread split)

Reply #92
 I'm thinking you start the discussion in This Thread, Page 2
See the post of fuusion who has far the best solution (I think) concerning filnames, folders, in fact any structures. However as I said above I'm not convinced a developer have picked this up. If you meant something different, sorry, my bad.

Album art support in 0.9.5 (thread split)

Reply #93
Surely, as a matter of principle, album cover file names and locations should be fully user customisable (as in past versions). The options proposed are good as a default (and they happen to suit me) but why should people be forced into a particular way of dealing with this.

This allows for different structures, language, and approaches to be accommodated.

TAGZ have been used for such things in the past and are much easier to use than regular expressions.

Album art support in 0.9.5 (thread split)

Reply #94
It's not only about name schemes : it's about folders too. One should be able to choose a folder (or several folders) for all front covers, a folder (or several folders) for all back covers, etc.


I am the same opinion - but that was absolutely not my topic. Forget for one moment what you saw in foo_uie_albumart and ask yourself why must (1.) the location of the images and (2.) the names of the images be defined in one place/at same time and by using TAGZ functions. If the following (a little bit modified):

Front cover: *folder*.*;*front*.*;*cover*.*;*%album%*.*;<only one picture>
Back cover: *back*.*
Disc picture: *medium*.*;*media*.*;*disc*.*;*cd*.*;*dvd*.*

really matches all possible and senseful name shemes why should a user then bother about the names at all and not just define possible locations? Why should he use the $replace function to define albumfolder as location when a simple checkbox for "Look in albumfolder" would do the same job?

Surely, as a matter of principle, album cover file names and locations should be fully user customisable

Fully customizable means i can define my front covers as images with "back" in their name - nobody would do that, or? Can someone give me one example of names that would not match to the patterns above?

Album art support in 0.9.5 (thread split)

Reply #95
@q-stankovic : I'm not sure to have perfectly understood your post (sorry). But let's imagine for example that :
1/ For conventional albums, name of the front cover is "%album artist% - (%year%) %album% - front.jpg"
2/ For OSTs, name of the front cover is just "Soundtrack - (%year%) %album% - front.jpg"

Let's assume that we put all front covers in the same folder (I'd hate to do that, but let's assume it). Would foobar according to your method be able to recognize all patterns automatically, or should we be able to enter the patterns manually ? I'd feel more secure with the second solution, don't you think ?

 

Album art support in 0.9.5 (thread split)

Reply #96

It's not only about name schemes : it's about folders too. One should be able to choose a folder (or several folders) for all front covers, a folder (or several folders) for all back covers, etc.


I am the same opinion - but that was absolutely not my topic. Forget for one moment what you saw in foo_uie_albumart and ask yourself why must (1.) the location of the images and (2.) the names of the images be defined in one place/at same time and by using TAGZ functions. If the following (a little bit modified):

Front cover: *folder*.*;*front*.*;*cover*.*;*%album%*.*;<only one picture>
Back cover: *back*.*
Disc picture: *medium*.*;*media*.*;*disc*.*;*cd*.*;*dvd*.*

really matches all possible and senseful name shemes why should a user then bother about the names at all and not just define possible locations? Why should he use the $replace function to define albumfolder as location when a simple checkbox for "Look in albumfolder" would do the same job?

Surely, as a matter of principle, album cover file names and locations should be fully user customisable

Fully customizable means i can define my front covers as images with "back" in their name - nobody would do that, or? Can someone give me one example of names that would not match to the patterns above?


What you say may be plausible for users of English; I'm not sure how that might impact on users of other languages.

In any case, not all music in collections is from albums. As well as albums, I have a number of historical recordings of songs, downloaded podcasts, etc. which I want to display art for, so here's some examples from my own set up:

When playing tracks from a selection by artist I show the artist(s) (based on the %artist% tag) in a header and cycle through the composer(s) of the track which is playing. (I have composer names stored in a %composer% tag which I use to get the image of the composer.)

When playing tracks from a selection by composer I show the composer(s) in a header and cycle through the artist(s) performing.

For certain tracks I have particular images - say an excerpt of a particular performance with images of that performance - stored as <title>?.jpg. So I cycle through %title%*.* in a display.

It was a bit fiddly, but not particularly difficult, to set Foobar up that way but I like it I how I've got it and I find it very useful. That's what I like about Foobar - I can make it do what I want. No other player met my needs and I was able to customise Foobar to work how I want it to.


My general point is that there will always be lots of users with different needs which cannot be anticipated by developers.  Good software allows users to meet their own needs by allowing customisation. Why should that be restricted? If people want a particular set up and they are prepared to put their own effort in to get it how they want - why shouldn't they be able to? A good application can be fitted to the way people need or want to do things - it should not force users into a particular way of operating!

A good default, but fully customisable: everybody gains!

(In the meantime, I'll stick with the album art display plug-in!).

Album art support in 0.9.5 (thread split)

Reply #97
My general point is that there will always be lots of users with different needs which cannot be anticipated by developers.  Good software allows users to meet their own needs by allowing customisation. Why should that be restricted? If people want a particular set up and they are prepared to put their own effort in to get it how they want - why shouldn't they be able to? A good application can be fitted to the way people need or want to do things - it should not force users into a particular way of operating!

A good default, but fully customisable: everybody gains!

I totally agree !!! A good default doesn't mean that foobar doesn't have to be fully customizable, even with the default components (no need for exotic dlls to tweak the Playlist View or the Album art patterns for instance). IMHO foobar must be able to work in both modes (beginner and expert).

And since 0.9.5, I have the feeling that some developers (no offense intended of course) are focused on the ease of use, which is great of course, but tend to forget a bit about the total customizability that has made foobar a reference among expert users.

A good example is the default buttons in 0.9.5. Personally I like them, I don't feel the urge to change them, but I understand other people's complaints because I really don't understant them being hard-coded ! Hard-coded stuff belongs more to closed, commercial projects, not to cooperative projects like foobar. This is wrong IMHO.

I really hope I'm wrong, but when I see that simple customization requests like "let us enter several custom directories for the art files and at least one different custom file pattern per directory" don't seem natural/logical to developers, I must admit that I don't understand. You can define as much default patterns as you want, there'll always be someone with a different pattern. So why wouldn't you let people enter their own patterns / directories, plain and simple ?

It's not about the 60+% of users that will be happy with the Default UI and no tweaks. It's about all the others. The genius within foobar has always been to be able to address other people's requests, so that nobody feels left aside and everybody can be happy.


Album art support in 0.9.5 (thread split)

Reply #98
1/ For conventional albums, name of the front cover is "%album artist% - (%year%) %album% - front.jpg"
2/ For OSTs, name of the front cover is just "Soundtrack - (%year%) %album% - front.jpg"

Let's assume that we put all front covers in the same folder (I'd hate to do that, but let's assume it). Would foobar according to your method be able to recognize all patterns automatically...


No, it wouldn't - but as you said: you would hate to do that, so you don't do that. That was my point: Fully customizability means freedom to make senseless things. Maybe there are 1% of all users who likes to be excentric but for me that is not a good reason to make it for the rest more complicated than necessary. Don't understand me wrong: The album art viewer must be improved in the sense to display all album art (of the 99%) but why it must be titleformatting? I can remeber very well as i saw as noobie the foo_uie_albumart plugin how confused i was. I know many people who really need foobar because there is no other program that could do what they want (flexible tagging, creating any views in library viewers,...) - as i made the first experiences with the new DefaultUi i was thinking of them and showed them foobar again: unlike the first time i showed them foobar now they were excited about how simple and powerful a tool can be. Hopefully that is not going to be changed just because a minority likes to manage simple things in a bizarre way and to declare that as freedom. The ideal solution would be: in the advanced prefences we have one line where we can store the name of directory if we don't like album folders.

As i asked myself what are good reasons for storing albumrelated images outside of albumfolders i started to suppose that the real motivation to ask for full customizability is to display any art (artists, composers, locations, logos...). But why didn't you say that explicitly (if i missed something so i am sorry but i think kiteroa was the first, or?)

Album art support in 0.9.5 (thread split)

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


When Clicking on an Artist - how about the option to display an Artist Picture rather than a stub image or text for multiple items. (my structure = albums are within subfolders of artist)?