Bugzilla – Bug 9747
Wrong display of mp3 tags with diacritic characters ANSI 1250
Last modified: 2009-07-27 08:16:35 UTC
Created attachment 4149 [details] Tags correctly displayed in flac files Tags in mp3 files and cuesheets with diacritic marks are not displayed correctly on the display of SB3 as well as in web browser interface. The same tags are diplayed correctly in flac files. Please see attached screenshot-the interpret name "Rany tela". I am not 100% sure, but I think it worked fine with 6.5.4 SC version. The Windows code page is ANSI 1250.
Created attachment 4150 [details] Tags NOT correctly displayed in mp3 files and cuesheets
Would you mind uploading a small sample file which doesn't display correctly?
Created attachment 4159 [details] Tags correctly displayed in flac file
Created attachment 4160 [details] Tags NOT correctly displayed in mp3 file
Michael, need any other information? please re-target if needed.
James - it generally would be most helpful if you could at least try to reproduce newly reported issues.
I forgot to add my comments before I committed it. Sorry, I was able to verify the issue on my MAC installer of 7.3 using the files provided in this email
This very likely is a dupe of bug 5686 - we seem to systematically break encoding for some baltic languages to fix encodings for tons of badly tagged other files :-(. Could you please give the following patch a try (attached to the above bug): https://bugs-archive.lyrion.org/attachment.cgi?id=2774
EWI - any news? Did you have a chance to test that patch?
(In reply to comment #9) > EWI - any news? Did you have a chance to test that patch? > Michael - simple, but important question. How to install the patch ? It is just source code, probably should be placed somewhere. Thanks EWI
> How to install the patch ? Are you running the Windows binary? Then you can't :-( Otherwise you could edit the source file (shown at the beginning of the patch). Remove any line which is prepended by a minus sign, add lines which have a plus.
(In reply to comment #11) > This means I have to wait to 7.3.3 version. Correct ? Could you guess when this version could be released ? (just guess, no guaranties of course) Is there any other possibility to solve this issue ?
I'm sorry, no. I wanted you to test the change before we apply it (if at all). You'd have to download and install ActivePerl to run SC from the code.
(In reply to comment #13) > I'm sorry, no. I wanted you to test the change before we apply it (if at all). > You'd have to download and install ActivePerl to run SC from the code. > Well, I thought so far that the testing should be on SW vendor responsibility. But I understand your issues with many european languages and I REALLY appreciate you take care of this issue. I can run the test on VMware with smaller copy of my music library. Could you please help me a bit and send me the "how to" manual for installing ActivePerl and running SC from code ?
Created attachment 4595 [details] patched SqueezeCenter 7.3.2/rev. 24606 > Well, I thought so far that the testing should be on SW vendor responsibility. :-) Sure, we do test, lots of testing indeed. But we can not build all the environments our users have. Therefore we sometimes ask them to help us help them. Attached you'll find a zip file with squeezecenter.exe and scanner.exe. Make a backup of your existing files, then drop these two into your SC installation folder to replace the original file (they must be in the same place). Restart SC and run a scan from scratch. Do you see any difference?
(In reply to comment #15) > Created an attachment (id=4595) [details] > patched SqueezeCenter 7.3.2/rev. 24606 > > > Attached you'll find a zip file with squeezecenter.exe and scanner.exe. Make a > backup of your existing files, then drop these two into your SC installation > folder to replace the original file (they must be in the same place). Restart > SC and run a scan from scratch. > > Do you see any difference? > I changed both .exe files, but SC did not start anymore. When I changed again to standard .exe files, SC works again. I tried several times back and force, as well as tried to start SC as a service. The result was the same - SC never starts and then died to timeout. Just to be precize, my current SC version is 7.2.1 - 23460. I haven't upgraded yet because this version is stable and except the ANSI issue is fine for me. Please check your .exe files and let me know how to proceed.
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
(In reply to comment #17) > We are now planning to make a 7.3.3 release. Please review your bugs (all > marked open against 7.3.3) to see if they can be fixed in the next few weeks, > or if they should be retargeted for 7.4 or future. > > Thanks! I vote for this bug. Should not be difficult to solve this issue. Please keep on your mind this is not only CZ issue. It is important for nearly all european countries. I can help again to run test on CZ Windows as promised.
We're working on all new scanning code, but it won't make it into 7.3.x. Andy - yet another good test case.
The tags in this file appear correctly encoded in iso-8859-1. The removal of an ugly guess hack is the correct solution. New scanner code will handle this properly by being more strict about accepted encodings and not trying to guess.
(In reply to comment #20) > The tags in this file appear correctly encoded in iso-8859-1. The removal of > an ugly guess hack is the correct solution. New scanner code will handle this > properly by being more strict about accepted encodings and not trying to guess. Well, I know it is unbelieveable how many languages there are in Europe. However I sent the files coded in ANSI 1250 not in iso-8859-1. As far as I know in iso-8859-1 there is not possible to use CZECH language. Please try to keep the same approach as Microsoft did. After couple of years of problems, now MS products are able to handle CZECH language correctly with WINDOWS 1250 coding. I have to also emphasize that there is also difference between ISO 8859-2 and WINDOWS 1250. (http://en.wikipedia.org/wiki/ISO/IEC_8859-2)
The file you sent has id3v2.3 tags and the only character sets supported by id3v2.3 are: ISO-8859-1 UTF-16 (UCS-2) UTF-16 big-endian Your file is ISO-8859-1. If you need more characters, you should use UTF-16. http://www.id3.org/d3v2.3.0 If nothing else is said a string is represented as ISO-8859-1 [ISO-8859-1] characters in the range $20 - $FF. Such strings are represented as <text string>, or <full text string> if newlines are allowed, in the frame descriptions. All Unicode strings [UNICODE] use 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings must begin with the Unicode BOM ($FF FE or $FE FF) to identify the byte order.
(In reply to comment #22) > The file you sent has id3v2.3 tags and the only character sets supported by > id3v2.3 are: > > ISO-8859-1 > UTF-16 (UCS-2) > UTF-16 big-endian > > Your file is ISO-8859-1. If you need more characters, you should use UTF-16. > > http://www.id3.org/d3v2.3.0 > > If nothing else is said a string is represented as ISO-8859-1 > [ISO-8859-1] characters in the range $20 - $FF. Such strings are > represented as <text string>, or <full text string> if newlines are > allowed, in the frame descriptions. All Unicode strings [UNICODE] use > 16-bit unicode 2.0 (ISO/IEC 10646-1:1993, UCS-2). Unicode strings > must begin with the Unicode BOM ($FF FE or $FE FF) to identify the > byte order. OK. Does it mean that if I translate all my tags to UTF-16, they will be displayed correctly on SB3 as well as in SC gui ? I do not know if WXP supports UTF-16. Could you guess when this issue will be solved ? So far I spent a lot of time on testing and there are no results.
How are you tagging the file? I would suggest using MP3Tag, it lets you choose the encoding and tag version. If you're tagging using some native thing in XP, I wouldn't be at all surprised if it was wrong. http://www.mp3tag.de/en/
(In reply to comment #24) > How are you tagging the file? I would suggest using MP3Tag, it lets you choose > the encoding and tag version. If you're tagging using some native thing in XP, > I wouldn't be at all surprised if it was wrong. > > http://www.mp3tag.de/en/ (In reply to comment #24) > How are you tagging the file? I would suggest using MP3Tag, it lets you choose > the encoding and tag version. If you're tagging using some native thing in XP, > I wouldn't be at all surprised if it was wrong. > > http://www.mp3tag.de/en/ Thanks for recommendation. I am using EAC+Lame. I would suggest solution. You can add parameter to SqueezeCenter which coding is used. Then you do not need to guess coding and SB can be sure how to display the tags. Is that acceptable solution for Europe languages and many coding possibilities ? Please keep on your mind that re-tag all library is not an easy task. I have about 600 my CDs there.
No need. It is not even *possible* to store other encodings in id3v2 tags, and it is obvious when parsing the data which encoding has been used. EAC, LAME or the command-line in XP must be doing something wrong when tagging the files.
(In reply to comment #26) > No need. It is not even *possible* to store other encodings in id3v2 tags, and > it is obvious when parsing the data which encoding has been used. EAC, LAME or > the command-line in XP must be doing something wrong when tagging the files. I tried reccommended SW MP3Tag. The result is the same. This means the problem still persist.
EWI - could you please test the latest 7.4 nightly builds? We've replaced the existing scanner code in this version.
Any news?
(In reply to comment #29) > Any news? yes, I tried 7.4 r27455 version. There are so many errors regarding charset, that I stopped to count them. :( Official version 7.3 works much better (except the issue above). Version 7.4 is so far unusable.
> yes, I tried 7.4 r27455 version. There are so many errors regarding charset, > that I stopped to count them. :( Official version 7.3 works much better (except > the issue above). Version 7.4 is so far unusable. You'd have to be a bit more specific for us to be able to reproduce and fix.
assigning scanner related bugs to Andy
This is a won't fix, ID3v2 only supports ISO-8859-1, UTF-8 (2.4 only), and UTF-16.