Rockbox General > Rockbox General Discussion
Does Rockbox support '.cue' files for mp3's?
Llorean:
If you've read this thread, you'll notice that the feature has been "requested" for a while. A LONG while. But nobody's stepped up for doing it.
Yes, feature requests are possible, but they actually belong on the feature request page (see the left side of the page). So, while yes, saying you support it here is fine, saying you vote for it implies that you feel that somehow the number of people in favour of it will make it be selected. Voting is something you do when there are several choices, and whichever one has the most votes wins. The entire population of Earth can *vote* in favour of CUE, but because there is no voting process, even if it has more people wanting it than any other feature, that in no way guarantees, and in fact does not necessarily even increase the chance of, it getting made.
So yes, if you want to simplify it to "either program in C or shut up" then feel free, but the reason I said it is not because that's the way things have to work, but because evidence suggests that if someone doesn't actually DO it, CUE support will never be done, and this conclusion can be easily reached by reading this, and other threads, discussing it.
The real key though is the use of the word "vote." Voting is a method of decision making, one that this project does not use.
TP Diffenbach:
To handle VBR mp3s, you'd need to post-process (hopefully on the PC, on the device if absolutely necessary) each vbr mp3 to produce an auxiliary file giving the offset for each "track" (or other point of interest, say 1 minute granularity) within the mp3 file.
For you guys who want CUE support, instead of voting, offer a bounty. That is, vote with your pocket money. I'd probably do CBR CUE for US $100. Since I don't use CUE files, I have no interest in doing it gratis, and no desire to go to the trouble of ripping test CUE files, researching the CUE spec, and testing code.
(The actual algorithm for CBR seems pretty intuitive, but that's always the easy part of coding; it's the testing and patching and catching corner cases and transferring executable code to the device and then building for all 22 platforms that sucks down dev time.)
Or learn C, and do it yourselves. Or take a middle way: find a dev who is interested, and make his life easier by providing him with CUE files and corresponding MP3s and urls to technical specifications of CUE sheets or GPL'd code that implements CUE seeking already.
A "here are urls to three sample CUE files and the corresponding MP3s and the tech spec and here's some GPL'd CUE code and here's $50 bucks" will get you what you want a lot faster than voting.
ted_b:
I just donated $50 via Paypal. I'm non-technical, so instead of voting, I'm offering payola....jk Use it how you may. The feature request capability, BTW, is down (i.e it requires a Soundforge user id, which is down). i was simply responding that a first time poster was so abruptly scolded. I'm not stupid, just simply non-technical.
If someone wants me to send something (like a sample FLAC file and associated cue sheet), then lemme know where.
Ted
TP Diffenbach:
--- Quote from: ted_b on July 11, 2006, 01:52:26 PM ---i was simply responding that a first time poster was so abruptly scolded. I'm not stupid, just simply non-technical.
If someone wants me to send something (like a sample FLAC file and associated cue sheet), then lemme know where.
--- End quote ---
Llorean wasn't scolding (though I can get how it might have seemed that way), just pointing out that there are technical reasons -- which Llorean exhaustively outlined in earlier messages -- why adding CUE support isn't easy. (If it were easy, it would have been added by now.)
But perhaps he should have scolded you, for a different reason ;) : this thread is about CUE support for MP3 files. You have FLACS, not MP3s, and the technical challenges are in some ways the same, in other ways different.
FLAC (in both the Native and, even more easy in the OGG, container) does support seeking, which makes adding CUE support for FLAC less of a problem than adding it for MP3s.
The other problem is the user interface; and that's pretty much the same problem as for MP3 CUE sheets. From a technical perspective, this means some major code surgery.
Off the top of my head: changing the tagcache creation functions to grab metadata from the cue sheets to cache fake "tracks", changing tagcache handling to allow "playing" the fake "tracks", and changing playlist to correctly display multi-track FLACs when tagcache isn't used. (I'd probably just want to change tagcache, only supporting FLAC for tagcache users; the functions in playlist.c are pretty tightly coupled, something I discovered when I wrote some code to try to hack in support for extended EXTINF data.)
(What I really want is the opposite: the ability to treat several individual tracks as one tagcache entry, for classical music where each track is a movement within a composition, and possibly to represent whole operas (or opera acts) as one "track". I suspect the "right" way to do this involves OGG and chaining....)
Llorean:
OGG and chaining actually will probably end up working much like CUEs should work (or any multiple track / single file solution really).
I still think just integrating .cue file support into the bookmark system, instead of the playlist system, and then adding some sort of method for next-bookmark (as in, an on/off option for the next track going to next bookmark instead, if there's a bookmark set between the current position and the end of the file) would provide the *vast* majority of the CUE functionality people seem to want (it's uncommon for them to want to shuffle individual subtracks into a playlist, but rather they mostly just want to be able to skip to the next or previous one, and play them sequentially), and this would also allow for easily browsing audiobooks, since you can set bookmarks for each chapter, and if you re-listen to it, you can make use of them, and so on.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version