Artist name ist cut after the umplaut at MP3 Tags

[GoogleCodeExporter]

I am using the cureent git version - Rev. 182d3dd6ba27  Date Aug 5, 2012

The bug is fixed with the diff I attached.

1) Please describe the steps to reproduce the situation:
a. I encode a MP3 with umlaut in its artist name "Die Ärzte".
b. The artist name ist cut after the umplaut "Die " when you look into the MP3 
tag.

2) What is the expected output? What do you see instead?
I expact that the MP3 tag of the artist is "Die Ärzte" instead of "Die ".

3) What version of rubyripper are you using? On what operating system? The
gtk2 of commandline interface?
bug is in both versions

4) Is this not already fixed with the latest & greatest code? See for
instructions the Source tab above.
its not fixed

5) Does the problem happen with all discs? If not, please attach
the output of cdparanoia -Q with a disc that gives trouble.
this does not matter

6) Please explain why this change is important for you. Also, how many
users would benefit from this change?
its important for german users cause we have alot of umlauts

Please provide any additional information below. The more usefull
information provided, the sooner the issue will be fixed.

Note that ruby versions older than 1.9 are no longer supported. You are
advised to upgrade instead.

Original issue reported on code.google.com by eniak.i...@gmail.com on 9 Sep 2012 at 7:35

Attachments:

• rr_lib.rb-diff

[GoogleCodeExporter]

also see this for the output http://pastebin.com/yZGJuUZ5
The problem is not happening with off or flac (as you can see in the output)

Original comment by eniak.i...@gmail.com on 9 Sep 2012 at 7:41

[GoogleCodeExporter]

I mean ogg not off ...

Original comment by eniak.i...@gmail.com on 10 Sep 2012 at 6:05

[GoogleCodeExporter]

Converting the character set to latin will give problems with non-compatible 
character sets. So the solution is only a workaround.

The code was removed because the issue is fixed for lame. From the changelog of 
lame 3.99.1 
(http://lame.cvs.sourceforge.net/viewvc/lame/lame/doc/html/history.html) I 
quote:

"
Fixes for several issues with ID3v2 unicode tags, using Big-Endian text 
encodings. Because of several other software (like Windows Media Player), LAME 
writes Little-Endian unicode tags only.
"

What version of lame are you using?

Original comment by boukewou...@gmail.com on 10 Sep 2012 at 6:17

[GoogleCodeExporter]

I am using LAME 64bits version 3.99.5
Linux Dist. is Arch Linux 64 Bit 

Original comment by eniak.i...@gmail.com on 10 Sep 2012 at 6:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

@boukewou...@gmail.com:
Well, you say its a Lame bug that has been fixed.
That's not right cause "lame -ta "ö ä ü" from terminal *does* work

Original comment by eniak.i...@gmail.com on 10 Sep 2012 at 6:58

[GoogleCodeExporter]

I can confirm that lame 3.99.5 in terminal correctly writes the tags, whereas 
rrip_cli from the very same terminal does not. So the issue must be somewhere 
between rubyripper -> ruby -> lame. Doesnt ruby have any kind of text-encoding 
conversion integrated?

Original comment by rasmus.s...@gmail.com on 10 Sep 2012 at 7:13

[GoogleCodeExporter]

I've retested this and cannot reproduce this problem.

This is what I did (with master branch):
* Put in a normal disc without any special characters
* Add some umlauts to the artist, album and trackfield
* Encode to mp3
* Watch the result in multiple places: Totem, Thunar file properties, 
Clementine, mpg123

When debug is on, it will show you the exact commandline, in this case:
DEBUG: lame -V 3 --id3v2-only --ta "Focüs" --tl "Höcus Pocus" --tv 
TCON="Metal" --ty "1990" --tv TENC="Rubyripper 0.7.0a1" --tc DISCID="EA120A10" 
--tt "Höuse of the kïng" --tn 3/16 
"/mnt/data/audio/new/mp3/temp_cdrom/track_3_1.wav" 
"/mnt/data/audio/new/mp3/Focüs (1990) Höcus Pocus/03 - Höuse of the 
kïng.mp3"

This makes me believe that the problem is not really related to lame, but 
actually to the source where the tags come from. According to the official 
standard of freedb, the tags should be encoded in UTF-8. It is known however, 
that the entries are sometimes encoded differently.

Can you please reproduce my results like described above?

Original comment by boukewou...@gmail.com on 30 Sep 2012 at 10:54

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Here is my /etc/locale.conf:
LANG="en_US.UTF-8"
LC_TIME="de_DE.UTF-8"

Original comment by eniak.i...@gmail.com on 16 Oct 2012 at 6:41

[GoogleCodeExporter]

This is confusing since you are using an old version of rubyripper. (I found 
out because of the ./rrip_cli command. Since it's a very long post, I will 
delete the post. Better save next time to a .txt file.

The problem above is reported against current git. The code has changed in this 
regard, so this result is not relevant.

Original comment by boukewou...@gmail.com on 20 Oct 2012 at 5:58

[GoogleCodeExporter]

Ok, so I downloaded a fresh update of the complete freedb database. The disc 
which was reported can be found as /data/38043805. Gedit for example shows this 
is a iso-8859-1 encoded file. So in this case freedb is sending wrong data.

However, this happens more times than I would like. I actually had some code 
that should convert the character set automatically. I changed the sequence for 
checking so that iso-8859-1 is now the second character set instead of the 3rd 
to check. This fixes the problem.

I actually use the freedb file now in the cucumber tests to ensure it keeps 
working. See also commit:
http://code.google.com/p/rubyripper/source/detail?r=3a49a9819a5f6ed6460bdc6a7a26
24276cbb8ebd

Can someone please verify this fixes the issue? Otherwise I am very interested 
in the discid + metadata of the audio disc.

Original comment by boukewou...@gmail.com on 20 Oct 2012 at 7:30

• Changed state: Started

[GoogleCodeExporter]

For now I will close this issue, since it seems to work for this particual 
disc. If any more problems arise, please report an issue.

Original comment by boukewou...@gmail.com on 28 Oct 2012 at 10:08

• Changed state: Fixed