Rockbox Technical Forums

Rockbox General => Rockbox General Discussion => Topic started by: rykos on February 26, 2006, 08:40:50 AM

Title: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 26, 2006, 08:40:50 AM
does the rockbox firmware support '.cue' playlist files for selecting playback at various points in a long mp3 file?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on February 26, 2006, 08:49:54 AM
Not at the moment. You could potentially bookmark various locations in it. But I'm sure there are some others who would like such a feature (as well with FLAC files) so if you felt like coding a patch for it, it'd probably be welcome.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 26, 2006, 11:30:56 AM
thanks for confirming this

do you know where might be the best place to begin in going about such a project?

i would really appreciate any advice and technical knowledge

many thanks
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 26, 2006, 11:31:42 AM
Honestly, I'm not sure. Rockbox is playlist based, so there's a few ways you could do this.

I think you would *have* to not use embedded cues with the way rockbox is currently set up. It would have to be a separate .cue file, which is really fine. Then, look into the playlist code. I'm not sure where it is, but you could probably set it up to use a .cue file like a playlist, and for each entry in it, instead of loading a different track, simply seek to the appropriate point in the current file, and load that portion of the file into the Audio Thread Buffer.

This of course would mean that you couldn't include those long MP3s as multiple entries in a normal playlist (the whole .mp3 file would just be one entry that you couldn't "skip tracks" in) but if you just ran the .cue, it would work properly, I imagine. Just as a general idea for approaching it.

So, if you know C, the first step is to check out the source from CVS, which is explained in the UsingCVS wiki page. If you have windows, you may want to start at the CygwinDevelopment wiki page instead, which tells how to set up a development environment.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 26, 2006, 11:32:25 AM
thank you so much

