Closed reprise5 closed 2 years ago
Please upgrade eyeD3 to the lastest version (eyeD3 0.6 is 6+ years out of date) and attempt to reproduce.
Okay, So this old version 0.6.18 is a problem with the version of eyeD3 in the apt package database (at the time I installed it), and it appears it's still a bit behind, But it's what I expect of Debian Stable.
Sorting... Done
Full Text Search... Done
eyed3/stable,now 0.7.10-1 all [installed]
Display and manipulate id3-tags on the command-line
python-eyed3/stable,now 0.7.10-1 all [installed,automatic]
Python module for id3-tags manipulation
I got version 0.8.5 through python-pip, and can confirm the problem still persists. According to the release history notes, this should be the latest. Here's the latest log:
$eyeD3 -t "title" -a "友 & 愛" Multiverse.mp3
/home/reprise/Desktop/Multiverse.mp3 [ 5.50 MB ]
----------------------------------------------------------------------------------------------------
Setting artist: 友 & 愛
Setting title: title
Time: 11:57 MPEG1, Layer III [ 64 kb/s @ 44100 Hz - Stereo ]
----------------------------------------------------------------------------------------------------
ID3 v2.3:
title: title
artist: 友 & 愛
album: Particle Void
eyed3.id3:WARNING: Invalid numeric genre ID: 2018
track: 1/87
FRONT_COVER Image: [Size: 49053 bytes] [Type: image/jpeg]
Description: a1380472194_16.jpg
Writing ID3 version v2.3
Uncaught exception: 'latin-1' codec can't encode character u'\u53cb' in position 0: ordinal not in range(256)
eyed3:ERROR: 'latin-1' codec can't encode character u'\u53cb' in position 0: ordinal not in range(256)
Traceback (most recent call last):
File "/home/reprise/.local/lib/python2.7/site-packages/eyed3/main.py", line 277, in _main
retval = mainFunc(args, config)
File "/home/reprise/.local/lib/python2.7/site-packages/eyed3/main.py", line 50, in main
fs_encoding=args.fs_encoding)
File "/home/reprise/.local/lib/python2.7/site-packages/eyed3/utils/__init__.py", line 95, in walk
handler.handleFile(os.path.abspath(path))
File "/home/reprise/.local/lib/python2.7/site-packages/eyed3/plugins/classic.py", line 513, in handleFile
max_padding=max_padding)
File "/home/reprise/.local/lib/python2.7/site-packages/eyed3/id3/tag.py", line 825, in save
self._saveV2Tag(version, encoding, max_padding)
File "/home/reprise/.local/lib/python2.7/site-packages/eyed3/id3/tag.py", line 1032, in _saveV2Tag
max_padding)
File "/home/reprise/.local/lib/python2.7/site-packages/eyed3/id3/tag.py", line 948, in _render
raw_frame = f.render()
File "/home/reprise/.local/lib/python2.7/site-packages/eyed3/id3/frames.py", line 294, in render
self.text.encode(id3EncodingToString(self.encoding)))
UnicodeEncodeError: 'latin-1' codec can't encode character u'\u53cb' in position 0: ordinal not in range(256)
Seems environment or a difference in the tag in the file you are using. Here's what I see with your example:
└> eyeD3 -t "title" -a "友 & 愛" ./test.id3
/home/travis/devel/eyeD3/git/test.id3 [ 366.00 Bytes ]
--------------------------------------------------------------------------------------------------------------------------------------
Setting artist: 友 & 愛
Setting title: title
ID3 v2.4:
title: title
artist: 友 & 愛
album: Drei Haselnüsse für Aschenbrödel
track:
Writing ID3 version v2.4
--------------------------------------------------------------------------------------------------------------------------------------
Hm That's interesting. Can you tell me more about your environment?
If I echo $LANG
, it returns en_US.UTF-8
. are you saying your terminal is using a different character set which would imply this is to blame for this issue?
For whatever reason latin_1 is being chosen as the default encoding for that new TPE1 frame, that does not happen in my environment. We seem to have similar locale settings, but here is mine:
$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
...
LC_ALL=
I just committed some additional logging to help tell a better story, see 53c2fba.
I am able to reproduce the problem tho, but differently then what is going on in your logs. In your logs the problem frame (TPE1) is brand new since does not show up in the frames that are loaded. And for new ID3v2.4 frame the default encoding should be utf8, but it is not happening in your environment.
But when the frame already exists, and has an explicit encoding any new text will be encoded per the current encoding. So, to reproduce.
$ touch issue201.id3
$ eyeD3 -a "abc" --encoding latin1 test.id3
$ eyeD3 -a "友 & 愛" issue201.id3
<BOOM>, your error
Have you tried using the --encoding
option? That will likely fix you.
$ eyeD3 -a "友 & 愛" --encoding utf8 issue201.id3
I'm interested about why latin1 is using chosen for a new ID3 v2.x frame in your environment. It is not the ideal default, not what I get.
Also, eyeD3 does have a bug here. In the very least it should not crash with a traceback. It's arguable that the frames encoding should be honored rather than "upgraded"
I followed the instructions from here to run the current version from source (which contains that commit, I checked), But ran into a small problem with some imports, partly due to my ignorance with python. I assume they're supposed to be internal modules rather than external ones?
$python main.py -t "title" -a "友 & 愛" ~/Desktop/file.mp3
Traceback (most recent call last):
File "main.py", line 25, in <module>
import eyed3
ImportError: No module named eyed3
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
...
LC_ALL =
--encoding
optionAlternatively, the option --encoding utf8
came back with a "no such option" error.
EDIT: I went through the manpage, and I guess the option is --set-encoding
. This prevented the exception from occurring.
$ eyeD3 --set-encoding=utf8 -t "title" -a "友 & 愛" ~/Desktop/file.mp3
(Sorry to keep you waiting on an update!)
Description / Reproduce Bug
eyeD3 --debug -t "title" -a "友 & 愛" ~/Desktop/testfile.mp3
Setup Information
Log/Stacktrace
From the moment the bug was caught
Traced Execution Log:
Command: $
eyeD3 --debug -t "title" -a "友 & 愛" ~/Desktop/testfile.mp3
Other notes
This could be an umbrella issue for other open issues about Characters like #195 with accented e's. I believe the offending characters in My particular issue here are the characters 友 and/or 愛.