Open Oleksiy-Yakovenko opened 9 years ago
Comment #1 originally posted by Alexey-Yakovenko on 2014-05-28T20:31:48.000Z:
deadbeef doesn't (and won't) support fetching embedded album art via ffmpeg plugin.
well, you can make feature request for it, but it's unlikely it will ever get implemented.
you might be interested in using this opus plugin instead: https://bitbucket.org/Lithopsian/deadbeef-opus
it doesn't have album art support either, as far as i know, but this will be added at some point, via bug # 1083
Comment #2 originally posted by Alexey-Yakovenko on 2014-05-28T20:32:43.000Z:
changing this into feature request.
Comment #3 originally posted by Alexey-Yakovenko on 2014-05-28T20:38:14.000Z:
Ah, I see. I assumed it was a bug because it works for tak, but I guess tak is a special case because it's not open source. Having a dedicated opus plugin makes sense.
Comment #4 originally posted by Alexey-Yakovenko on 2014-05-28T20:46:04.000Z:
Nope. It doesn't work for TAK either. Perhaps the cover is being fetched from internet, if you have this enabled in the settings. And since TAK coded used by deadbeef is part of ffmpeg -- it's also open source, of course.
Comment #5 originally posted by Alexey-Yakovenko on 2014-05-28T21:08:18.000Z:
That's weird, I never enabled that feature. Considering the stable version couldn't open the files, it shouldn't have cached the album art. And in the devel build, it's not enabled. But new files added to the playlist don't find any cover art anymore. Oh well.
What I meant by "open source" is that the ffmpeg version was reverse engineered vs coming from the developer of TAK. It would make sense to implement getting album art for TAK via FFMPEG, because the author doesn't have plans to open TAK's source, so a dedicated plugin for TAK doesn't seem likely. In that sense, changing it to feature request is correct.
Slightly OT, I can't seem to find where deadbeef stores the cached album art. Some songs are stuck with wrong covers and reloading metadata doesn't seem to update it.
Comment #6 originally posted by Alexey-Yakovenko on 2014-05-28T21:36:42.000Z:
~/.cache/deadbeef
Comment #7 originally posted by Alexey-Yakovenko on 2014-05-30T16:10:11.000Z:
I agree use the Opus plugin to play Opus files. I wrote it :)
Displaying album art isn't really there yet though. Album art tags are recognised and parsed, but there is currently not a defined way to make the artwork plugin display it. All you see so far is a tag describing the covert art contents. Hopefully this will be improved fairly soon so that the image itself can be displayed by the artwork plugin. A quick and dirty solution would be to just slam it into the artwork plugin cache directory, but that's not very nice.
Issue # 1083 discusses possible solutions for displaying images from METADATA_BLOCK_PICTURE tags in Ogg files.
Comment #8 originally posted by Alexey-Yakovenko on 2014-05-30T17:46:10.000Z:
@waker...: you say it doesn't work for TAK, but for some reason after doing the following, I'm still getting cover art displayed for some of the TAK files:
Any idea why? That sample (and a few others) were what caused me to think deadbeef is able to extract covers with ffmpeg.
@goo...: Thanks, I'm not really using opus as my main format on PC (maybe mobile, if battery times get better), but due to a misunderstanding decided to report a bug which turned out to be not a bug...
Comment #9 originally posted by Alexey-Yakovenko on 2014-05-30T17:57:15.000Z:
this file contains APEv2 tag, which contains embedded cover art. this is supported by deadbeef.
Comment #10 originally posted by Alexey-Yakovenko on 2014-05-30T18:22:27.000Z:
So does this file: https://dl.dropboxusercontent.com/u/19330332/%E5%BF%AB%E6%A5%BD%E5%8E%9F%E7%90%86.tak But no cover is extracted... from what I can see, both covers are jpeg, 500x500.
Comment #11 originally posted by Alexey-Yakovenko on 2014-05-30T18:27:54.000Z:
this file doesn't have "artist" field specified. as far as i remember, there is some check in artwork plugin which ignores such files.
if i add any dummy artist field into tag -- the image loads.
Comment #12 originally posted by Alexey-Yakovenko on 2014-10-02T14:19:46.000Z:
After a number of artwork plugin changes, it should behave as follows:
If might be worth looking again at how your files are working, although the underlying issue of albumart lookups through ffmpeg or any other plugin (the Opus plugin has a temporary hack in place to load METADATA_BLOCK_PICTURE tags) haven't been fixed.
As a side issue, there are several ways to remove and update incorrect artwork without going to the underlying disk cache files (although that would trigger an update). On the playlist context menu there is an item to refresh artwork. This will remove any current cached artwork and then try to look it up again. Changing the lookup preferences will invalidate all cached artwork files and cause them to be looked up with the new preferences. As a side effect, any changes to the artist or album tags will trigger a lookup of new artwork (or will switch to existing artwork for those tag values, if it is already in the disk cache) although any images in the disk cache for the previous tag values will also remain until they expire.
Original issue 1122 created by Alexey-Yakovenko on 2014-05-28T20:13:07.000Z:
What steps will reproduce the problem?
What is the expected output? What do you see instead? Expected: cover is displayed Instead: "no album art" placeholder displayed.
What version of the product are you using? On what operating system and CPU architecture? x86_64, arch linux, deadbeef-static_devel-1_x86_64 from today.
How did you install the product? Gotten for the drone.io autobuilder, extracted folder
Please provide any additional information below.