Welcome to the Rockbox Technical Forums!
Gap's, and it make's building a tag database faster.
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.
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?!
I'm sorry, call this personal taste, but I just cannot understand why you would prefer having individual files!!!
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).
Reading the tags out of the ID3 tags using the existing tag readers? Pretty hard to get easier then reusing existing code.
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.
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!
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.
Quote from: saratoga on February 26, 2006, 10:44:57 PMTrue, 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).Do you mean burning mp3 cd's or WAV cd's?
Quote from: saratoga on February 26, 2006, 10:44:57 PMReading the tags out of the ID3 tags using the existing tag readers? Pretty hard to get easier then reusing existing code.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 PMAs 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.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'.
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!
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.
Why? If the format supports seeking (without decoding all the content) you just need to load the headers (as usually) and some parts to find the start of the track 5. When the format is CBR you do not even need to search for the track beginning, you load it directly.This functionality is already implemented in Rockbock as the playback resume and I think it works well even with VBR formats (at least MP3 and OGG).
A level of innaccuracy such as this is absolutely NO problem for me and would not be a problem for me in any Rockbox implementation.
Page created in 0.101 seconds with 21 queries.