Support for fetching & embedding album art would be great!

Embedding where? In the FLAC file or as a jpeg in the directory?

Also, does CDDB support album art these days or how would you obtain the information? (fwiw, musicbrainz should have the info we need).

I meant embedded as tags in the mp3/flac/whatever. Other people would probably be happy with a .jpg in the album directory.

If I could find a command-line tool for finding & embedding, I'd tackle the abcde script mods myself. But I've had no luck.

Do you know if there is a standard way how people encode cover art as tags with mp3/ogg/flac?

For MP3s there is an id3v2 'APIC' tag that is used. I don't know about the others.

I have many MP3s with album art inserted by various graphical tools. Here's the id3v2 output of one:

$ id3v2 -l 01* id3v1 tag info for 01.Whatever.mp3: Title : Whatever Artist: Ani DiFranco
Album : Living In Clip (Disc 1) Year: 1997, Genre: Unknown (255) Comment: Track: 1 id3v2 tag info for 01.Whatever.mp3: TALB (Album/Movie/Show title): Living In Clip (Disc 1) TPE1 (Lead performer(s)/Soloist(s)): Ani DiFranco TIT2 (Title/songname/content description): Whatever TYER (Year): 1997 TRCK (Track number/Position in set): 01/16 APIC (Attached picture): ()[, 0]: image/png, 202738 bytes

I've also seen "image/jpeg".

Thanks for the info. BTW, I should point out that I'm not an abcde developer; just an interested bystander.

I'm working on MusicBrainz support for abcde at the moment. With this, you can obtain the Amazon ASIN and then download the covert art from Amazon. I've done this yesterday (will publish patches soon).

So maybe you could figure out the best way to embed the image once it's downloaded.

And just to confirm, does this embed the cover art into every MP3?

I cannot figure out how to do it with id3v2, but eyeD3 can do it:

eyeD3 --add-image foo.jpg:FRONT_COVER bar.mp3

If you just want the album art in the directory, there are two simple(ish) ways of doing it.

1) Screen-scraping albumart.org using this script http://www.ludicrous-speed.com/wiki/index.php?title=How_To_Download_Album_Cover_Art 2) Using the AllCDCovers.com API http://www.allcdcovers.com/api 3) Using the FreeCovers API http://www.freecovers.net/api/

The screen scraping is probably the easiest to integrate - although I'm not sure the above script works reliably. AllCDCovers requires API signing FreeCovers is probably the easiest to implement.

Not sure how to deal with multiple hits - unless using ASCII art is a possibility ;-)

!/bin/bash -e

freecovers.sh

#

This script fetch the cover art for the album path provided on the command line.

It will download the cover art from freecovers.net, and place it into the album path.

#

Usage

freecovers.sh

freecovers.sh The\ Beatles/Get\ Back

The path passed as an argument

dpath="$1"

Escape any special characters

encoded="$(perl -MURI::Escape -e 'print uri_escape($ARGV[0]);' "$dpath")"

FreeCovers doesn't like the %2F (/) so let's just replace it with a %20 ( )

corrected=echo $encoded | sed s/2F/20/g

If the cover already exists, skip

if [ -f "$dpath/cover.jpg" ] then echo "$dpath/cover.jpg already exists" exit fi

Let the user know what's going on

echo "" echo "Searching for: [$1]"

Full documentation http://www.freecovers.net/api/

url="http://www.freecovers.net/api/search/$corrected/Music+CD" echo "API Call [$url]"

Very lazy. Look for the first big.jpg

There may be multiple covers returned - this only grabs the first one

coverurl=wget -q -O - "$@" $url| grep -o -m 1 -i 'http:\/\/www\.freecovers.net\/preview\/0\/[a-z0-9]*\/big.jpg' echo "Cover URL: [$coverurl]"

Save the file

wget "$coverurl" -O "$dpath/cover.jpg"