in response to your points about the cue files:
(and i'm sorry for talking in 'always' and 'never')
- a cue file will always be a separate file, containing the textual timing information for the associated mp3 file. 
- every long mp3 file has an associated cue file - it's the accompanying part of the ripped cd image. 
- the mp3 will always be a single file of only 1 track.
- the mp3 would never be loaded as part of a greater playlist - it would always just be loaded on its own, from its own folder (which would also contains the cue file)

so yes, i totally agree with your points - in fact, winamp uses a very similar plugin to what you've just described, where the cue file is loaded into the playlist viewer and is then used to simply seek the appropriate points in the associated mp3 file.   

it works in the same way as a fast forward function, or perhaps like a 'study mode' function - except it knows exactly which point to go to because the cue file specifies the exact location in 'minutes:seconds'.

each entry in the playlist viewer contains 'trackname' description, and then the timing info telling it where to seek.

it's really very nice to use :)

by way of personal background:  i have a very very 'very' basic programming knowledge.  i would be hesitant to say that i am a suitable candidate for working on something so important.  also, i currently work a 60 hour p/w job, so don't have much time.

both points make working on a project such as this almost impossible for me.  i am sorry, and i do feel kinda guilty for telling you that.

perhaps it would be a good idea to start a thread trying to drum up some support and interest in this?  what do you think?

do you think it might be useful for other people if we added the salient parts of our pm's to the thread?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 26, 2006, 11:33:01 AM
Yeah, I was aware that it would be a single mp3 of one track. I know some people would like long MP3s of a whole CD to be inserted into a playlist as multiple tracks though. I was just making sure that you were aware that with the current system that's really impossible. It'd essentially require a custom playlist format, and probably reworking of the current playlist code.

Also, I know some people (with FLAC files specifically) add the .cue file into the container, so that you have one file with the cue in metadata or otherwise included. That as well wouldn't work too well. Though it could allow skipping forward to set cue points, when that .mp3 or .flac came up in a playlist, you'd have to decide if the "next song" event went to the cue point, or just moved on to the next file. With separate .cue files, then if the MP3 is included in a playlist when generating on the fly, there's no question on handling because the .cue is a separate file, and ignored since playlists aren't added to playlists. This seems to me to be the best behaviour.

I think a good idea would be starting a thread in the General Discussion forum on the idea of "Cue files as Playlist-like behaviour." I personally don't do much programming work either, and I'm definitely not familiar with that area of the code at all, but it seems like something enough people might be interested in that someone who can do it might able to at least start an effort for a patch.

Feel free to use anything from these PMs you think would be helpful/relevant.

Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: keytotime on February 26, 2006, 01:28:20 PM
For me cue's have to be used for a tag database, so maybe whoever's working on the tag database could add support for cuesheet's and embedded cues for flac and WavPack.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on February 26, 2006, 01:33:27 PM
What do you mean by they have to be used for a tag database?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: keytotime on February 26, 2006, 02:24:00 PM
I mean that a cue has multiple track's within it, so a file browser can not see those track's all it see's is

cdimage.cue
cdimage.wav
or

cdimage.wv (embedded cue)

That's not much use. But if you have a tagdatabase it can read it as:
03. Queensrÿche - [Empire #02] The Thin Line
04. Queensrÿche - [Empire #03] Jet City Woman
05. Queensrÿche - [Empire #04] Della Brown
06. Queensrÿche - [Empire #05] Another Rainy Night (Without You)
07. Queensrÿche - [Empire #06] Empire
08. Queensrÿche - [Empire #07] Resistance
09. Queensrÿche - [Empire #08] Silent Lucidity
10. Queensrÿche - [Empire #09] Hand On Heart
11. Queensrÿche - [Empire #10] One And Only
12. Queensrÿche - [Empire #11] Anybody Listening?

That is useful. You can select the song you want to play. That's why for me cue's need a tag database that can read the info from a cue, and make them into individual tracks.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on February 26, 2006, 02:30:15 PM
Yes, but it could also simply treat the .cue files as a playlist for not. You wouldn't be able to mix tracks from a .wv or .wav or .mp3 with associated cue into a normal playlist, but it wouldn't require a database to use.

It seems that if you want to shuffle the songs into the rest of your collection, and treat them as separate tracks, what reason is there *not* to rip it into separate tracks?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: keytotime on February 26, 2006, 02:53:16 PM
Gap's, and it make's building a tag database faster.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on February 26, 2006, 02:56:57 PM
Um, there are no gaps in properly encoded LAME MP3s, and I believe wavpack is natively gapless. (If it's not, consider FLAC.) So really, the "gaps" thing isn't an argument.

As for the Tag Database, yeah there's only one file open operation instead of several, but seeking has to occur *in* the file to start at various points, which actually probably means more effort during playback.

I don't say that it won't be a good feature to have. I'm basically asking, why should it treat the different tracks as individual songs, complicating the loading because of the seek, rather than just treating them as seekpoints when you play the individual file? If you want to shuffle them, or play them out of order, why *not* make them individual files?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 26, 2006, 03:22:39 PM
If a cue sheet was accessible within rockbox as some sort of scrollable list, then could it be possible to use the list to select whatever point within the mp3 file you wished to play from?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: keytotime on February 26, 2006, 04:15:49 PM
I guess it's a matter of taste, I prefer having a cdimage over individual files. Also I is easier to fix up bad tag's because since it's a cd image you can get the tag's fromfreedb. Sometimes when you compress the files you get a better ratio. Burning to Cd is easier also.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 26, 2006, 04:52:36 PM
Where did you come up with all that! lol

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 burning a data cd - by burning as one long file it means that you achieve gapless playback on any mp3 decoding hifi because it is all still ONE track.

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!!! lol  ::)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on February 26, 2006, 10:44:57 PM
Gap's, and it make's building a tag database faster.

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.

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

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

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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: keytotime on February 27, 2006, 06:40:14 AM
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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 27, 2006, 07:37:56 AM
saratoga, please make it clear who you are quoting - you quoted two different people in your post without differentiating between their names
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 27, 2006, 07:45:38 AM
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!  :)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: linuxstb on February 27, 2006, 08:10:21 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!  :)

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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: keytotime on February 27, 2006, 09:40:09 AM
Another reason to support cue's is because without embedded cue support the flac and wavpack aren't really fully supported  ;D .
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: LinusN on February 27, 2006, 02:22:05 PM
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...
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on February 27, 2006, 02:26:47 PM
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?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on February 27, 2006, 03:32:55 PM
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 . . .

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

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

Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on February 27, 2006, 03:44:38 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).
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.

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

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.

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.

Quote

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

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!  :)

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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: pabouk on February 28, 2006, 04:46:04 AM
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).
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: linuxstb on February 28, 2006, 05:41:05 AM
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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on February 28, 2006, 01:07:23 PM
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 (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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on March 01, 2006, 09:46:09 AM
Guys, I really must insist that mp3cue is the way to go!  :)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: LinusN on March 01, 2006, 10:00:17 AM
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?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on March 01, 2006, 10:37:17 AM
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?

5 seconds, no. 

10 seconds... maybe.
but not really.  i honestly would just be delighted that my cue file was supported in even the most basic way. 
honest!
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: twinsen on March 19, 2006, 10:44:02 PM
 
Quote
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.

But why you are against cue files ?
For me they are just important and common, native tag containers for whole CDs.
When I rip new CD with Exact Audio Copy, it writes one big wav file and a cuesheet.
But, why 2 files! I have one CD in my hand and want have 1 file on disc, with all data.
So, I personally use Monkey's Audio, others use FLAC or something like that for compressing audio.
Then, with a little help of Foobar2000 player, I embed cue file into my Monkey's Audio APE file.
And finally, I erase cue file from disk. Now I have complete backup of my CD, playable immediately
with Foobar2000. The only thing to play it is loading this one file to foorbar, which automatically
recognizes embedded cue tracklist, puts it on current playlist and plays it.

And... all above we simply want implemented in Rockbox. Why to complain if it is good or not.
This just IS. People use it. It's useful. Simply. Effective. Comfortable.

And, what other containers can do for me in this case? Basically - what MORE than this?
I listen to music usually as whole CDs, mainly concept albums, so I want to put my
APE CD images on my DAC and play it with track titles read from embedded cue.
Nothing more.

Probably there is many people interested in this feature. All we have hope, that programmers
understand us, and code it into Rockbox :-) Sooner, or later.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on March 20, 2006, 09:53:58 AM
Well, at the moment APE can't really be incorporated into rockbox anyway. There are license issues, as well as the fact that the codec is apparently very x86-centric. So, if you want to do that once cue support is in, you'll probably need to transcode to flac.

As for the advantage of say, several OGG files: You can listen to them gaplessly, and still create a playlist of your favorite songs from various CDs, or mix things up for a party.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on March 20, 2006, 07:42:33 PM
Quote
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.

But why you are against cue files ?
For me they are just important and common, native tag containers for whole CDs.
When I rip new CD with Exact Audio Copy, it writes one big wav file and a cuesheet.
But, why 2 files! I have one CD in my hand and want have 1 file on disc, with all data.
So, I personally use Monkey's Audio, others use FLAC or something like that for compressing audio.
Then, with a little help of Foobar2000 player, I embed cue file into my Monkey's Audio APE file.
And finally, I erase cue file from disk. Now I have complete backup of my CD, playable immediately
with Foobar2000. The only thing to play it is loading this one file to foorbar, which automatically
recognizes embedded cue tracklist, puts it on current playlist and plays it.

And... all above we simply want implemented in Rockbox. Why to complain if it is good or not.
This just IS. People use it. It's useful. Simply. Effective. Comfortable.

And, what other containers can do for me in this case? Basically - what MORE than this?
I listen to music usually as whole CDs, mainly concept albums, so I want to put my
APE CD images on my DAC and play it with track titles read from embedded cue.
Nothing more.


Rockbox support.   You're never going to get APE support on any DAPs (nevermind embedded cues).  At least not unless a lot changes. 

I think you could use embedded cues with FLAC though, which would probably be feasible to implement in Rockbox.  Since the Ogg container already supports all features of cue files, it shouldn't be too hard to support cue sheets in Vorbis and FLAC. 
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on March 20, 2006, 07:51:57 PM
So once again we find ourselves let down by the worlds most 'popular' digital music format  :(

The problem is the container, not the format.  MP3 wrapped in a proper container like MP4 or MKA would not have this problem.  The cue method does since it does not actually have a container, and thus cannot properly seek.  (you'd see the same problem if you tried to do this on a raw .aac stream instead of an m4a file with AAC inside)

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

It can seek at about 200x on my 3.2GHz P4, which is acceptable if you have a fast PC and a reasonable length cue (though the foobar forums are filled with people complaining about it anyway).  I don't know how fast the decoder on Rockbox is right now for various platforms.  Probably <5x on most platforms, so you'd be looking at ~5-10 minutes to seek halfway through a CD image with MP3 + cue.  Not much fun.

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

Note that inaccurate seeking precludes the use of gapless files, so for this method to work, you'd need to either give up gapless decoding.  Or maybe have two MP3 decoders (or one with two modes), so that you could vary the seek method depending on how the file is loaded.   And even then you still won't be able to seek to the right place in MP3 files using cues.

Neither seems like a great solution IMO.  My solution would be to require cue files to only work with containers that support fast seeking, and to then to add support for MP3 in MP4/MKA/whatever (Vorbis and Flac would work normally since they're already in Ogg).  That would solve the seeking problem, but I'm guessing people will complain if they're made to do this in advance.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: dabotsonline on April 10, 2006, 11:51:39 AM
Along with mp3cue, there is also a plugin for Winamp called Cue Player: http://winamp.com/plugins/details.php?id=143011 . MPlayer, foobar2000 and amaroK also support cuesheets.

Cuesheet support was also discussed on another forum recently: http://www.misticriver.net/showthread.php?t=39645 .
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on April 10, 2006, 03:24:09 PM
Along with mp3cue, there is also a plugin for Winamp called Cue Player: http://winamp.com/plugins/details.php?id=143011 . MPlayer, foobar2000 and amaroK also support cuesheets.

Cuesheet support was also discussed on another forum recently: http://www.misticriver.net/showthread.php?t=39645 .

Ha, they use this thread as a source :)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: rykos on April 27, 2006, 09:54:43 AM
ha!  so i am not the only person interested in seeing this functionality come to fruition then.

i am getting to the point where i would like sell my i-river because it will not play cue files.  it's a shame.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on April 27, 2006, 12:05:04 PM
What benefit does .cue offer that cannot be achieved in some other way?
Also, have you found some other portable that supports .cue files or something?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on April 27, 2006, 02:06:58 PM
What benefit does .cue offer that cannot be achieved in some other way?


There aren't any, but was a fairly popular way to rip for a while, and people don't like to have to covert stuff. 
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on April 27, 2006, 05:58:35 PM
I mean there's a lot of technical reasons why .cue handling won't work well on Rockbox (mostly due to the fact that you have to load all of the file up to and including the track you want, and that our entire buffering and playlisting system would probably needed to be rewritten to implement this). This isn't so much as a "we don't want to" as it is a "It can't be done in a reasonable way without likely having costs greater than the gains, especially when a simple once-off preparation of your files completely negates the need for it.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Kimmohoo on May 17, 2006, 08:47:37 AM
I think Matroska would be a nice solution for this problem.

For an experiment, i muxed few of my cue+mp3 albums (Sandra Collins - Tranceport 3 and Teddy Douglas - Soulful House Experience 2) tuo MKA with Mkvtoolnix (http://www.bunkus.org/videotools/mkvtoolnix). Now i'm listening these albums on foobar2000 with matroskaplugin (http://dl.matroska.org/downloads/foobar2000) and it works wonderfully; Trackchanges are gapless, tagging is fast and flexible, replaygain works and seeking is almost instant! Matroska works much faster and nicer than cue-files.

With Mkvtoolnix its pretty easy, just add mp3-file to "input files", then go to Global and choose cue-file as a Chapter file. Then choose "Start muxing". You can mux multiple mp3+cue-files by adding them to job queues. Not too much of a problem. Of course if you have many mp3+cue-files it could be simplier and faster.. maybe somebody could write simple mp3+cue-to-mka tool for this purpose?

Of course, implementing multi-track matroska file support for rockbox might be problematic.. but it's nice solution for pc.  ;D
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on June 05, 2006, 11:39:09 AM
I have a lot of DJ mixes that have been recorded via radio etc (let alone some CD rips that have been created as one long file with a cue sheet [my own CD collection is individual flac files]), and so CUE sheet support in Rockbox, even at it's most basic, would be really great for me.

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

For me, (2) & (3) aren't a problem.  It really wouldn't bother me at all to not have a cue sheet included in the random track play functionality nor indeed to have cue sheets added to the tag db.  The seeking issue is more of a requirement for VBR files though.

So at it's basic, I'd love to see cue sheets supported by Rockbox that simply play back the one file accurately.  No need for any more complex use of cue sheets a la (2) & (3) imo.

I know there's a feature freeze, and I know that Rockbox isn't gonna 'like' cue sheets, but imo I think this would add the icing on the cake so to speak.

The Slim Devices (http://forums.slimdevices.com/) people have managed to support CUE sheets in there software: I wonder if that would be a worthwhile starting place (it's open source code I believe): no point trying to reinvent the wheel (but I know Rockbox is Rockbox and not the Slimserver).  Just a thought  ;D
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on June 05, 2006, 11:54:42 AM
Nobody's yet offered any actual _advantage_ to cue sheets over properly split files.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on June 05, 2006, 12:05:53 PM
Nobody's yet offered any actual _advantage_ to cue sheets over properly split files.
If I have 20gb of mp3 files that have a cue sheet say, then I do not need to split them as Rockbox will just play them (if and when it can) as if they were split (like the Slimdevices software does on my Squeezbox).  If I do have to split them, then I'll have one 'original' copy of the mp3 on my PC HDD, and then one copy of the split files on my DAP.  Fine until I want to clear my DAP and remove those files... but then I'll have to split again next time I want them on. Or I need keep two copies.  Or I guess I could keep just the one losslessly split 'copy' <--- but then that is just a workaround for a feature that seemingly a few people want.

TBH it's just convience for people that have files that have cue sheets

I don't have it as bad as some people though, cos I don't rip all my CDs to image / one large file.  But as I say, I have a lot of live music, that to split is just a hassle.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on June 05, 2006, 07:21:20 PM
Okay, so that's not an advantage of CUE over properly split files.
That's a "It makes it convenient for some users who don't have properly split files." Remember that CUE sheet support will increase binary size. Which means it will slightly decrease battery life for EVERYONE including people who don't use it. I'm looking for _technical_ advantages here. Not "That way I don't have to split my files" style ones.

What is wrong with keeping the properly split file? How is that a workaround, with one track / file? I do believe CUE sheets can still use that, for your programs that like to use them, and meanwhile your files are actually usable elsewhere as opposed to just some few softwares.


So, let me rephrase my request: What makes this feature worth worsening the battery life of everyone who doesn't use it? What _technical_ advantage does it offer that no other existing setup within Rockbox has?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on June 06, 2006, 11:48:50 AM
Okay, so that's not an advantage of CUE over properly split files.
They aren't split to begin with, so why should I have to split them?

That's a "It makes it convenient for some users who don't have properly split files."
see above, they are not split to begin with.  A DJ mix that gets recorded via a soundboard is not going to be split into tracks.  But a cue sheet will achieve that.

Remember that CUE sheet support will increase binary size.
Sorry, I'm not sure what you mean? The binary size of the Rockbox software/code?

Which means it will slightly decrease battery life for EVERYONE including people who don't use it.
Get rid of some of the useless games that increase binary size then (if I've got my understanding right?).  I've never used any of those games.

I'm looking for _technical_ advantages here. Not "That way I don't have to split my files" style ones.
I actually think you're being quite harsh about the whole matter.  I'm not stupid (I've been a coder and I'm also an admin on a 30,000+ users site) so I'm not trying to be argumentative to p!ss anyone off here.

What is wrong with keeping the properly split file?
see split (get it ;)) quotes 1 & 2 above

How is that a workaround, with one track / file? I do believe CUE sheets can still use that, for your programs that like to use them, and meanwhile your files are actually usable elsewhere as opposed to just some few softwares.
I have no need for them to usuable elsewhere.  I use foobar, burrrn, Rockbox H120 & Slim Devices Squeezebox 3: I use no other software/hardware as much as this lot, and all those except Rockbox support cue sheets.

So, let me rephrase my request: What makes this feature worth worsening the battery life of everyone who doesn't use it? What _technical_ advantage does it offer that no other existing setup within Rockbox has?
How much of a detriment to battery life will it make it?  If it's shocking then sure, don't do it.  If it's minimal cos hey, any new bit of functionality impairs battery life, then that's being a bit picky.
The technical advantage is so that I & others do not have to split XXXgb of audio, for use soley on my H120.


Again, I would personally find cue sheet support very useful.  BUT if it really is a nasty thing to implement in that it dramatically reduces battery life etc, then ok it's not worth it.  I'll live without it.  There are things in Rockbox that I could live without also, that I'm sure increase binary size, but others will use them.  It sounds like you personally would never use cue sheets, but I know there are people that would.  I'm really not trying to antagonise you Llorean (although I'm sure I have) as I respect what you and all those that contribute to the amazing Rockbox project do.  I'm just an interested party airing a view about a potential new bit of functionality.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on June 06, 2006, 11:55:56 AM
The games don't affect battery life, as they aren't part of the core binary.

Yes, it's a _very_ small effect on battery life actually. But every new feature is, so you have to weigh in which ones are most valuable. You can achieve the exact same functionality by simply splitting your files properly. So what if they don't come split? You can do it.

You would be taking away battery life from _everyone_ just so you don't have to split your own files. That's the argument against it. That, and making sure that every feature weighs in as being valuable to at least a decent percentage if it has to go into the core. Plugins / Codecs are free. You can add as many of them as you like because they're not all loaded at once, but instead are forced to fit within a reserved portion of memory. The Rockbox binary on the other hand is always in memory, so the bigger it is, the less space there is for buffering. As well, some units have a constraint on the maximum size it can be (which it's actually incredibly near).

I'm not antagonised at all. I come down somewhat... well... antagonistically on new ideas sometimes, but basically you have to determine if an idea is convenient (as this one does) or useful (adds something, which this one really doesn't since you can simply prepare your files, cuesheets don't actually add any new function just another means of doing something already done) or actually a gain to the program. While CUEs are nice, since Rockbox has proper gapless, there's no argument against splitting the files other than "I don't feel like splitting my files."

That's why I keep asking for a _technical_ benefit. It is a small(ish) effect on battery life, and if it allowed something that couldn't be replicated simply by preparation then I'd see it as having more potential.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on June 06, 2006, 12:03:02 PM
Ok, thanks for the quick reply.

Out of interest, is this a feature request already?  If so, can you point me in the direction of it please?  I just wonder what sort of popularity it really has, given all the info we know so far with how it will affect Rockbox.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on June 06, 2006, 12:08:56 PM
http://www.rockbox.org/tracker/task/278
It's also been brought up in the forums before. Maaaaan is that an old feature request.

Since most people don't want to mix .CUE'ed songs into anything else, or even shuffle them...  and I believe plugins can manipulate playback... it's possible that a viewer plugin could be written to handle CUEs

When you click on a CUE file, you'd get a list of tracks in it, you could click on one to start playback there. Though the plugin would have to either be able to show the WPS, or pass you to the WPS (if it did the latter you wouldn't have next/prev track support in the CUE).

I'm now trying to think if there are ways not to affect the binary size. It's really not going to be a major hit, in the end, but no hit is minor. I argue strongly against a lot of new ideas not because I dislike them, but because there are issues that need to be brought up. Honestly I don't think CUE support is a bad idea, and would like to see it, but I think working it in outside the core would be best. Basically, treating a CUE as a playlist, and the tracks within it aren't really individual songs (as in, can't be inserted into other playlists or shuffled) only played sequentially and skipped forward and back... that wouldn't require the same sort of changes to the playback code or anything probably.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on June 06, 2006, 12:23:27 PM
http://www.rockbox.org/tracker/task/278
It's also been brought up in the forums before. Maaaaan is that an old feature request.
Thanks

The rest of your post sounds great.

Basically, treating a CUE as a playlist, and the tracks within it aren't really individual songs (as in, can't be inserted into other playlists or shuffled) only played sequentially and skipped forward and back... that wouldn't require the same sort of changes to the playback code or anything probably.
I can't speak for others, but I have absolutely no issues whatsoever with only being able to skip forward and back.  I really would have no need to put a CUE sheet file into shuffle or another playlist.  The simple functionality of allowing a file to be read via a CUE sheet and playing it is all I'd need.  And to be honest, I reckon most people that would want to use CUE sheets would be perfectly happy with that.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on June 06, 2006, 12:28:17 PM
The difficulty really is being able to have the "Next" and "Previous" buttons skip tracks, while showing the WPS, without having to change the existing playback code. That and properly seeking to a specific point in VBR mp3s, since the DAP's processors are slow for doing it accurately.

But I think something could definitely be come up with in the form of a viewer plugin, if an able programmer were so inclined, and since plugins don't count against binary size, there wouldn't really be _any_ room to object to inclusion. But also remember, even though I object to it, doesn't mean the core devs will if someone succesfully codes CUE support. It just means I'm against it, since it fits my definition of redundant features.

The next thing is finding a willing programmer, since most of the core guys already have a ton of stuff on their plates. :)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on June 07, 2006, 02:26:51 PM
Basically, treating a CUE as a playlist, and the tracks within it aren't really individual songs (as in, can't be inserted into other playlists or shuffled) only played sequentially and skipped forward and back... that wouldn't require the same sort of changes to the playback code or anything probably.
I can't speak for others, but I have absolutely no issues whatsoever with only being able to skip forward and back.  I really would have no need to put a CUE sheet file into shuffle or another playlist.  The simple functionality of allowing a file to be read via a CUE sheet and playing it is all I'd need.  And to be honest, I reckon most people that would want to use CUE sheets would be perfectly happy with that.

Keep in mind, skipping most likely would not work on VBR/ABR MP3 files, so you'd be limited to CBR file only in such a system.

Quote
They aren't split to begin with, so why should I have to split them?

Because CUE is a terrible way to do this that presents essentially insurmountable problems for playback on portable devices. 
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: LinusN on June 08, 2006, 04:42:10 AM
I'd like CUE support as much as the next guy, but there are quite a few technical "problems" with the implementation.

The issues we need to deal with is how to treat a CUE file in the playback and the browser. The simplest (for which there is an old patch already) is to treat the CUE file as a single file, but handle next/prev skipping inside the file, and also special treatment of the metadata.

This raises a few questions:

How should shuffle work? Should it shuffle the tracks within the CUE file? If so, what would then happen if you insert more files in the playlist? Should Rockbox be able to shuffle other files in between the CUE tracks?

These things are not impossible to deal with, but we need to find a good, clean way to handle the CUE files. It is not that simple when you start thinking about it.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Captain Spandrel on June 08, 2006, 08:56:25 AM
So, to clarify, the problems for implimentation in RockBox are:

1) an issue about seeking within big files to find the start of the track (in the case of some formats, for example mpc, vbr mp3 and flac without seektables), and

2) the fact that the browser in directory mode detects and displays individual files, and there's no mechanism for it to slip into some other 'playlist'-like mode for navigating the cuesheet information of a single file, and

3) the tailoring of the current tagcache scanning to extract one entry per file.

 So #2 is an insurmountable problem for the traditional file-browsing mode - it just can't tell if a file has an embedded cuesheet without reading it (like windows explorer or any other file browser). #3 seems less insurmountable, and a tagcache-only workaround might in theory be an option, just as it is with people who use an iPod with the iTunes database and file-storage system. But #1 is the more serious problem, given the lack of CPU cycles on a DAP to just crash through certain files to get to the desired tracks.
Is that a fair take on the situation?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: JdGordon on June 08, 2006, 08:59:53 AM
i know it would be very hacky.. but could it be done by adding each track in the .cue as <the filename>.cue.<track number> then the only thing that would need major work is the playlist (?) code so it knows that if its a .cue.X file it should read the que and move to the correct part in the .mp3?

that woiuld solve the shuffle problem because each track would be an actual track in the playlist.

Also, Llorean. using the excuse of adding to disk/batt usage for a pretty small feature is a bit silly, it might add a few KB, nothing... If you really want to cut down on the fat in rockbox, split it into "modules" or something so the wps/radio/etc is in seperate plugins (mostly wps). that way the people who dont want AA and all the fancy patches dont have to waste space/batt on them.

edit: actually, to make code easier, it should be <cue file name>.<track in que>.que, ie really_bad_dj.1.que, really_bad_dj.2.que etc. and im not sure how TC should handle it, (i dont know the .que format), most probably que-meta data reading would need to be hacked in on-the-fly and not worry about the hdd/batt hit on that?

edit 2: ok, a bit of googling later the format looks simple... so wouldnt all it take a bit of hacking the playlist and metadata reading code? and for TC i guess it should check each mp3 file to see if there is a .que for it (although this sux and should probably be settable). actually, (me is semi-drunk) it just would delete any .mp3 associated with a found .que found during the scanning.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on June 08, 2006, 10:08:51 AM
jdgordon: The "it's just a few KB, nothing" excuse doesn't work. When you have a hard limit of a little over 200kb on some systems that's a few percent points right there. And even on the ones that don't have the limit, *every* feature is "just a few KB" and you have to weigh in each one on its own, as if those few KB mattered. You can't compare it against things already in the program, or things that might be written in the future. Is it valuable enough that ALL users should be penalized, no matter how slightly, for it?

I'm not saying that this feature isn't worth the added code. Just that this needs to be considered with every feature, no matter how tiny.

I mean a really simple solution to this is that we treat .cues as playlists, and ignore embedded cue data if the song is in a playlist, but if the song is run on its own, use the .cue to generate the playlist.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: JdGordon on June 08, 2006, 07:11:14 PM
in all honesty, i reckon this feature is more worthy than a pretty wps, becuase rockbox is after all a audio player and this adds audio playback functionality, not like the album art patch.
but enough on that. if i get some time im gonna have a play.

oh, umm... how do u rip an audio cd to a single file and cue sheet? might help if i had an example to test with :p
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: JdGordon on June 08, 2006, 11:20:11 PM
ok, iv been having a bit of a play. i can easily parse the .cue now and add the individual tracks to the playlist. EXCEPT the playlist isnt happy adding tracks which dont exist, so that is going to need to be changed.
so, how im doing it is adding tracks by the name blaa.cue.1.cued to the playlist. I dont know how the playback code works but i guess it will need a codec for the .cued files which just reads the .cue, finds the index and starts the correct codec at the correct position.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on June 09, 2006, 02:21:26 AM
Keep in mind, skipping most likely would not work on VBR/ABR MP3 files, so you'd be limited to CBR file only in such a system.
You mean skipping to the next track or seeking through the currently played track? 
If it really can't be done on vbr files then that is a big problem for cue sheet handling.  I mean that rules out Ogg Vorbis for a start. 

---

Anyway, it's great to see some more interest in this potential bit of functionality and that jdgordon is having a play with some code; thanks matey  ;)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: pupil on June 09, 2006, 06:13:08 AM
It's my understanding that if you create an MP3 with a CUE sheet, you always do it CBR. I've never found a piece of software that can handle VBR MP3's with CUE's proeprly. It seems to be an unwritten rule that you only use CBR's. So I wouldn't worry about the accurate VBR support tbh.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on June 09, 2006, 06:30:24 AM
It's my understanding that if you create an MP3 with a CUE sheet, you always do it CBR. I've never found a piece of software that can handle VBR MP3's with CUE's proeprly. It seems to be an unwritten rule that you only use CBR's. So I wouldn't worry about the accurate VBR support tbh.
Really? I've never had a problem myself.  I use foobar & slimserver as my players without any problems. 

It's the bitrate that varies not the time, so why should it be a problem?  Or is it that the palyer's code converts the time in a cue sheet into samples (588) and that could confuse it if it's VBR?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on June 09, 2006, 06:44:48 AM
It doesn't rule out Ogg Vorbis because the format has much better seeking.
It really only makes seeking bad for MPC and VBR MP3. Those are the only two that would experience problems with next-track / previous-track seeks in a .CUE situation.

Since the bitrate varies throughout the file, and you have to seek by data position, not time position (as that would require decoding the whole file up to where you wanted to seek), varying bitrate poses difficulties. I believe that Vorbis has information in place to facilitate this, if I understand.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on June 09, 2006, 01:25:58 PM
Keep in mind, skipping most likely would not work on VBR/ABR MP3 files, so you'd be limited to CBR file only in such a system.
You mean skipping to the next track or seeking through the currently played track? 
If it really can't be done on vbr files then that is a big problem for cue sheet handling.  I mean that rules out Ogg Vorbis for a start. 

The issue here is that fast seeking in VBR requires a container like Ogg, MP4 or MKA.  MP3 doesn't have that.

Quote from: pupil
It's my understanding that if you create an MP3 with a CUE sheet, you always do it CBR. I've never found a piece of software that can handle VBR MP3's with CUE's proeprly. It seems to be an unwritten rule that you only use CBR's. So I wouldn't worry about the accurate VBR support tbh.

Werid.  The handful of CUEs people have given me have all been for VBR files.  What would be the point of taking such care to use CUE, and then doing a bad encode with CBR?  Totally defeats the purpose IMO.

Quote from: jaybeee
It's the bitrate that varies not the time, so why should it be a problem?

Because CUE is really, really dumb and stores the position in the file in time, not bytes.  So to figure out which btyes map to which seconds, you need to decode the file.

I suppose thats not really fair since cue wasn't really meant to work the way people use it, but whatever.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: bobbel on June 09, 2006, 05:02:55 PM
IMHO it would be great to implement .cue support.
Would save time not to split those single .cue/mp3(or flac) for rockbox

bobbel 
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: esper256 on July 06, 2006, 06:17:20 PM
Sometimes music is about convenience not technical superiority.

What is the technical superiority of a remote control for your receiver? You can walk up to it and press buttons on the thing. So why should we waste money when we buy receivers when they include a remote?

.cue file is:

A) convenient for those that have a music collection that uses .cue files

In my own experience I use cue/wav for certain reasons

A) The much touted LAME gaplessness of multiple tracks isn't something that every mp3 file I've ever played works flawlessly. The support is just not out universal, so don't treat multi-mp3 files as a perfect gapless solution. cue/mp3 IS perfectly gapless.

B) cue/mp3 represents the music collection better. The people who say it's unnecessary probably don't listen to dance music. Dance music relies on gaplessness. If you don't listen to a lot of DJmixes you probably wouldn't even know if your gapless playing was even really gapless. If you have a collection that is heavy in dance music and DJ mixes you will have many 60 - 200 minute MP3 liveset recordings/radio recordings where anywhere between 9 and 40 individual songs are played.

