Created attachment 99 [details] debug log output Using abcde 2.9.4 on CentOS 7 I have ripped about 500 discs in the past 3 weeks on an old PC, 2-core with 2 CD-ROM drives. I am ripping and encoding as MP3 with album art, so I can more easily listen to my music in the car and see the album cover on the car screen. My car only supports ID3v2, and mp3 files are approx 10-20% the size of originals. Quality not so important with road noise. The one odd thing I have noticed is that I need to disable automatic CD eject. What I have observed is that the encoding to mp3 can take longer than ripping the CD to wav file on disk. When disc is ripped, abcde will continue to run encoding in the background. When the file has mp3 tags added, the file is copied as track01.mp3 to “10 Somewhere Over the Rainbow.mp3” - the munge function is run again so track can end up as “10 Over the Rainbow.mp”. Artist name is also re-munged, so artists with one word names, e.g, U2, end up as empty, so dir looks like “OUTPUTDIR//Baby” when is should be “OUTPUTDIR/U2/Achtung Baby” and the track names are also wrong. Separately, I have had issues with eyeD3 to tag files. I use id3v2 for tagging and eyeD3 to add album art as I have been using it for this purpose for a while. I haven’t tried to use id3v2 for the art yet, but will try later. I have also had mixed results with album art. Album details have been okay but album names can include record company name and catalogue number so lookup fails to find art. I have been able to retrieve album art on either discogs or musicbrainz
Created attachment 100 [details] abcde.conf file
OK, I took a look at this... ...and I'm confused. **WHY** did you put a call to read the CD TOC in your mungefilename??? Re-reading the CD TOC is the reason for all the problems you described. using the jools-lift-the-lid.txt attachment: disable CD eject: in post_encode (which is run after the CD is ejected), you use mungefilename and there is no CD to read. long processing time: for that album, you re-read the CD TOC 45x. wrong names: when you use mungefilename after the CD is ejected, FIRSTPART is blank. Now when you pass the echo string to munger.py, it uses the "first word" of the string as FIRSTPART and whatever is left as the "name". regular use: +++ echo ce0adc0d 13 150 14937 29927 49080 65860 77235 92550 114527 134107 148892 167127 177617 195112 2782 ++ FIRSTPART=ce0adc0d ++ /home/doodah/dev/munger.py ++ echo ce0adc0d 'Lift the Lid' + ALBUMFILE='Lift the Lid' no CD use: +++ echo ++ FIRSTPART= ++ /home/doodah/dev/munger.py ++ echo 'Lift the Lid' + ALBUMFILE='the Lid' FIRSTPART is blank. echo sends to munger.py. munger.py uses "Lift" as the FIRSTPART so "the Lid" is used as the ALBUMFILE. and for your "U2" example, U2 is used for FIRSTPART and there is nothing left to use for ARTISTFILE... so it's blank. Now, the simple fix for this: the disc ID is one of the first things that abcde needs. it is calculated and put in CDDBDISCID. and for that album it's "ce0adc0d". so, change your function from: mungefilename () { CDDISKID=$(cd-discid "$CDROM") FIRSTPART=$(echo $CDDISKID | cut -d' ' -f1) echo $FIRSTPART "$@" | /home/doodah/dev/munger.py } to: mungefilename () { echo $CDDBDISCID "$@" | /home/doodah/dev/munger.py } and it should all work. The "encode and tag" part should run at least 20x faster now.