Here is the patch against abcde-2.4.2 with basic cover download functionality (no cover embedding) it adds "cover" to list of supported actions. Cover download utility itself is based on Google image search and is very dumb.

Is there a better way to do the lookup? It sounds a little scattershot...

Good afternoon. I have written a patch to abcde2.5.4 to perform album art downloading. It gives the end user the chance to provide a path or url to appropriate cover art (it does not do the searching for the user). If the user enters a path or url the image file will be downloaded and saved in the target folder (the same one as the play list is used). It also embeds the image into an APIC tag on every mp3 file (I have not yet done the other formats). I have tested that an album ripped to mp3 with cover art included imports and reners correctly within iTunes version 11. I've attached my patch here but I will also a patch emails to the mailing list.

Further to my comment yesterday, I now have this working for Flac and Ogg Vorbis tagging of album art.

Further to my comment yesterday, I now have this working for Flac and Ogg Vorbis tagging of album art.

Can you attach your latest patch?

Here's the latest patch. I've also put my repo up on Github in case it helps: https://github.com/johnlane/abcde.git

+1 here. But all I'd like is for abcde to grab the cover art if possible, since verifying the cover.jpg is dependent on X/Xorg!

Some people might not want the cover.jpg to be embedded within the tags as it will make the filesize larger.

Preferably, I just grab the cover.jpg from the Internet and copy to the root folder of the album as cover.jpg. From here, most computer software players will recognize this. Portable (OGG/MP3) devices might not be able to view the (embedded) cover.jpg due to having no graphics capability. Also, some players may encounter streaming or playback issues because of the added file size. A good example of this is audiophiles having issues playing back FLAC vs WAV/PCM files. ;-)

Musicbrainz has metadata for album art now, linking to archive.org. It's well integrated into the website.

I have written a patch against abcde 2.6 release that will automatically download the corresponding album cover and place it in the output directory.

Since everything in the old comments of this issue seems more or less outdated or not functional I totally started from scratch.

Download is taking place in up to three steps:

1) if CDDBMETHOD is musicbrainz, cover is downloaded from coverartarchive by MBID 2) if 1 fails, download is tried from amazon by ASIN 3) if 1 and 2 fail or CDDBMETHOD is cddb, album will be downloaded using glyrc by artist + album title.

While 1 and 2 are more or less 100% reliable to fetch the right image, musicbrainz does not have covers for all CDs in their database. glyrc is a great tool for textual album art search and supports many sites, but by its nature it will not always get the right image. In total this 3-step approach works very well even for more "exotic" CDs.

Since I could not find any coding guides for abcde, I tried to write the patch as much in the style abcde has been done. I tried to keep things as simple as possible - I'm a great fan of the KISS approach.

A few lines have been added to musicbrainz-tool to save MBID and ASIN to tmp files. abcde.conf gets a new action 'getalbumart' and options for glyrc. A new function do_getalbumart() is introduced to abcde as well as the stuff around to check dependencies etc.

Patch #18 looks very nice, thanks! Can this be merged in the next abcde release?

ShellCheck says it's good, except for the mention of the unquoted $GLYRCOPTS variable. (Likely an expected unquoted variable.)

I haven't tested the patch, and only copy/pasted the main function into ShellCheck.

Thanks for the feedback. There was a reason why I removed the quotes around $GLYRCOPTS which I had quoted originally. glyrc didn't like it. So I ended up with the command call being

$GLYRC cover --artist "$ARTISTFILE" --album "$ALBUMFILE" --write "$ABCDETEMPDIR/$ALBUMARTFILE" $GLYRCOPTS

Any hints on how to solve this?

As far as I know, this lack of quotes isn't a problem but merrily a warning or advisement by ShellCheck as long as this is the desired result. Shrugs.

The quoting syntax also commonly seen is using both curly braces and double quotes, such as "${VARIABLE}".

I also have shell scripts where sometimes (albeit rare) the desired variable content results are created by not using or avoiding quoting, or using single quotes.