There are two supporting reasons for mp3/cue:
1. Splitting the mp3 file makes no sense from a music collection perspective. Because a DJ played Artist A - Track T in Liveset L, if you have it as one file, your collection tells you you have Liveset L in your collection. If you have it split, suddenly you are told you have Artist A - Track T in your collection. You don't. There could be an MC hollering over it, it could have fade out fade ins where commercials were removed. From my perspective about being OCD about music organization, storing the original full length MP3 file makes the most sense from a music collection standpoint

2. In a hypothetical situation where we concede that we are selfish but are allowed to not transcode our entire collection to bow to Rockbox's whims: cue files are a great way to add ease of use to our huge MP3 files. Given that we 100% refuse to split our long mp3 files, cue files give us the following features:

#1 and the biggest 1, when a DJ slams a new track in that is absolutely amazing, and I go, man who's track is this, it's ridiculous good, I look at my player and instead of saying I'm 41 minutes into DJ nobodycares, it says Artist A - Track T, and I try to remember to buy that song later.

#2 when the DJ trainwrecks into that one song of the album that has that annoying voice sample over and over again, but the rest of the album is really great but you don't like this song, you hit the next button, and you are pleasantly relieved of having to listen to it.

#3 there are two sides to this one. Sometimes in a radio set, a DJ will play a song that is unreleased, or a special version that might never ever get played ever again. You are in love with it, and you want to listen to it right away, you'd have to seek all over the place in a long mp3 file, but with cue file you can jump right to that place in the mix.  The other way to look at this is if you are playing long mix and you accidentally hit stop or track change button and you lose your place, with cue file you can at least get back to the nearest track mark very quickly.

