Folder.jpg not always recognized as cover

I wanted a clarification ...

But if in the folder, I have only music files that contain the cover in the tags. I can see folders such as CD-Cover?

Or I must , in any case, use the file coverart.jpg?

Thanks

The quickest way to find out is to simply try both and see what happens. That's what I did (I used folder.jpg instead of coverart.jpg, but that doesn't matter):


ok but I did not want to use any jpg file (if possible) and have the CD-Cover

I thought that Dopus, go to read the tags and recognize the cover

[quote="plunder"]
unfortunately, all of my album folders contain files with the name "cover.jpg" (back.jpg, ..) and for some good reason (compatibility with some other program, cataloguer) i wont rename them from cover.jpg to coverart.jpg.
Maybe, in a future version of Dopus10, there's some switch in the Preferences>>Miscellaneous>>Advanced>>... ? Crossing fingers! :sunglasses:[/quote]
Same problem. My music collection is organized like this, H:%album artist%%album artist% - %year% - %album%, and inside the album folder, I have front.jpg, back.jpg, cover.jpg, and folder.jpg, and it's working alright in most apps. Shame to see that DOpus as the most customizable and flexible thing I've seen can't be configured to use some other file name instead of coverart.jpg. I'm sure it's not hard to implement, but I don't know, maybe it doesn't fit into your vision of what DOpus should be, or it's not on your priority list.

Some of my folders are already half-music, half-artwork :grin: , it would be great if I could avoid another duplicate image for the same thing.

folder.jpg works in Opus, and you've got folder.jpg in your list already, so what's wrong?

Do you have so many other jpgs each album folder that it's not being recognised as a music album automatically? That, and weird cases like single-track albums, are usually the only cases where you need to have coverart.jpg to explicitly force the cd-cover mode.

folder.jpg works in Opus, and you've got folder.jpg in your list already, so what's wrong?

Do you have so many other jpgs each album folder that it's not being recognised as a music album automatically? That, and weird cases like single-track albums, are usually the only cases where you need to have coverart.jpg to explicitly force the cd-cover mode.[/quote]
Yeah, sometimes it seems kinda unpredictable to me... I've got one album with 30 mp3's, and 7 jpg's, and it doesn't display folder.jpg correctly. Then there's another one where I have 10 mp3's, and 5 jpg's, and it works alright. :grin:
Adding coverart.jpg for DOpus wouldn't kill me, but I guess I got used to its meta-configurability and got even more obsessive about such trivialities. :grin:

Fair enough, I guess. :slight_smile:

As a few people have asked for it now, I've put in the option, but its release will need to wait until the language translations are updated (so don't worry if it's not in the next beta, but it'll be available in the not-too-distant future).


Thanks...

Maybe it's also an opportunity to add a nice section with a complete description, in the manual .... :smiley: :smiley: :smiley:

Awesome. Thanks, Leo.

Makes sense... various media mgmt and playback related apps out there allow configurable cover art filenames, and it doesn't strike me as very "advanced" so much as an acknowledgment that many people likely obtain their music from a variety of sources which include album cover images in a variety of filenames. I'd imagine that some people might like a comma or semi-colon delimited to allow specifying multiple filenames though... Especially active downloaders who do indeed find that the cover images for their music come in several different names, and would prefer Opus to be able to handle those filenames rather than have to always take 'corrective action' by renaming those images to coverart.jpg all the time.

Anyhow, re:

Well, the thing that I find a minor annoyance is that even in an album folder with say - 13 mp3 files and just the folder.jpg file, yes... Opus displays a cd cover thumbnail just fine. But add just a single additional non-mp3 file to the folder (say a cue file, or a playlist), and the cd cover thumbnail is lost. I thought at one point I saw you comment that if "most" of the files in the folder were mp3's, then that's what Opus used to decide if folder.jpg should be shown as a cd cover thumbnail or not. It seems like it's far more restrictive than just "most" files though - it looks like it's got to be ALL mp3 files and no other non-mp3 file other than folder.jpg (unless of course the other non-mp3 file is coverart.jpg - where even any other jpg filename breaks it). Yes single-track albums are an issue - but that's hardly the most likely scenario where this "breaks" where, for instance... even a folder with 100 mp3's and a folder.jpg file loses the cd cover if a single txt file is added...

Any way to make it so that if that new advanced/misc option is used - then whatever filename(s) are entered can force Opus to display the cd cover thumbnail regardless of. the presence and/or number of other files? Specifically, looking to be able to explicitly list folder.jpg in there so that it's treated like coverart.jpg and always displays as a cd cover regardless of the scenario above with 100 mp3's + folder.jpg + a playlist file.

Also, out of curiosity - will this option allow people to specify other image formats (say - png)?

I think PNG will work but haven't tried it.

CoverArt.jpg already forces CD album thumbnails; that's always been the point of it on top of the normal folder.jpg.

A comma separated list would slow thumbnail generation down and doesn't seem useful to me.

BTW - thanks for this option. I prefer to keep my cover images named "folder.jpg"... mainly due to having a variety of buttons and scripts for album art downloading and other automated tasks already set to use that file name.

At any rate, I was real happy to see that explicitly setting the new advanced option to "folder.jpg" causes Opus to force CD album thumbnails, and also to NOT lose the CD image rendering when other files (cue, m3u, pls, etc) are present. Thanks for that...