In your case, it sounds like the defacto elsewhere within abcde.sh to avoid using quotes with the OPTS variable.

curly brackets don't help. Neither does changing GLYRCOPTS to use single quotes. Also, quotes cannot be omitted in the variable definition.

Anyway, if you give the entire abcde into shellcheck it will complain about the same error hundreds of times. That of course does not yet justify it, but I see there are many places where quotes are omitted in command calls probably for exactly the same reason. I guess we can live with that.

What I really want to know - how do people out there like the functionality? Does it work fine for you?

Yup. The quoting issue was already recently discussed on the new mailing list.

What I really want to know - how do people out there like the functionality? Does it work fine for you?

Exactly. ;-)

I can see that there has been a lot of work in this patch! Can you remake the patch against current git? There are hopefully many using the current git who may be interested in testing this out.

I admit that I am myself more interested in this idea of downloading album art rather than downloading as well as embedding...

Personally I prefer to just download the cover without embedding. Many players support the "have a cover.jpg in the album directory" method. Also many UPNP servers do and picture will show up in the client.

Embedding just blows up the file size. And what sense does it make to have a dozen tracks in an album each containing the same image tag? Still if anybody wants to have that they are welcome to deliver another patch for that purpose.

OK, I'll do the patch + testing against current git after the weekend.

Thanks for going to this trouble. I have finished my self-appointed task of bringing aac encoding to abcde and I am keen to see the album art downloader in action :).

Ditto. Usually ".cover.jpg" or cover.jpg is sufficient for my needs or wants.

From what I hear, most hardware players are known to break when playing embedded image music files and usually considered an eccentric file format.

Besides the album image is something rarely viewed (but nice eye candy) while playing, making a separate file more than sufficient for most people. Notice I use a dot format so that players do not try playing the image file, but dot name format probably isn't really necessary.

I have converted abcde-2.6-albumart001.patch to work against the current master in git.

Comment deleted

I have added 3 new features to this patch: 1) inspecting the downloaded image using identify from ImageMagick (when available) 2) ability to manually enter an URL to download 3) converting non-JPG images from manual download to JPG using convert from ImageMagick (when available)

Fixed a small typo in the patch.

I hope to have a good look at this on the coming weekend, my day job precludes before then I'm afraid :(.

OK, Richard already did the patch against current git, so I don't have to do that anymore. abcde-git-albumart002.patch looks like it is the equivalent of abcde-2.6-albumart001.patch but I haven't tested it yet.

Concerning the other additions:

The interactive part ignores the non-interactive mode of abcde. This breaks automatic use. Needs fixing.

Using imagemagick identify to display image information is nice. But I guess what you would really want is to actually display the downloaded image to be able to see if you got the right one. That will probably get you into platform dependencies.

Manually entering a url is OK, but at this point you are already looking into your web browser. It seems more likely to me you would directly save the image you see in your browser to the destination directory with a mouse click than copying the url into abcde. Still it's a feature if you already have the image.

Using the extension to determine the file type is very unreliable. You should rather check the mime type. This will also save you from struggling around with url basename etc.

I hope I am not passing to much criticism. I just think some more work needs to be done here. And I am really happy about the unexepected lots of feedback. It's not only that I would like to keep things as simple as possible. It's also that testing, integration and later maintenance will be much easier if we go stepwise. Therefore I would rather suggest to first integrate abcde-git-albumart002.patch after thorough testing. In the meanwhile we could do other patches incrementally, discuss the conceptual stuff and add them later.

concerning imagemagick convert: I had previously taken it into account. But then I ended up with coverartarchive delivering jpg trough it's web interface (though documentation is vague about this). Amazon always having jpg. And glyrc being able to search only for jpg. So I did not consider conversion necessary.

I am totally fine with committing abcde-git-albumart002.patch first, and doing the other parts later.

I will fix the non-interactive mode, good point.

Instead of using extensions (or mime/type) I will just use identify since we are relying on ImageMagick anyway. That seems the most robust.

