search

beetbox / beets

music library manager and MusicBrainz tagger
http://beets.io/
MIT License
12.88k stars 1.82k forks source link

EmbedArt plugin results in album art showing as "Other" instead of "Cover (Front)" #2339

Closed dannn-o closed 7 years ago

dannn-o commented 7 years ago

I have FetchArt and EmbedArt both coded in my config.yaml file, and album art is successfully being embedded in the resulting audio files. However, the album art is showing as "Other" (when viewed with a tag editor such as Puddletag or EasyTAG), as opposed to "Cover (Front)".

Supporting documentation is attached as follows:

I experimented with a few configuration changes, and also tried importing files that did not have any existing art embedded (to rule out some sort of interference), but I haven't discovered a way to avoid the "Other" classification. It may depend on the specific version, but iTunes (and the iPods being managed) seems to display the dreaded generic "grey musical note" in cases when the album art is tagged as anything besides "Cover (Front)". I am able to re-tag the images using the tag editing programs, but am hoping beets can be made to do this during import.

Thanks again for the excellent program!

dogpartybad dogpartygood 03 Dog Party (Beets import).zip 03 Dog Party (Good-Art).zip

sampsyo commented 7 years ago

Thank you for thorough documentation!

I was able to confirm, looking at the files, that you (and PuddleTag) are totally right—the type is set incorrectly. But, strangely enough, I'm unable to reproduce the problem. Importing a file and using embedart to set its art produces a file with the right type in its APIC frame.

So, I have a couple of questions:

dannn-o commented 7 years ago

I thought I had been at the most current version, but found I was behind an update. So, I upgraded from v1.4.1 to 1.4.2 just now and tried again, but found that the same issue persists. Here is my config.yaml file:

directory: ~/Music
library: ~/data/musiclibrary.blb

id3v23: yes
plugins: lyrics fetchart zero embedart scrub

import:
    move: yes
    write: yes
    log: /home/dan/Music/import-log.txt
    timid: yes

zero:
    fields: comments

lyrics:
    force: yes

As for your 2nd question/request, I had done something similar in my initial testing by running the album through Audacity to change the bit rate (Audacity strips out many of the file's tags, including album art). But, I went ahead and attempted what you requested. The beet clearart command removed the embedded art successfully. After that, I first ran beet embedart to see if that would be enough, but received the error: embedart: No album art present for Scott Henderson - Dog Party

Next, I ran beet fetchart, hoping it would find the necessary album art online, but received the error: fetchart: Scott Henderson - Dog Party: no art found

So, what I did next was use EasyTAG to extract the album art from one of the files in my master library (which has the correct Cover (Front) tagging), and saved it into the test directory with the rest of the audio files and named it "album.jpg". Running beet embedart without any parameters wasn't enough, I found, so I ran this: beet embedart -f "/home/dan/Music/Scott Henderson/Dog Party/album.jpg"

After the above command, I found that the art work was successfully embedded in the audio files with the correct "Cover (Front)" tag showing in both puddletag and EasyTAG!

One additional thing I felt was worth trying that I did next: I ran the beet clearart command again to clear the art work, and then ran the entire album through the beet import process again. However, I found the resulting files did not include any album art afterward (which was surprising to me, because I thought it would embed the art work, even if giving it the "Other" classification again).

I didn't want to try any more scenarios until you've had a chance to review/comment on the above. Let me know what might help next.

sampsyo commented 7 years ago

Huh, that's odd! It's not 100% clear to me, then, when the embedart plugin touched your files at all—if the art didn't come from fetchart (which apparently can't find album art for that album), when did it have occasion to embed new art into the file?

Another way to ask this is: if you start with known-good files (art type: cover), import them into beets now, and then examine them, do they go wrong (art type: other)? If so, can you include the verbose log from an import that does exactly that?

dannn-o commented 7 years ago

Yes, if I take the folder of files with good album art (tagged as "Cover (Front)"), and then import it into beets, the album art then shows as "Other" afterward. I am attaching a file ("beets_verbose.txt") with verbose output from that import command, as you requested.

I re-ran the album again through Audacity and performed an import, and I guess I was mistaken about what I thought it did initially. The resulting files did not have any album art included, similar to what happens when stripping out the art using beet clearart before the import. I'm not sure how I missed that. Anyway, I am hoping to try a few other scenarios in the next few days, but please let me know if you'd like me to test anything in particular. beets_verbose.txt

sampsyo commented 7 years ago

OK, thanks! I know this is a little fiddly, but if you get a chance, could you try that with -vv instead of -v (two verbose flags)? That will get additional information from plugins.

I also noticed you have the scrub plugin enabled. That might be to blame here—can you also try disabling that to see if there's any effect?

dannn-o commented 7 years ago

Your instincts were right: disabling the scrub plugin prevented the embedded album art from being retagged as "Other" during the import. I am attaching -vv output ("beets_very_verbose.txt") from an import done with the scrub plugin enabled, in case it helps you further with trouble-shooting. When I remove "scrub" from the config.yaml, the resulting files after import continue to properly show the album art as "Cover (Front)" beets_very_verbose.txt

With regard to the fetchart plugin: I'm curious why it failed for the 2 attempts (see lines 79 & 81) to download from coverartarchive.org? When I copy the URLs directly into a browser, the correct album image does seem to be displayed, after a bit of redirection (http://ia600307.us.archive.org/25/items/mbid-b290b142-6611-46a2-9fd4-a268190cda46/mbid-b290b142-6611-46a2-9fd4-a268190cda46-10495208921.gif). Any ideas?

sampsyo commented 7 years ago

Cool! I found the problem in scrub, and I think I fixed it. Any chance you can give this latest version a try?

Here's the clue from your log about the CAA files:

fetchart: trying source coverart for album Scott Henderson - Dog Party
fetchart: downloading image: http://coverartarchive.org/release/b290b142-6611-46a2-9fd4-a268190cda46/front
fetchart: not a supported image: image/gif

The fetchart plugin only accepts JPEGs.

dannn-o commented 7 years ago

Be glad to test it out. Just to confirm: Should I follow the steps in the FAQ for "How do I...run the latest source version of beets?"

And, thanks for clarifying about .gif not being a supported image format...guess I missed that. I won't bother asking for that feature as an enhancement, as I noticed the explanation you gave with issue #1588 in ver 1.3.15. :o)

P.S. Sorry I threw EmbedArt under the bus in the issue description, instead of scrub.....

sampsyo commented 7 years ago

Be glad to test it out. Just to confirm: Should I follow the steps in the FAQ for "How do I...run the latest source version of beets?"

Yep!

P.S. Sorry I threw EmbedArt under the bus in the issue description, instead of scrub.....

No worries! Attributing the root cause of a problem is often the hardest part.