Problem with UTF-8 filename encoding in cue sheets when using latin accents (áéíóúàèìòùâêîôû and the like)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Load a cue sheet containing a link to a file with a latin accent;
2. Save the cue sheet as UTF-8;
3. Try to read the new cue/flac pair with another player than XLD.

What is the expected output? What do you see instead?

Say I have a cuesheet that is linked to "testé.flac". It contains the line:

FILE "testé.flac" WAVE

XLD will encode the é in UTF-8 as a three-byes 65 CC 81, which is correct, but 
unusual. The usual way of encoding the character is the two-bytes C3 A9.
On most systems, this cuesheet will not be read correctly, because even if it 
reads the same for a human (é), 65 CC 81 is different from C3 A9 for a parser 
or a filesystem. Note that XLD seems to do fine with both encoding, even when 
reading.

What version of the product are you using? On what operating system?

XLD 20110611 (or previous) on Mac OS X 10.6.7 and Windows 7 with foobar2000 for 
reading. Also tested with various other players which exhibit the same behavior.

Please provide any additional information below.

The problem is not limited to the é letter as shown in this example, but 
occurs with any latin diacritic (I haven't tested other alphabets). Some common 
examples in French : é, à, è, ç, ô.

Original issue reported on code.google.com by rie...@gmail.com on 22 Jun 2011 at 8:17

[GoogleCodeExporter]

Seems to be NFC/NFD issue due to HFS+ filesystem.

I understand the issue could occur, but the steps to reproduce described above 
does not always reproduce the issue. Basically XLD preserves the original form, 
so the problem should occur only when the string is derived from the HFS+ 
filename.

Original comment by tmkkmac on 23 Jun 2011 at 5:27

• Changed state: Accepted

[GoogleCodeExporter]

The bugs come only when XLD can't find the sound file listed in the Cue Sheet 
and ask the user to choose a file for him. So I suppose that's due to the HFS+ 
filesystem like tmkk says.

Original comment by stanisla...@gmail.com on 23 Jun 2011 at 10:59

[GoogleCodeExporter]

I had the same issue and Apple provides some very handy NSString methods to 
deal with this.

I use this one:

precomposedStringWithCanonicalMapping to get the NFC mapping.

Apple Documentation says:

Returns a string made by normalizing the receiver’s contents using Form C.

- (NSString *)precomposedStringWithCanonicalMapping
Return Value
A string made by normalizing the receiver’s contents using the Unicode 
Normalization Form C.

Availability
Available in Mac OS X v10.2 and later.
See Also
– precomposedStringWithCompatibilityMapping
– decomposedStringWithCanonicalMapping
Declared In
NSString.h

Original comment by zeccot...@gmail.com on 23 Jun 2011 at 1:08

[GoogleCodeExporter]

Fixed in version 20110703.

Original comment by tmkkmac on 3 Jul 2011 at 5:49

• Changed state: Fixed