Does Rockbox support '.cue' files for mp3's?

[saratoga]

Gap's, and it make's building a tag database faster.

And seeking much, much harder

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.

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).

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?!

Reading the tags out of the ID3 tags using the existing tag readers?  Pretty hard to get easier then reusing existing code.

I'm sorry, call this personal taste, but I just cannot understand why you would prefer having individual files!!!

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]

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).

Do you mean burning mp3 cd's or WAV cd's?

Reading 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!!!

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.

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]

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! 

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.

[keytotime]

Another reason to support cue's is because without embedded cue support the flac and wavpack aren't really fully supported  .

[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]

Because freedb does not work on individual files.

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 . . .

Because there are times when you burn indivdual files to a cd, the cd can not be recognized by freedb.

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).

The fact that seeking is no harder.

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]

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).

Do you mean burning mp3 cd's or WAV cd's?

I was thinking of CDDA, but I suppose it doesn't really matter.  Either case is trivial.

Reading 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!!!

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.

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.

How would battery life be affected by the use of a cue list?

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.

I don't quite understand what you mean about the limitations of 'seeking'.

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).

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! 

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.

[pabouk]

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).

[linuxstb]

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).

It can't work perfectly for MP3 for the simple reason that the individual MP3 frames do not contain a timestamp.  So when you seek to a random point in the bitstream, you can only estimate where in the bitstream you are.  This is why applications with good cuefile support such as foobar have to frame-walk the file.

Other formats, such as Ogg and FLAC, contain a timestamp in the header of each compressed frame - this is the key to accurate seeking.  The MPEG-4 container (which could store MP3 streams if any software supported it) goes one step further by storing in the file header a full index containing the offset and length in both bytes and samples of every single frame in file - allowing extremely fast and accurate seeking.

[rykos]

So once again we find ourselves let down by the worlds most 'popular' digital music format 

Anyway, I have not seen foobar 'framewalking' a file, but would be interested to.  Is this a processory-intensive operation for it to perform?

Is iRiver study mode feature also a problem with VBR mp3's?

My Winamp pulls it off without any problem - it just uses the cue list as a fast forwarding feature, rather like the study mode.  It's instantaneous.

For anyone who's interested in using it, or more importantly, having a look at it for Rockbox purposes, the website for the plugin is http://www.guerillasoft.co.uk/mp3cue

Please note the first heading in the FAQ section of that page:

It's not accurate!
Yes it is (I think). For CBR mp3s, the accuracy is the same as for a wav file, and the same as for a CD. The problem comes with VBR mp3s. Winamp uses a fast, inaccurate method to seek positions within mp3s (otherwise it would take a second or so to seek...). This messes up the accuracy a bit, but it's not the fault of mp3cue (or Winamp, really).

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.

[rykos]

Guys, I really must insist that mp3cue is the way to go! 

[LinusN]

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.

So you wouldn't be annoyed at all if you switched to the next track, and Rockbox started playing the last 10 seconds of the current one before playing the next?