Rockbox Development > Feature Ideas
Getting CUE from APEv2 tag <CUESHEET> in wv, flac, ape files
prikolchik:
Right now it is possible to store whole album in one lossless (wavpack, ape, flac) and play it track-by-track using CUEsheet file.
CUE file is supported, but it is read from file. However, in lossless music communities it is a standard to have CUEsheet tagged inside lossless file in <CUESHEET> tag.
It seems like Rockbox supports APEv2 tags without a problem, so why not add an option of loading CUEsheet from tag and not from a separate file? It is a much better choice, because tagged CUEsheet is stored in Unicode, there would be no need for a separate CUE file, and it would be possible to display Russian characters (for example) without a problem.
As far as my (very) limited programming knowledge tells me, it shouldn't be too hard. Just need to bind method that handles CUEsheet files with <CUESHEET> tag and (if it is not already done) implement Unicode support.
This little feature would make Rockbox so much more enjoyable for people like me ::)
Thank you.
Llorean:
Are there character-set issues in .cue files in Rockbox that are unfixable? Feature requests shouldn't be made to fix bugs that can be repaired other ways. They should stand solely on their own merits, not the fact that they work around other issues that can be fixed.
As well, Rockbox doesn't support ApeV2 tags on .FLAC files, only Vorbis Comments.
prikolchik:
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:
--- Code: ---/** 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;
}
--- End code ---
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 ///*):
--- Code: ---/* 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;
}
--- End code ---
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.
Chronon:
Thanks for looking into this. However, this would do its job much better as a proper bug report in the tracker. This forum (Feature Ideas) is for presenting new ideas for inclusion into Rockbox, not for fixing bugs or discussing problems with the current code.
prikolchik:
--- Quote from: Chronon on January 25, 2009, 08:57:51 PM ---Thanks for looking into this. However, this would do its job much better as a proper bug report in the tracker. This forum (Feature Ideas) is for presenting new ideas for inclusion into Rockbox, not for fixing bugs or discussing problems with the current code.
--- End quote ---
You are right. I've added bug report http://www.rockbox.org/tracker/task/9830
But I still want <CUESHEET> tag support ;)
Navigation
[0] Message Index
[#] Next page
Go to full version