I'm only referring to UTF-8 CUE file problem here. ASCII CUE file (with correct codepage settings) works without issues.
OK, I have looked myself at the Rockbox source code and my very basic knowledge of C tells me that this function from /app/misc.c:
/** Open a UTF-8 file and set file descriptor to first byte after BOM.
* If no BOM is present this behaves like open().
* If the file is opened for writing and O_TRUNC is set, write a BOM to
* the opened file and leave the file pointer set after the BOM.
*/
#define BOM "\xef\xbb\xbf"
#define BOM_SIZE 3
int open_utf8(const char* pathname, int flags)
{
int fd;
unsigned char bom[BOM_SIZE];
fd = open(pathname, flags);
if(fd < 0)
return fd;
if(flags & (O_TRUNC | O_WRONLY))
{
write(fd, BOM, BOM_SIZE);
}
else
{
read(fd, bom, BOM_SIZE);
/* check for BOM */
if(memcmp(bom, BOM, BOM_SIZE))
lseek(fd, 0, SEEK_SET);
}
return fd;
}
DOES NOT properly handle UTF-8 files. It just ignores UTF-8 BOM (\xef\xbb\xbf) and still treats file as ASCII (instead of UTF-8).
This may be a desired behaviour (which I doubt), but even if it is, it is NOT handled correctly in this function from /apps/cuesheet.c (my comments start with ///*):
/* parse cuesheet "file" and store the information in "cue" */
bool parse_cuesheet(char *file, struct cuesheet *cue)
{
char line[MAX_PATH];
char *s;
DEBUGF("cue parse\n");
int fd = open_utf8(file,O_RDONLY); ///* <===== here open_utf8() is called */
if (fd < 0)
{
/* couln't open the file */
return false;
}
/* Initialization */
memset(cue, 0, sizeof(struct cuesheet));
strcpy(cue->path, file);
cue->curr_track = cue->tracks;
while ( read_line(fd,line,MAX_PATH) && cue->track_count < MAX_TRACKS ) ///* <== here it reads one line at a time from cue file we opened with open_utf8() */
{
///*skipped some code */
}
close(fd);
///* skipped more code */
return true;
}
So in the end, CUE file with Russian track names encoded in ASCII looks like this (right on the photo), and CUE file encoded in UTF-8 gives gibberish (left on photo). And if UTF-8 was handled correctly both ASCII and UTF-8 file would give image on right.
Also these are the CUE files I used:
http://rapidshare.com/files/189443474/cue.zip (there is no wait time)
This seems like a serious bug to me and it would be great if a developer could have a look at it.
===============================
As for <CUESHEET> tag support I would still LOVE to see that in Rockbox. It is a great feature to have.
I'd say that it should do this:
- see if CUE sheet support is enabled. If it is
-- see if file has <CUESHEET> tag. and if it does
--- try to parse it. If it works then we are done here.
--- parse fails so we look for CUE file
---- cue file found, try to parse it. if it works we are DONE and even if it doesn't we are also done.
And also along with CUE support enabled (Yes/No) in settings we should add something like "Enable parsing cue from tag (Yes/No)" and maybe something like "Look for CUE file first and only then after CUESHEET tag (Yes/No)".
I hope this helps.
As for FLAC files. I guess you are right. I dont use them very often anyway =D.
PS: If any clarification or testing is needed please feel free to contact me.
Rockbox Technical Forums
Topic: Getting CUE from APEv2 tag <CUESHEET> in wv, flac, ape files (Read 3979 times)