Personally I find copy-pasting a URL much easier than saving an image and copy-pasting it's local path. Currently the code supports both though.

This patch addresses the issues above and is a diff against abcde-git-albumart002.patch so they can be applied seperately.

I have had a quick mid-week look at abcde-git-albumart002.patch and I have to say it was magic seeing the album art appear :). A few small issues could do with a look at:

1. Some logging to $ABCDETEMPDIR/status would be nice
2. Testing with multiple OUTPUTTYPE settings shows album art only in the first OUTPUTTYPE, nothing in the others

Thanks to the obvious effort being put into this area...

1: I've added get-album-art=$ALBUMARTURL to the status file. Should we also check this is already in the status file and skip the function if it is? 2: files for different OUTPUTTYPE only end up in a different place when you use OUTPUTTYPE in OUTPUTFORMAT or VAOUTPUTFORMAT. So I made a loop for copying the album art for all OUTPUTTYPE types. Makes sense?

This patch is a modification of abcde-git-albumart002.patch only, and does not include the manual override stuff I did before.

I haven't yet tested abcde-git-albumart005.patch, but so far it looks good and addressed both tiny issues pointed out by Andrew. Thanks! The multiple OUTPUTTYPE code looks pretty much like taken from do_move() so it should work as expected. I'll do some testing later.

Concerning Richard's questions: 1: checking would make sense when you continue an aborted rip, but I'll leave this up to Andrew 2: I guess it does make sense since players and UPNP / DAAP / whatever servers will look for the file in the same directory where the music is. Ripping in multiple formats is already redundant, so I wouldn't worry about duplicate images in that case. You could of course use symbolic links, but not all filesystems support it. Oh just forget about it :-)

Running nicely here, I am currently encoding to multiple formats using the ancient ripper dagrab: 'Dark Side of the Moon' and I see the album art sitting there nicely :).

I note that in status I get only:

get-album-art=

with $ALBUMARTURL omitted. I have not investigated atm as I am caught up in the Real World for a while ....

Hmmm... the only thing that makes me cool off a little on the whole idea is that the album art seems more than a little random at times. glyrc seems to find the correct art in only about 50% of cases. Is this your experience as well?

A couple of posts above I see:

'Using imagemagick identify to display image information is nice. But I guess what you would really want is to actually display the downloaded image to be able to see if you got the right one. That will probably get you into platform dependencies.'

But what about imagemagick's 'display' command?

Using ImageMagick's display is not a bad idea. It gives a decent error message when DISPLAY is not set. I guess we only should try to call it when in interactive mode, and pause for a manual-override Y/N prompt while the user is examining it.

Let me know and I'll code that up.

In the meantime, I've fixed the issue with the empty get-album-art= when glyrc is used in the attached (full) patch.

This patch builds on abcde-git-albumart006.patch and adds identify, display, manual entering an URL and converting the manually downloaded image to JPG.

Andrew: "Hmmm... the only thing that makes me cool off a little on the whole idea is that the album art seems more than a little random at times."

Ditto from my experience a year or so ago using those automated image grabbers. I had better luck finding album art using Google Images, and then selecting the best image resolution. Most times the image would be the first and most popular image, and about 30% of the time the image would be further away from the first or top slot; if even present sometimes. (Unique tastes of music sometimes.) Also depends on the popularity of your music choice or genre. The more finesse (and unpopular) your tastes in music, the more likely you're album art is not in the top or first slot. (Another factor is the age or era of music.)

Using ImageMagick's display will depend on X, whereas abcde as a whole currently does not. You could also experiment with using something like an image to ascii filter. But it must likely be noted to packagers, that they'll now need to pull in X as a runtime dependency for ImageMagick's display command. Using an image to ASCII filter, might be all you need for simple verification. Albeit, might need to first magnify the image somehow before sending to stdout?

I'm not at all against using ImageMagick's display, and recognize some features do need X.

