Bugzilla – Bug 10671
Problem with extended characters in FLAC files
Last modified: 2009-06-17 09:36:17 UTC
Created attachment 4632 [details] Dummy FLAC file, compressed from a file containing 600 odd meg of zeros, with the same CUEsheet and tags attached. I have a FLAC file, which contains a track who's title is in Welsh: Llosgi Nhŷ i Lawr (the second word is 'N h y-circumflex') If I do a hexdump of the FLAC file, I get the following: 32 32 1b 00 00 00 54 49 54 4c 45 5b 39 5d 3d 4c |22....TITLE[9]=L| 6c 6f 73 67 69 20 4e 68 c5 b7 20 69 20 4c 61 77 |losgi NhÅ· i Law| 72 12 00 00 00 54 52 41 43 4b 4e 55 4d 42 45 52 |r....TRACKNUMBER| As I see it, the appropriate portion is: 4e 68 c5 b7 which corresponds to Nh and then the y-circumflex. However, if I query that album's tags using the CLI, I get the following: 64 25 33 41 31 33 33 37 20 74 69 74 6c 65 25 33 |d%3A1337 title%3| 41 4c 6c 6f 73 67 69 25 32 30 4e 68 25 45 35 25 |ALlosgi%20Nh%E5%| 41 34 25 41 39 25 32 30 69 25 32 30 4c 61 77 72 |A4%A9%20i%20Lawr| The data coming back from the CLI is Nh%E5%A4%A9 I think this means the scanning process has mis-read the tag. As a result the web interface shows an incorrect character for the y-circumflex (Llosgi Nh天 i Lawr - it looks like some sort of Kanji character). I've created a 'dummy' FLAC file, compressed from a file containing 600 odd meg of zeros, with the same CUEsheet and tags attached. It's attached (hopefully) to this report. It's track 9 that's the one of interest. I can make the original FLAC file available if necessary, but it's about 400 Meg.
As mentioned in the forum thread, it is reproducable on SC7.3.2-24623/Windows. I have expaned the test file suite I originally created for bug 9772 by two flac files that demonstrate it: Addendum to test suite: http://www.kaufen-ist-toll.de/download/radio/Moonbase%20-%20Windows%20Unicode%20Filenames%20Test%20Suite%20FLAC.rar Screenshots: http://forums.slimdevices.com/attachment.php?attachmentid=6712&stc=1&d=1231871276 http://forums.slimdevices.com/attachment.php?attachmentid=6713&stc=1&d=1231871573 Forum link: http://forums.slimdevices.com/showthread.php?t=58003
Michael: would this be yours? or has it been address yet.
Andy - is this really the file you intended to attach? The tag information is all different from what you describe.
Pretty sure the tag information is correct, however someone else looked at it and found they had problems. The test suite posted in the other comment does seem to demonstrate the issue however. If necessary, I can provide a copy of the actual FLAC file. However, this is several hundred meg and will take me a while to upload somewhere. Let me know if you want me to do this. Andy
Kind of a duplicate of bug 9553: Encode::Detect::Detector sometimes is mislead to interpret utf8 as Big5 or (in this case) EUC-JP. Encode::Guess does a better job in these cases. Change 25129 - please re-open if this doesn't fix this issue for you.
Still an issue for me. If you need a copy of the original FLAC, or some other method of getting the tags to you, then just let me know.
> Still an issue for me. Are you on 7.3.3/SVN? > If you need a copy of the original FLAC, or some other method of getting the > tags to you, then just let me know. Please run a test with Moonbase's file. I used this one for my testing. It's showing the issue you've shown before the change, but is fine afterwards (testing on OSX). If this test is ok for you as well we might need to test with your file. Can't you strip out the data from the file, leaving only the headers & some noise?
Yes, updated with SVN: andy@gently:/usr/lib/slimserver/7.3/server$ svn info Path: . URL: http://svn.slimdevices.com/repos/slim/7.3/trunk/server Repository Root: http://svn.slimdevices.com/repos/slim Repository UUID: 60ad55ce-86ed-0310-8cf8-f9d879be5ea1 Revision: 25132 Node Kind: directory Schedule: normal Last Changed Author: michael Last Changed Rev: 25129 Last Changed Date: 2009-02-23 14:37:02 +0000 (Mon, 23 Feb 2009) Still seeing the issue with Moonbase's file also. I do have the change in Slim/Utils/Unicode.pm. I've restarted Slimserver, and done a full clear and rescan.
Created attachment 4854 [details] Title displayed correctly What exact Debian are you using? What does Settings/Information say about your system? I've been testing this with OSX and an Ubuntu 8.10 system.
Version: 7.3.3 - TRUNK @ UNKNOWN Hostname: gently.org.uk IP: 82.5.225.118 HTTP Port: 9000 OS: Debian - EN - iso-8859-1 Platform: i686-linux Perl Version: 5.8.8 - i486-linux-gnu-thread-multi MySQL Version: 5.0.32-Debian_7etch8 Total Players Recognized: 3 Could this be some sort of mismatch between Perl libraries? I've seen something similar in the past. Any particular version of any of the Perl modules that I should be looking for?
> OS: Debian - EN - iso-8859-1 Aha! This should be utf8 instead of iso-8859-1. What's your locale set to? You're running from SVN? Then you might want to add --charset=utf8 to the SC startup parameter you're using.
Ok, added that startup parameter. Info now reports: OS: Debian - EN - utf-8 However, the title is still showing up incorrectly using Moonbase's test suite.
> OS: Debian - EN - utf-8 > However, the title is still showing up incorrectly using Moonbase's test suite. Did you run a full wipe/rescan?
Of course :) If it would help, and you can give me an IP address, I could give you access to my server's web interface?
> If it would help, and you can give me an IP address, I could give you access to > my server's web interface? You've got mail. But then I'm not sure whether the web UI alone will help that much :-/. ssh access (with the permission to fiddle SC's source files) would be much better, of course...
If necessary, I could arrange ssh access too.
Change 25166 - Encode::Guess sometimes returns ambiguous results like "ascii or utf8" - which aren't valid encoding objects. In this case we'll scan that returned value. If it lists utf8, we'll use it. Otherwise we'll reset the returned character set and continue our analysis. Thanks Andy!
Andy, Do you still see this issue with the latest nightly of 7.3.3?
This issue has now been resolved as far as I'm concerned. Cheers Andy
Marking verified per user comment 19
This bug has been fixed in the 7.3.3 release version of SqueezeCenter! If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.