#4 these DJ mixes I mentioned, not only make more sense in your collection as one file, but with a correct cue implementation, the cue file should always insert itself into the playlist as a whole entity. As in you shouldn't be able to reorder it, or drag a new track in betwee the tracks. If we simply split them up, then various play methods would actually do just this. Rockbox wouldn't read our minds and know that when we add our entire collection to the playlist and hit shuffle, don't shuffle these split mp3s because they came from an mp3/cue situation, it would shuffle them. I hate hearing mixed songs shuffled.

Seeking in VBR due to cue being inaccurate is 100% acceptible.

If you are simply ripping normal CDs (as in a cd that you would want to listen to the tracks non-contiguosly very often) as mp3/cue then I'd agree with Llorean, what's the point? But if your music is only really truly represented as one file, and cue just helps manage playing that file then it makes sense in my opinion.

To reword that, there's little sense in implementing cue support so that it makes cues not work any different than already sliced mp3s. In my opinion cues should be treated like one long track with benefits. But that is because of my musical bias.

I'm an old hand straight C coder and I'd consider giving this a shot, except that I have a good feeling it will interefere with the way the rest of Rockbox handles playlist entries in memory and wouldn't want to guess at what would be the best way to alter that to allow 1 file -> multi play-list entryish formats.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on July 06, 2006, 07:32:36 PM
A) The much touted LAME gaplessness of multiple tracks isn't something that every mp3 file I've ever played works flawlessly. The support is just not out universal, so don't treat multi-mp3 files as a perfect gapless solution. cue/mp3 IS perfectly gapless.


