Rockbox General > Rockbox General Discussion
Does Rockbox support '.cue' files for mp3's?
saratoga:
--- Quote from: keytotime on February 26, 2006, 02:53:16 PM ---Gap's, and it make's building a tag database faster.
--- End quote ---
And seeking much, much harder :)
--- Quote ---Burning to cd is much easier using the ripped image and the accompanying cue file! Nero does ALL the work for you and puts all the track marks in place for you. Also, it means that you have a gapless wav cd when you've finished.
--- End quote ---
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).
--- Quote ---As for tagging - the cue file would contain all the tags. You don't even need to embed the trackname information into each of the files - you can just copy and paste track info it to the text body of the cue file. What could be easier than that?!
--- End quote ---
Reading the tags out of the ID3 tags using the existing tag readers? Pretty hard to get easier then reusing existing code.
--- Quote ---I'm sorry, call this personal taste, but I just cannot understand why you would prefer having individual files!!!
--- End quote ---
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.
keytotime:
Because freedb does not work on individual files. Because there are times when you burn indivdual files to a cd, the cd can not be recognized by freedb. The fact that seeking is no harder.
rykos:
saratoga, please make it clear who you are quoting - you quoted two different people in your post without differentiating between their names
rykos:
--- 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?
--- 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!!!
--- 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?
I don't quite understand what you mean about the limitations of 'seeking'.
For me, the enourmous benefit of having a cue list reader would is because much of my music collection is ripped to mp3 using one mp3 image and a cue list. Much of the music professionally ripped on the internet is also made available only in this format.
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! :)
linuxstb:
--- Quote from: rykos on February 27, 2006, 07:45:38 AM ---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 ---
I don't think there any objections from Rockbox developers to adding cuefile support (it's been discussed at various times in irc), we are just waiting for someone to implement it.
The concept of "one file, many tracks" does not just apply to cuefiles - the Ogg container format allows for "chained files" (basically, just individual Ogg files concatenated together) and the mp4 container allows for chapter marks.
There will be one major issue whenever cuefiles are implemented - it's not easy to perform accurate seeking in VBR MP3 files. Applications like foobar perform "slow seeking" by frame-walking the whole file - something that isn't very practical on the limited devices Rockbox runs on. This won't be an issue for CBR files, or other formats like Ogg, MP4 and FLAC.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version