So, "if pidof X, then ImageMagick display $IMAGE; else pipe $IMAGE through image to ASCII?"

And I guess don't forget about Wayland users, etc?

Then you also have to worry about people using something a desktop such as DWM, where mouse pointer focus might be lost.

Sigh! ;-)

display: that sort of trouble is what I meant when I was pointing to 'platform dependencies' :-)

'little random': I strongly recommend using CDDBMETHOD=musicbrainz in combination with getalbumart. This actually should go into some documentation. If coverartarchive or amazon have the cover image, then it is almost 100% sure to be the right one.

glyrc is only used if neither one has the image oder if you don't enable musicbrainz. Still you can restrict it with GLYRCOPTS to your preferred choice of database. Personally I made the best experience by using only slothradio.

The 'random problem' is actually the reason why I wrote this patch from scratch. I had been using a different solution in the past which I never published because of the possible unreliability.

OK, we are discussing two independant patches at the same time now.

1) basic getalbumart patch 2) Richards additions to it

2 is currently being worked on. What about 1? Everything OK with that?

I think abcde-git-albumart006.patch is good enough to be committed. My additional patch might need some more work/discussion. Should I open a new issue for it?

The last version had a silly bug where $DISPLAY=display was overriding the X $DISPLAY.

Please note that currently there no hard dependency on ImageMagick or X. Everything will work just fine without them. I would suggest recommending ImageMagick which in turn will depend on X11.

I have to admit there are a lot of patches here :). And we have a southern vs northern hemisphere time delay when looking at them...

Give me a little while to have a good look at abcde-git-albumart006.patch, I would like to get Steve to cast an eye over it as well before definitively committing abcde to album art.

Having said that I like the idea and the possibility of opening up a new area for abcde users...

And I have had a look at abcde-git-albumart-manual-003.patch which is working very nicely on my system!

OK so if Steve is still afk I will commit abcde-git-albumart006.patch next weekend. My plan would be:

1. Commit abcde-git-albumart006.patch as 'Album art part 1' in a few days (Friday).
2. Have a good look abcde-git-albumart-manual-003.patch and commit a worked on version of this as 'Album art part 2'. Perhaps a week later...
3. Write and commit the documentation for album art as 'Album art part 3'. I am happy to do this part.

For the first patch I should acknowledge j.gernemann (or other name?) as the submitter and original creator with subsequent input from Richard. Happy with this? As far as I am concerned we can continue to work on this within this issue report (Issue 33) until all is complete, then I will close...

Then I will return to pottering about with adding True Audio encoding to abcde :)

I am totally fine with this. Forgot to sign the original patch off though.

abcde-2.6-albumart001.patch as in comment #18 Signed-off-by: Johannes Gernemann

For changes in abcde-git-albumart006.patch credit goes to Richard.

I am very happy to see this being committed soon. Thanks to all of you for the work and the great support!

First commit in place, thanks Johannes and Richard! I hope to have a good look at Richard's additions to getalbumart on the weekend and I would love to hear any thoughts for further enhancements of abcde-git-albumart-manual-003.patch.

My only comment so far with abcde-git-albumart-manual-003.patch is that when using 'display' to see the image the use of 'identify' to give a commandline summary seems a litle redundant. Thoughts? I can see that further down in the patch 'identify' will still be used to assist with interrogation of the album art and possible conversion to jpg...

And another thought: it would be nice to see some options for the display command, i.e:

$DISPLAYCMD $DISPLAYCMDOPTS "$ABCDETEMPDIR/$ALBUMARTFILE" >&2 &

with suitable additions to the conf file etc. This would allow access to options such as resize and verbose. I personally would use resize to get a guaranteed image size for viewing (which of course does not actually write the changes to the image) and verbose to mimic the use of 'identify' currently used. Many other options for the commandline enthusiast...

On my sytem:

DISPLAYCMDOPTS='-verbose -resize 512x512 -title "abcde album art"'

