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

[Llorean]

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?

[jaybeee]

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.

[Llorean]

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.

[jaybeee]

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.

[Llorean]

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.

[jaybeee]

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.

[Llorean]

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.

[saratoga]

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.

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. 

[LinusN]

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.

[Captain Spandrel]

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?

[JdGordon]

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.

[Llorean]

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.

[JdGordon]

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

[JdGordon]

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.

[jaybeee]

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