Rockbox General > Rockbox General Discussion
Does Rockbox support '.cue' files for mp3's?
keytotime:
Another reason to support cue's is because without embedded cue support the flac and wavpack aren't really fully supported ;D .
LinusN:
Basically, multi-track files, like CUE files, are a pain in the b*tt for Rockbox. Mostly because Rockbox is designed from the ground up for one track per file. Multi-track files will cause quite a lot of grief:
1) A lot less accurate seeking for VBR files, since the TOC is so coarse
2) Random track play is difficult to implement
3) The tag database will be more complex
I'm sure there are more issues than those...
Llorean:
But, what about simply using a .cue as a non-shufflable playlist? Essentially, a list of seekpoints for when you hit next/previous track? Just for those who feel they must leave their music in this format, so that there's at least some support for it, however minimal.
Would that at least be not *too* painful within the current way rockbox is set up? Not asking anyone to do it, just how hard it might be were one of these intrepid fans of .cue files were to take on the task?
saratoga:
--- Quote from: keytotime on February 27, 2006, 06:40:14 AM ---Because freedb does not work on individual files.
--- End quote ---
It works fine with individual files, just not individual tracks. I can freedb tag an entire CD using either cue or seperate files exactly the same way. There is no difference . . .
--- Quote ---Because there are times when you burn indivdual files to a cd, the cd can not be recognized by freedb.
--- End quote ---
Using cue provides no advantage over other methods here though. A CD burned gaplessly will be recognized by freedb regardless of the source (well assuming you don't do something silly like edit the cue file or renumber the tracks).
--- Quote --- The fact that seeking is no harder.
--- End quote ---
Yes actually it is. MP3 provides no provisions for seeking, and cue files do nothing to help this (since they stupidly spec offsets in CD frames and not bytes). Proper container formats (Ogg, MP4) do.
saratoga:
--- Quote from: rykos on February 27, 2006, 07:45:38 AM ---
--- Quote from: saratoga on February 26, 2006, 10:44:57 PM ---True, but burning a gapless CD is pretty trivial even without a cue sheet. Foobar will do it effortlessly from MP3s, as well many other programs. And they'll do it without making it harder to support your files in other programs (and without the battery hit from seeking through huge MP3 files).
--- End quote ---
Do you mean burning mp3 cd's or WAV cd's?
--- End quote ---
I was thinking of CDDA, but I suppose it doesn't really matter. Either case is trivial.
--- Quote ---
--- Quote from: saratoga on February 26, 2006, 10:44:57 PM ---Reading the tags out of the ID3 tags using the existing tag readers? Pretty hard to get easier then reusing existing code.
--- End quote ---
A good point, but I still think that there is nothing easier than a tracklisting pasted into a plain text file!!!
--- End quote ---
I'm guessing you're not a programmer then. Theres no solution simplier then the one thats already been written and debugged by someone else.
--- Quote ---
--- Quote from: saratoga on February 26, 2006, 10:44:57 PM ---As I see it, cue files are really a solution to a problem that no longer exists, and a solution that brings its own problems. Essentially, if you can read cue files, you probably already have a gapless MP3 decoder (since sample accurate seeking makes cues a lot more useful, though I guess theres probably a way to do it without that). At the same time, in software that can't read cues, you can't seek between tracks easily. So what do you really gain? Just gapless playback in crappy software as well as non-rockbox players (a few of which have it anyway), at the cost of not having seeking.
Given the issues involved with cues, and that they are not needed in Rockbox, why not just cut them? You'll save battery life and its not that hard to do.
--- End quote ---
How would battery life be affected by the use of a cue list?
--- End quote ---
To seek to track 5 in a que file, you have to load the ENTIRE file up to that point into memory. So if you want to play a 5MB track thats 50MB into a file, you have to load the entire 50MB to get at it. This is because cue (when used with audio) is somewhat of a hack and does not provide some sort of TOC function.
There a work arounds, but none of them are very good.
--- Quote ---
I don't quite understand what you mean about the limitations of 'seeking'.
--- End quote ---
Since MP3 is just a raw bitstream, seeking is slow and CPU intensive. Using larger files makes this problem even worse. Ideally, one would use MP4 or OGG to implement a CD image, since these allow for fast seeking (IIRC, Ogg may not).
--- Quote ---You're right, gapless playback of separate mp3 tracks is now possible - which is a great thing.
And I do agree that to anyone who isn't using mp3 images with cue files, this must certainly seem rather trivial now.
But surely having the choice of both methods of playback would be even better. I can guarantee you there will be more people like me who would appreciate it! :)
--- End quote ---
Of course. I simply took issue with some of the other points raised by people in this thread that were incorrect. I also wanted to point out that there are solutions that are better then cue in all possible ways now that we have gapless MP3 and true container formats.
But if you're ok with the limitations of cue, and someone is willing to implement support, theres no reason not to do it.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version