Andrew, thanks for the commit. About 'identify' and 'display' - once you install imagemagick you have all of the commands. I guess it won't hurt using both?

Richard, I would also appreciate options in form of DISPLAYCMDOPTS and also something like CONVERTCMDOPTS to give abcde.conf an option to select covert art size, format etc.

Even if it's most likely that jpg will be the image format, it would also be nice to allow conversion to the user's choice and also when non-interactive. Maybe the 'convert' part could actually be moved down a few lines into the 'copy to target directories' section. And not be fixed to jpg. What do you think?

Supporting DISPLAYCMDOPTS and CONVERTCMDOPTS sounds good to me. I realized that some players only support a maximum image size. That could be handled as well. I'll see if I can implement this over the weekend.

This patch incorporates the above suggestions. I used CONVERTOPTS and DISPLAYCMDOPTS because DISPLAYCMD only adds CMD to not conflict with the X11 $DISPLAY variable.

It also removes the default GLYRCOPTS="--formats jpg;jpeg" (since we will now convert to JPEG) and moves the default ALBUMARTFILE="cover.jpg" to the correct place.

A few rough spots with this one, does it run on your system? Bracket problem at beginning:

if new_checkexec $DISPLAYCMD && [ "$DISPLAY" != ""]; then ^^

Hmmm... and I am having trouble getting the escapes right with the display 'title' option...

With offending bracket moved and my offending display options removed all is well, for the life of me I cannot get the space in the 'title' option to work!

Looks like the -verbose option with 'display' + & causes an odd terminal output as well. Remind me never to suggest options again :)

I see what you mean. I now use identify instead of "display -verbose". Also I cannot get spaces in "display -title 'abcde cover art'" to work. I replaced them with underscores.

I realized that convert was only called when a type conversion was needed, so I introduced ALBUMARTALWAYSCONVERT to use convert for thinks like resize and colorspace conversions. Also fixed a few typos.

Richard that patch is looking truly amazing! Working very nicely here as well.. I have only a few comments about the initial identify command:

1. Do you think this should be introduced with a suitable echo comment? It pops up quite suddenly.
2. At the risk of exciting the commandline fiddler too much what about identifyopts? There is a nice -format option that I started to have a look at but it is very late at night here :(.

But these are only small points, overall it is looking very exciting. Interested to hear what Johannes has to say if he is still around.

Thanks Andrew, I have been using a custom patch for this for a few years. I'm pretty excited it's actually gonna land now.

1. Makes sense, and text suggestions?
2. I am so used to type "identify foo.jpg" that I never looked at the options. Offering IDENTIFYOPTS makes sense though. I'll add it.

OK, a lot going on here... Looks very nice so far. I will do some testing around the weekend. Just from looking over the patch:

I am getting ab bit confused about lots of variables and names. Maybe a bit of renaming could help? I'd kind of like something like IMGCONVERT instead of CONVERT etc. But then of couse this could be confused with 'image' in the meaning of 'CD iso image'. Any better ideas?

Anyway, this will need some good documentation. Maybe someone could start writing some notes now and make a list of what we already have for album art? Then it might be easier to discuss.

Also a bit inconsistent: there is ALBUMARTTYPE="JPEG" but CONVERT target format depends on ALBUMARTFILE="cover.jpg" extension...

Image should only be displayed in interactive mode. This is important for automatic ripping.

I also tried to get display -title to work, but nothing help (single or double quotes, escaping...) That's a pity because I would like to see the disc title as the window title :-)

OK, good work. Hope to see some more improvements soon.

I agree about the documentation, I'll try to start on that.

I tried to keep with the abcde naming conventions where possible. Variable for commands are capitalized, adding OPTS for options.

The ALBUMARTTYPE="JPEG" comes from how identify displays the JPEG format (JPG is just a Windows abbreviation) while cover.jpg is what most player recognize.

If you are going to test, please use this patch which has IDENTIFYOPTS and a small bugfix for the second identify call.

Comment deleted

Comment deleted

Some nice convert options here:

http://stackoverflow.com/questions/7261855/recommendation-for-compressing-jpg-files-with-imagemagick

-strip -interlace Plane -gaussian-blur 0.05 -quality 85%

This altered an admittedly monstrous albumart file from 2.1mb to 306kb with no discernible loss of quality. My eyes are old admittedly :).