Within the context of Rockbox, LAME is gapless, so this isn't really an arguement. 

Actually, given that I don't believe there is even a single hardware device out there that can understand CUE files, wouldn't your argument actually favor not using CUE files?  Seems to me that if support must be universal for something to be acceptable to you, then CUE would not be acceptable since support is so poor.

Quote
B) cue/mp3 represents the music collection better. The people who say it's unnecessary probably don't listen to dance music. Dance music relies on gaplessness. If you don't listen to a lot of DJmixes you probably wouldn't even know if your gapless playing was even really gapless. If you have a collection that is heavy in dance music and DJ mixes you will have many 60 - 200 minute MP3 liveset recordings/radio recordings where anywhere between 9 and 40 individual songs are played.

I don't see how its better, given that both are functionally identical. 

Quote
1. Splitting the mp3 file makes no sense from a music collection perspective. Because a DJ played Artist A - Track T in Liveset L, if you have it as one file, your collection tells you you have Liveset L in your collection. If you have it split, suddenly you are told you have Artist A - Track T in your collection. You don't.

If you tag properly, this is not a problem.

Quote
2. In a hypothetical situation where we concede that we are selfish but are allowed to not transcode our entire collection to bow to Rockbox's whims: cue files are a great way to add ease of use to our huge MP3 files. Given that we 100% refuse to split our long mp3 files, cue files give us the following features:

