No id3tags in mp3s are written

[MAWSpitau]

# Trying to convert a CD into mp3s

1. >abcde -o mp3
2. Starts working giving me an mp3
3. id3v2 -l <filename> says: "No ID3 tag"
4. I expected to have a Tag
5 Trying flac and ogg have tags

# Installed programms
eirloom-mailx flac lame mkcue mp3gain speex vorbis-tools vorbisgain id3 id3v2 abcde

[Adriaan van Nijendaal (adriaan-choam)]

It's a pity you did not include the version number for abcde.

I'm using v2.5.4 and I came across the same problem for a particular CD. One of the titles is "Barcarolle op.65 n°6 (extrait du Troisème receuil de chants)".

My rather large collection is old: I started using id3v2.3 with latin1 encoded tags about 10 years ago. I currently request latin1 encoded cddb info from the server and keep on tagging new music in the same way. I have written scripts that extract music, rename files, etc etc. These scripts expect id3v2.3 tags (in latin1 of course and convert where needed).

The latest version of this (excellent!) abcde ripper uses eyeD3, which tags id3v2.4 in utf8. It chokes on latin1 characters. EyeD3 error message: "Uncaught exception: 'utf8' codec can't decode byte 0xb0 in position 45: invalid start byte". abcde silently ignores the error condition, leaving me with MP3s without tags.

EyeD3 does not write (old) id3v1 AND id3v2.3, like the program "id3v2" does. I like(d) that, because old/cheap MP3 players will always understand old id3v1.

Reading the source for abcde v2.5.4, I did find "ID3TAGV=2", which switches abcde to eyeD3. Now, if CDDBPROTO is not set to 6, one might expect trouble. I feel that if eyeD3 is selected, abcde should complain when CDDBPROTO is not set to 6.

Setting "ID3TAGV=1" in my ~/.abcde.conf file fixes my problem (for now) because that way id3v2 is used for tagging and it will happily tag id2v2.3 like it always did.

[Adriaan van Nijendaal (adriaan-choam)]

See https://code.google.com/p/abcde/issues/detail?id=101 for a patch.