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

[rykos]

does the rockbox firmware support '.cue' playlist files for selecting playback at various points in a long mp3 file?

[Llorean]

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.

[rykos]

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

[rykos]

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.

[rykos]

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?

[rykos]

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.

[keytotime]

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.

[Llorean]

What do you mean by they have to be used for a tag database?

[keytotime]

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.

[Llorean]

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?

[keytotime]

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

[Llorean]

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?

[rykos]

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?

[keytotime]

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.

[rykos]

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