#1 and the biggest 1, when a DJ slams a new track in that is absolutely amazing, and I go, man who's track is this, it's ridiculous good, I look at my player and instead of saying I'm 41 minutes into DJ nobodycares, it says Artist A - Track T, and I try to remember to buy that song later.

#2 when the DJ trainwrecks into that one song of the album that has that annoying voice sample over and over again, but the rest of the album is really great but you don't like this song, you hit the next button, and you are pleasantly relieved of having to listen to it.

#3 there are two sides to this one. Sometimes in a radio set, a DJ will play a song that is unreleased, or a special version that might never ever get played ever again. You are in love with it, and you want to listen to it right away, you'd have to seek all over the place in a long mp3 file, but with cue file you can jump right to that place in the mix.  The other way to look at this is if you are playing long mix and you accidentally hit stop or track change button and you lose your place, with cue file you can at least get back to the nearest track mark very quickly.

#4 these DJ mixes I mentioned, not only make more sense in your collection as one file, but with a correct cue implementation, the cue file should always insert itself into the playlist as a whole entity. As in you shouldn't be able to reorder it, or drag a new track in betwee the tracks. If we simply split them up, then various play methods would actually do just this. Rockbox wouldn't read our minds and know that when we add our entire collection to the playlist and hit shuffle, don't shuffle these split mp3s because they came from an mp3/cue situation, it would shuffle them. I hate hearing mixed songs shuffled.

Seeking in VBR due to cue being inaccurate is 100% acceptible.

If you are simply ripping normal CDs (as in a cd that you would want to listen to the tracks non-contiguosly very often) as mp3/cue then I'd agree with Llorean, what's the point? But if your music is only really truly represented as one file, and cue just helps manage playing that file then it makes sense in my opinion.

To reword that, there's little sense in implementing cue support so that it makes cues not work any different than already sliced mp3s. In my opinion cues should be treated like one long track with benefits. But that is because of my musical bias.

I'm an old hand straight C coder and I'd consider giving this a shot, except that I have a good feeling it will interefere with the way the rest of Rockbox handles playlist entries in memory and wouldn't want to guess at what would be the best way to alter that to allow 1 file -> multi play-list entryish formats.

Did you read this thread?  This has been rehashed many, many times.  People aren't explaining work around for CUE MP3 support for no reason.  They're doing it because is simply not possible to implement CUE support for VBR MP3 files.  Its great that you have a number of semi-valid reasons for wanting CUE, but unless one of them can get around the fact that CUE is not designed for use inside compressed files, they're not going to make a difference.

If you want something like CUE for MP3, I'm afraid you'll probably have to look into implementing MP4 or MKA support for MP3 files.  Those containers actually support the seektables required to implement something like this in MP3.  Good luck.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on July 07, 2006, 03:38:03 AM
@esper256: you must have a very similar musical bias like me  ;)

And if it's that VBR mp3s cannot be supported by cue sheets in Rockbox but CBR can, then have a butchers at this nifty little tool I've been using for a while: MP3packer (http://www.hydrogenaudio.org/forums/index.php?showtopic=32379&hl=mp3repacker).

Yes it's a step to perform that could be replaced by splitting files, but as esper256 says, I don't think people want to have two copies of a 'mix' (the single file and the split files). I know I don't

Anyway, just a bit more info and a nice little tool for you.

---

It's a long shot, but how about implementing MP3packer into Rockbox for when you want to allow seeking of a VBR mp3? Again, I don't expect this to be taken up by Dev etc, but if you don't ask/suggest you don't get  ;D
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Bagder on July 07, 2006, 06:14:54 AM
how about implementing MP3packer into Rockbox

This is deviating from the thread topic, but sure go ahead and write a plugin for Rockbox that does this if you think it is a useful thing. Personally I've never had a need.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on July 07, 2006, 06:56:06 AM
how about implementing MP3packer into Rockbox

This is deviating from the thread topic, but sure go ahead and write a plugin for Rockbox that does this if you think it is a useful thing. Personally I've never had a need.
deviating? yes, slighty.  But still sort of relevant.
Anyway, it was just a suggestion* thrown into the mix ;)

* a suggestion for others to see, cos I'll not be writing any plugins for Rockbox; I've donated instead and hope that helps (not this issue, but Rockbox in general)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: esper256 on July 07, 2006, 12:24:06 PM
Did you read this thread?  This has been rehashed many, many times.  People aren't explaining work around for CUE MP3 support for no reason.  They're doing it because is simply not possible to implement CUE support for VBR MP3 files.  Its great that you have a number of semi-valid reasons for wanting CUE, but unless one of them can get around the fact that CUE is not designed for use inside compressed files, they're not going to make a difference.

If you want something like CUE for MP3, I'm afraid you'll probably have to look into implementing MP4 or MKA support for MP3 files.  Those containers actually support the seektables required to implement something like this in MP3.  Good luck.

Yes I read the thread. Did you read my post? Given that I said VBR support isn't important to the people who most likely want Cue/MP3 support I'm guessing you didn't.

You can call my reasons "semi-valid" and I will call your argument simply the absence of my musical tastes. If you had, then you would want cue/mp3 too. So maybe the workaround for us is to start listening to more top40 on rockbox.

Thank you for your enlightening reply.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on July 07, 2006, 03:40:18 PM
Did you read this thread?  This has been rehashed many, many times.  People aren't explaining work around for CUE MP3 support for no reason.  They're doing it because is simply not possible to implement CUE support for VBR MP3 files.  Its great that you have a number of semi-valid reasons for wanting CUE, but unless one of them can get around the fact that CUE is not designed for use inside compressed files, they're not going to make a difference.

If you want something like CUE for MP3, I'm afraid you'll probably have to look into implementing MP4 or MKA support for MP3 files.  Those containers actually support the seektables required to implement something like this in MP3.  Good luck.