OK I have deleted 2 of my previous posts to do with the abcde FAQs and attached the almost complete (updated) document to this post. This will be added in to the existing FAQ that ships with abcde.

The man page I will fix after Richard's patch has been committed.

I am open to comments...

Added an explanation for ALBUMARTALWAYSCONVERT... Running a few tests today but Richard's patch is looking close to commit?

Sequence adjusted in suggested conf file + white space adjustments...

Richard, a small issue I have found with the manual download of album art. There is no error checking so if an incorrect url or local link is given there is a welter of complaints from identify, convert and friends but nothing definitive to say: Malformed url. Any thoughts?

Andrew, thanks a lot for the documentation. This will help a lot.

Richard, thanks a lot for all the good work. With latest git + abcde-git-albumart-manual-006.patch I still think image should only be displayed in interactive mode.

Comment deleted

Thanks Andrew, the documentation looks really good.

I have moved the display (and identify) inside the INTERACTIVE block. I've also added some echo's when the HTTPGET/cp fails. Should we restart the dialog when this happens? Also, should we redirect stderr of HTTPGET and cp to /dev/null ? Personally I think those errors will provide useful information on why the download or copy fails.

Hmmm.. a midweek quick look at album tagging: I am trying to write a post_encode function to change to the appropriate mp3 directory and run:

for i in *.mp3 do eyeD3 --add-image cover.jpg:FRONT_COVER "$i" done

as an example for actually embedding the image. This for the FAQ document... Anybody tried anything like this?

Hoping to have a proper look at the weekend, work is busy this week :(

And a final mid-week comment! Looks like only smaller issues now that can easily be dealt with as they come up, I would like to commit this weekend and then add the docs. After that I will close this issue and deal promptly with any enhancements to getalbumat as they are posted to googlecode (until it closes for business!!).

And I would like to say a big thanks to Richard and Johannes for the amazing work on this issue! Good to see in the closing years of the audio cd that abcde still attracts quality work...

Borrowing liberally from Richard's syntax the following in an mp3 ~/.abcde.conf should embed images:

--------------------

post_encode () { ARTISTFILE="$(mungefilename "$TRACKARTIST")" ALBUMFILE="$(mungefilename "$DALBUM")"

if [ "$VARIOUSARTISTS" = "y" ] ; then FINDPATH="$(eval echo "$VAOUTPUTFORMAT")" else FINDPATH="$(eval echo "$OUTPUTFORMAT")" fi

TRIMPATH="$(dirname "$OUTPUTDIR/$FINDPATH")" cd "$TRIMPATH"

if [ -f "cover.jpg" ] then for i in *.mp3 do eyeD3 --add-image cover.jpg:FRONT_COVER "$i" done mkdir backup mv cover.jpg backup else vecho "No album art found so no image embedded..." >&2 fi }

--------------------

Similar should work for flac with the substitution of the for loop with:

--------------------

for i in *.flac do metaflac --import-picture-from=cover.jpg "$i" done

--------------------

I will fine tune this a little and write it up in the FAQ for those who wish to embed as well...

I attach the FAQ update with mention of the new -G option for getalbumart (which I have quietly committed) and the example post_encode function for embedding the album art at a user level.

This should do it for the FAQ, any more information there and it will get a little unwieldy...

Still playing with the function...

All commits in place and I will now close this issue. Please let me know of any problems or any future enhancements, probably best in a new 'Issue'.

I have been running the full 3 patches for a week now and I believe that the changes have given abcde a new breath of life. Thank you Johannes and Richard for all of your hard work!

abcde 2.7 released today and the jewel in the crown is album art downloading :)