Rockbox General > Rockbox General Discussion
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:
--- Quote from: Llorean on June 05, 2006, 08:21:20 PM ---Okay, so that's not an advantage of CUE over properly split files.
--- End quote ---
They aren't split to begin with, so why should I have to split them?
--- Quote from: Llorean on June 05, 2006, 08:21:20 PM ---That's a "It makes it convenient for some users who don't have properly split files."
--- End quote ---
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.
--- Quote from: Llorean on June 05, 2006, 08:21:20 PM ---Remember that CUE sheet support will increase binary size.
--- End quote ---
Sorry, I'm not sure what you mean? The binary size of the Rockbox software/code?
--- Quote from: Llorean on June 05, 2006, 08:21:20 PM ---Which means it will slightly decrease battery life for EVERYONE including people who don't use it.
--- End quote ---
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.
--- Quote from: Llorean on June 05, 2006, 08:21:20 PM ---I'm looking for _technical_ advantages here. Not "That way I don't have to split my files" style ones.
--- End quote ---
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.
--- Quote from: Llorean on June 05, 2006, 08:21:20 PM ---What is wrong with keeping the properly split file?
--- End quote ---
see split (get it ;)) quotes 1 & 2 above
--- Quote from: Llorean on June 05, 2006, 08:21:20 PM ---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.
--- End quote ---
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.
--- Quote from: Llorean on June 05, 2006, 08:21:20 PM ---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?
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version