Yes I read the thread. Did you read my post? Given that I said VBR support isn't important to the people who most likely want Cue/MP3 support I'm guessing you didn't.

It probably won't work at all for VBR files.  I can't imagine theres much interest in a solution that won't work for the overwhelming majority of files.  Yes, it could work for CBR, but given that it won't work most of the time, a better solution is needed IMO.

Quote
You can call my reasons "semi-valid" and I will call your argument simply the absence of my musical tastes.

Tastes have nothing to do with this.  Everything you wanted can be accomplished already in Rockbox presently, though it might take some effort to set things up.  Furthermore, the present situation will work for VBR files.  Which is why I called your points "semi-valid".

Quote
If you had, then you would want cue/mp3 too. So maybe the workaround for us is to start listening to more top40 on rockbox.

I don't know what this means.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: ted_b on July 11, 2006, 09:13:17 AM
First post.  I registered because I want to regoster this issue.

I have 780 FLAC files representing 780 cd's (so far).  Each has been ripped with EAC and each has a related cue sheet file.  I did this to easily archive and manage (rather than 10,000 files, assuming 12 songs per album), and because popular programs like Foobar2k handle flac and cue sheets out of the box.  It's painless, convenient (there's that word again) and oh.....what a lot of people who have large collections do (780 represents a portion of my library, and I'm a smalltime collector).

I can't become a Rockbox user unless:
a) I listen to albums in their entirety without the ability to distinguish tracks, read track titles, and skip along based on track numbers, etc.
2)  rerip 780 FLAC files into 10,000 new individual flac song files, all the while deleting the album files (unless I have an addtl few hundred gig laying around).

Seems unlikely.  So I vote for cue sheet support, too.  Thx
Ted
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on July 11, 2006, 11:51:16 AM
Don't *vote* for it. Either do it, or don't complain about lack of it.

Rockbox is not a democracy. It's a bunch of stuff that got done by people who decided they wanted it enough to actually DO it.

So, which is more inconvenient for you? Reripping your songs, or learning to program in C and writing CUE support for us? If the reripping is more inconvenient, we'd certainly welcome an effective method of CUE support.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: ted_b on July 11, 2006, 12:24:59 PM
your not serious, really?  I assumed this was a forum for questions, help, field-initiated ideas....... and feature requests.  My first post here and I'm told
"either program in C or shut up."  Wow.

Bye
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on July 11, 2006, 12:35:13 PM
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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: TP Diffenbach on July 11, 2006, 12:45:53 PM
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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: ted_b on July 11, 2006, 12:52:26 PM
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
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: TP Diffenbach on July 11, 2006, 02:03:21 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. 

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....)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on July 11, 2006, 02:57:58 PM
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.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on July 11, 2006, 08:19:45 PM
Would people be willing to cut files if it was automated?  I was looking on google, and it seems that making a utility that could run from a PC and recursively scan a portable player for CUEs, and then cut as it went would be easy.  Basically just need a few lines of perl to wrap around mp3split.

Downside is you have to change the files, but you could keep the original intact files on your PC, so you'd only be editing a copy of them.  And it would work correctly with VBR MP3 files.  I think it would be a nice solution, at least until someone actually rewrites the parts of rockbox needed for Cue.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on July 11, 2006, 08:22:16 PM
Well you'd have to cut FLACs, Ogg/Vorbis, and possibly MPC as well, at least, and the MP3s would have to be cut in a way to preserve gaplessness, with the .CUE used to generate tags perhaps.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on July 12, 2006, 03:00:51 PM
Well you'd have to cut FLACs, Ogg/Vorbis, and possibly MPC as well, at least, and the MP3s would have to be cut in a way to preserve gaplessness, with the .CUE used to generate tags perhaps.

The program I looked at could do Ogg and MP3.  It counts frames, so it should preserve gaplessness. 
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: luckydevil13 on July 27, 2006, 05:54:09 PM
I mean there's a lot of technical reasons why .cue handling won't work well on Rockbox (mostly due to the fact that you have to load all of the file up to and including the track you want, and that our entire buffering and playlisting system would probably needed to be rewritten to implement this). This isn't so much as a "we don't want to" as it is a "It can't be done in a reasonable way without likely having costs greater than the gains, especially when a simple once-off preparation of your files completely negates the need for it.

I'm newbie user of rockbox, i'm not programmer - but I can suggest algoritm.... it's not needed to load whole file... i think

1) open *.cue file as folder, while entering the folder:
  1.1) read Length of mp3 file and it's size
  1.2) read cue time markers
2) write filenames of small mp3s, on open one of it =>
3) and HINT! seek in large file proportion time_whole/time_part = size_of_file/seek bytes!

it's not needed to load whole file - no matter CBR, ABR o VBR ... yes seek will be approximately - but I think - it will be enough


sorry for my english )


Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: senab on August 04, 2006, 05:07:44 AM
I'm not too bothered about about cues to be honest, I use them a fair bit but the process of cutting a cue'd mp3 (even VBR) up is pretty painless. As I'm sure Jaybee knows, you can use a small program called pcutmp3 (http://www.hydrogenaudio.org/forums/index.php?showtopic=35654) to cut up the mp3 gaplessly as it addeds a LAME (and more importantly the enc_delay & enc_padding tags) to the files.

 ;)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Wolf on August 04, 2006, 11:54:56 AM
Another nice piece of freeware is mp3DirectCut at http://www.mpesch3.de
Wolf.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: dmd on February 16, 2007, 05:32:45 PM
A BIG thankyou to all who have made this possible and committing it! I guess especially JdGordon and Nico_P  :-* Since I'm a megamix fan (www.megamixers.com) there are usually 50-200 tracks in one mix, and I think using cuesheet is the only smart way if you want to jump within the mix. I've been dreaming of this for almost three years now  ::)
If I'm right at the moment the tracklimit is 20, so for me that isn't nearly enough ;D All I can hope for now is that the artist and title could be viewable in the WPS, but of course I can always use text or image file for tracklist.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: adam917 on February 17, 2007, 03:35:09 AM
Thanks a million for this CUE (and similar other files) support. I've been waiting for this on a DAP player for about 5 years.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: NicolasP on February 17, 2007, 09:47:44 AM
If I'm right at the moment the tracklimit is 20, so for me that isn't nearly enough ;D All I can hope for now is that the artist and title could be viewable in the WPS, but of course I can always use text or image file for tracklist.

