Rockbox General > Rockbox General Discussion
Does Rockbox support '.cue' files for mp3's?
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:
--- Quote from: saratoga on June 07, 2006, 03:26:51 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.
--- End quote ---
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 ;)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version