Have you tried playing a cuesheet with rockbox ? The tracklimit in a cuesheet is 99 (this is in the cue file format specification, we didn't decide it). Also the artist and title do show in the WPS.
Anyway, I'm glad to see it's appreciated ;)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: dmd on February 17, 2007, 11:40:34 AM
Ok, I gotta admit I rushed a bit and I can confirm that artist and title work ok and it shows tracks above 20  :-[ Afterall I tested some cues which work ok with Winamp's mp3cue plugin, but not with Rockbox. It seems to me there are lots of different kind of cuesheet formats.
NicolasP: would you like me to email you some cues which doesn't work with Rockbox?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: NicolasP on February 17, 2007, 12:07:40 PM
NicolasP: would you like me to email you some cues which doesn't work with Rockbox?

Of course ! I didn't test the parser on much different cues so it could have hidden flaws. Go ahead :)
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on February 18, 2007, 04:56:20 PM
Massive thanks for creating this cue sheet support
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on February 21, 2007, 03:42:12 AM
Just got round to installing Rockbox (Version. r12426-070221) with cuesheet support.

- Enabled cuesheet support via the menu & rebooted as required.
- Navigated to a directory with an mp3 file and a cue sheet (all correctly named and referenced [works with foobar etc]).
- So when I select the .cue file it loads and is viewable. But that's it. I can't get it to play. Surely this isn't what it's meant to do right?
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: LinusN on February 21, 2007, 03:50:35 AM

- So when I select the .cue file it loads and is viewable. But that's it. I can't get it to play. Surely this isn't what it's meant to do right?

You are supposed to play the .mp3 file, not the .cue file.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: jaybeee on February 21, 2007, 04:03:15 AM


- So when I select the .cue file it loads and is viewable. But that's it. I can't get it to play. Surely this isn't what it's meant to do right?

You are supposed to play the .mp3 file, not the .cue file.

ah, ok. I gotcha.

So I think what has confused me is that unfortunately the only mixes I have on my player at the mo that have cue sheets have more than one cue sheet in the same dir referencing the same file (1.cue & 2.cue allows the 2hr mix to be played in 1hr sections so to allow easier burning to CD, whilst 3.cue allows the entire 2hr mp3 to played). And when selecting the one mp3 in this instance no cue sheet playback style is initiated.

I've deleted the extra cue sheets leaving just one and it now plays ala cue sheet style.

I wonder if this is something that can be "fixed"?
TBH it's not something that often happens (more than one cue sheet in the same dir referencing the same file), but it maybe could be looked at?

Anyway, it's easy enough to delete the extra cue files.

Thanks for the swift response LinusN
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Billy on March 14, 2007, 03:27:15 AM
The simple functionality of allowing a file to be read via a CUE sheet and playing it is all I'd need.  And to be honest, I reckon most people that would want to use CUE sheets would be perfectly happy with that.


Totally agree.. plus skip forward and back...
That is all we need...
To: Developers...

People who use your Rockbox software are not so simple (pug and play, buy and use...), at least they need to be sure what are they doing to install it on device...
I use cd image files in flac and wv with CUE tagged within... it brings an order in my music library...
Most of advanced users are using it as well...

SO SIMPLE CUE SUPPORT for CBR and lossless files even through a plugin ARE VITAL...!!!!!!
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on March 14, 2007, 03:30:42 AM
A) CUEs are supported. Please, be up to date before writing your complaints.

B) There is no good reason to use embedded CUE files if you own the CD and are ripping to lossless.

C) If something is VITAL, then surely you want it badly enough to work on it. Rockbox is ENTIRELY volunteer work. So, feel free to improve it. If you don't have the knowledge to do so right now, feel free to spend some time learning first, it'll either still be there when you're done, or someone else will finish it while you're learning, and then you'll have the feature you want.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: bluebrother on March 14, 2007, 06:00:58 AM
SO SIMPLE CUE SUPPORT for CBR and lossless files even through a plugin ARE VITAL...!!!!!!

For my purposes cud sheets are completely unneeded even as I'm not "so simple" and have quite some requirements to a good firmware. Feel free to consider cue to be "vital" for you, but please don't assume it's vital to everyone using or developing Rockbox. From the responses I'm aware of cue is only wanted by a small amount of users. Calling such a thing "vital" is quite inappropriate IMO.

Btw, there is no need to scream.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: ray on March 24, 2007, 07:41:44 PM
wow! i haven't updated my rockbox build since late november 2005!

impressed with all the new codecs... but this cuesheet support was one of my most-wanted features!  it's great!

i like how there are "cuts" in the progress bar indicating where each track starts... really elegant!

i also like how winamp's mp3cue cuesheets are supported!

great job!
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Undesirable on March 29, 2007, 02:41:37 AM
I've just noticed cuesheet support in Rockbox. ESSENTIAL feature since the dawn of time, I now officially consider Rockbox a masterpiece and an absolute necessity on any future portable media player ever. I simply won't buy unless it supports Rockbox.

Since the cuesheet viewer is so great, I had an idea / suggestion that it could be displayed when tracks are being played and you hit the navigation button (with the currently playing track selected, and all other tracks playable directly from the cuesheet viewer). Then you could just press left on the pad to get back to normal file view. There could also be a little progress meter for whatever track is playing just underneath the text. Apologies if anyone else has suggested this. Of course, I'm more than happy with the current cusheet support. THANKS!

Edit: I edited in the bracketed thingy.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: GodEater on March 29, 2007, 02:46:48 AM
Forums aren't the right place for feature requests.

First search Flyspray and see if they're already present, and if not, then submit them yourself.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: iven on June 01, 2007, 04:44:09 PM
Thank you to the programmer(s) who added CUE support. Based on my own experience using the latest rockbox build on my iPod nano, it seems there are still limitations to the CUE support (correct me if I'm wrong):

1) It only works properly with CBR MP3s (not MPC or any other compressed format)
2) Skipping to next/previous track is inaccurate for VBR MP3s.

Despite these limitations, I'm still grateful for this feature. Even though I cannot select the tracks in VBR MP3s (or MPCs, etc.), it still scroll the proper name of the tracks at the proper time as the file is played continuously and this is good enough for me. The whole point of CUE sheet for me is to play continuously gaplessly (or with the proper gaps as on the original CD). Without the CUE support, I'd not be able to tell what track is currently playing unless I memorized the tracks' names and sequential order.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: Llorean on June 01, 2007, 06:37:23 PM
You can play gaplessly by having separate files, so saying that's the point of CUE support is to me somewhat silly: You can do it in a better way without the CUE feature.

And CUE will work for any filetype as far as I know. The problem with some situations (those where seeking is more difficult) is that because a precise seek is difficult, you'll get a seek to a point near where it wants to seek to, rather than exactly at. But with the filetypes where seeks are precise, it'll be fine, if I understand correctly.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: deadkenny on August 06, 2007, 05:02:50 AM
Main use of cue files for me is with mix and live albums. Some are just one big track but there are cue files available to break it down into individual parts.

Not essential, but handy to know what bit you're listening to.

Secondary to that though is I've generally been ripping to Flac for my server and then convert these into single album mp3s with cue files. I did that because I was originally using the official iRiver H10 software which didn't play gapless and it was an easy solution.

With Rockbox I haven't tried individual tracks yet. I need to reconvert my Flacs to individual MP3s. I think I tried a while back and gapless support seemed a bit flakey, even though my MP3s are all produced from Flac with LAME. Is MP3 even with LAME encoding, reliably gapless? (if the player supports it). Problem I've found is often gapless support seems to work on detecting silence rather than actually spotting the end of a track and playing the next. I assume Rockbox does the latter though (hope so).

Anyway, what I will say is I get nowhere with MP3 and cue files. Just seems to ignore the cue file. They work fine with Flac files though.

I might be a bit out of date though. I'm using the H10 build r13836-070709

If I had enough disc space on my player I'd just stick Flac files on there anyway ;D
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: saratoga on August 06, 2007, 11:06:15 PM
Quote
Is MP3 even with LAME encoding, reliably gapless? (if the player supports it).


Yes, provided your LAME build is less then 6 years old.

Quote

Problem I've found is often gapless support seems to work on detecting silence rather than actually spotting the end of a track and playing the next. I assume Rockbox does the latter though (hope so).


Rockbox does neither.  Instead, it uses the gapless information provided by LAME to decode the correct number of samples.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: mutilated on September 01, 2007, 09:44:00 AM
Just wanted to say thanks for this addition.  I was waiting for a while.  I'm going to gladly make a donation soon.
Title: Re: Does Rockbox support '.cue' files for mp3's?
Post by: m_l on January 17, 2008, 12:19:21 AM
THANK YOU for  .cue file support ;D