12.19.53 # JdGordon: I saw on the forum that you once started having a look at cuesheet support 12.20.13 # yeah, It wont work well with the current playlist code 12.20.32 # and what if we don't integrate it in the playlist code ? 12.20.43 # it wont be able to be used 12.20.49 # i mean it cant be done any other way 12.20.49 # have you looked at the wiki page i've created ? 12.20.54 # no 12.20.56 # which? 12.21.22 # http://www.rockbox.org/twiki/bin/view/Main/CuesheetSupport 12.21.59 # what do you mean by "it cant be done any other way" ? are you suggesting you tried something else and it failed ? 12.22.27 # thats the easy way of getting out of it... checking the wiki page now 12.24.15 # Nico_P: I reckon the foobar2k way is more correct.. but I dont think the playlist engine (without some pretty evil hacking) would be happy with either 12.24.44 # i must say i have a preference for the amarok way 12.24.51 # I dont know the playlist code all that well, so I could be wrong 12.25.36 # i mean from a purely user-ish point of view... 12.26.31 # so what did you do ? you were talking about a CUE file parser in the forums... 12.26.44 # I think not allowing shuffling would be a waste, I see cue's as a nice way of storing full cds, and sometimes its nice to listen to a bunch of cds on random 12.27.19 # I first thought about hackig the filename in the playlist and adding some code to seek that, but decided tats a bad idea 12.28.00 # are there any playlist formats that support cue files? 12.28.07 # m2u doesnt iirc 12.28.10 # m3u* 12.28.23 # not that i'm aware of 12.33.14 # what about implementing it separately in the first place and then trying to make it fir nicely with the playlist system ? 12.34.52 # Im sure it could be done with a plugin (assuming plugins have basic track seeking capalilites) 12.35.15 # * JdGordon checks 12.35.51 # it does 12.36.09 # plugins can seek ? 12.36.18 # audio_ff_rewind() 12.37.00 # doing it as a rock wouldnt allow it to work with the current playlist tho, but better than notihg 12.37.08 # so you're suggesting it could be done entirely in a plugin ? 12.37.56 # 80% sure it could. 12.38.16 # ok, but then nothing can be added to the WPS ? 12.38.41 # not nessacerily 12.39.11 # depends where the wps gets the info from 12.39.56 # actually... proablby not 12.40.15 # not sure how buttons would work if we left the plugin 12.41.25 # got it! 12.42.20 # ? 12.43.35 # I _think_ I can do the entire cue handlin in a tsr plugin, which means you would go back t the wps, and it would fake some of the info 12.44.13 # in the playlist viewer it would look like 1 track 12.45.35 # * JdGordon grabs a fresh cvs and starts playing 12.45.41 # :) 12.46.22 # what would go against putting it all in the core ? too much bin size added for only a few users ? 12.47.14 # the way it will be done is fairly hacky... to be put in the core I think the playlist engine should be fixed to support it properly (each playlist entry would have a start/end time and file) 12.47.52 # JdGordon: What exactly would your tsr plugin do? What happens if the user is in a plugin already when the cuefile needs parsing? Or tries to use a plugin whilst playing a file with cuesheet? 12.48.00 # JdGordon: and then maybe treat the .cue files as a virtual dir? 12.48.48 # IMHO having a separate "cuesheet viewer" instead of combning them with playlists is not that hacky 12.49.11 # * linuxstb would prefer the concept of "sub-tracks"/chapter points - i.e. keep playlists as they are. 12.49.28 # And accept the fact that .m3u playlists can't specify sub-tracks. 12.49.28 # linuxstb: i think we agree 12.49.45 # linuxstb: the tsr would read the .cue and make a new playlist with the one file, start a new thread and drop bck to the wps. the actio ahdnelr would get a callback which lets tsr plugins get button presses before the callee which would let it know when to ff/rwd. if anything wants the plugin buffer it will exit leaving the 1 file playlist 12.49.51 # markun: virtual dir? 12.50.07 # JdGordon: yes, so you can add individual subtracks 12.50.41 # JdGordon: would you mind sharing what you already have so i can play a bit on my side ? 12.50.46 # * linuxstb would prefer it in the core. 12.50.58 # Nico_P: I have an idea and a blank cvs tree :p 12.51.16 # It's not just cuesheets - it's chapters in .mp4 files, multiple-track SIDs, chained Ogg files... 12.51.19 # :) i thought you already had the parser 12.51.30 # I tihnk I lost that ages ago 12.52.40 # linuxstb: i totally agree 12.52.57 # linuxstb: have you read the wiki page about cuesheets ? 12.57.53 # markun: where is virtual dirs used so I can have look? 12.58.06 # nowhere I think 12.58.24 # ah, ok 12.58.34 # ondio MMC? 13.07.21 # * JdGordon is thinking it might be possible to store track position info with playlist entry filenames without much hacking 13.08.36 # * JdGordon does magic voodoo to get hardeep in here 13.12.27 # Would decreasing the maximum amount of playlist entries to 134million instead of 268million be acceptable to add cue support? 13.14.20 # maybe, but i guess users would want an option. :-D 13.14.20 # it does seem acceptable :) 13.14.44 # * JdGordon doubts anyone has that many tracks anyway 13.15.29 # I'm thinking that start and end track positions can be stored in the filename buffer after the track name.. the decrease is because another flag bit is needed 13.16.47 # not entirely sure how to implement this tho 13.19.55 # does anyone know which function the playback engine calls to get the next track to buffer? 13.32.25 # * linuxstb goes for lunch 13.34.32 # Nico_P: message on the dev mailing list... need to recruit someone who knows the playback engine 13.40.08 # JdGordon: what is the problem ? 13.40.35 # getting the playback engine to buffer only the requested part of the track 13.40.44 # also the playlist cde is confusing me 13.40.49 # ok 13.41.18 # so what unit does cue files normally use? 13.41.27 # ms? sample number? byte index? 13.41.39 # hr:mm:ss 13.41.52 # second resolution? 13.42.25 # actually it's MM:SS:FR (minute-second-frame) 13.42.42 # still a pain to find at run-time 13.42.49 # better than nothing 13.43.11 # Bagder: can't it be done as if the user was seeking ? 13.43.16 # JdGordon: I'm not so sure about that 13.43.17 # if we store ms offset it will be relativly easy to sek on all formats 13.43.44 # Nico_P: yes I bet, but it is quite an operation 13.44.05 # i don't quite realize what would be involved 13.44.21 # codecs with VBR 13.44.25 # well, it would only happen if the user actually loaded a cue (or any bookmarkable) file 13.46.26 # still, there's no such support today to load a given track and fast forward to a specific point and then only load a certain amount from there 13.46.40 # how hard would that be to add? 13.46.52 # no idea 13.47.12 # given the problems we already have with playback, a guess would be fairly tricky 13.47.31 # actually, only a moron would use VBR with cue sheets 13.47.52 # we'd still have to support those morons, wouldn't we? 13.48.09 # we support a lot of morons, so why exclude them? :-) 13.48.10 # well... not only cue sheets... any format which allows for chapters/bookmarks/sub tracks 13.48.15 # haha 13.48.26 # can that go on the golden quotes page? 13.48.32 # haha 13.48.55 # be my guest 13.49.14 # more asking because might not like the idea of one of those morons reading it :D 13.49.49 # lets hope they don't use WMA either... 13.49.58 # LinusN: why? if you ask me, only a moron would use mp3 cbr at all 13.50.01 # cue support with WMA! 13.50.07 # the ulitimate combo 13.50.50 # and then I wanna fast forward back and forth over the track change points, with sound! 13.51.06 # preglow: because it is a PITA to seek to a specific point in time 13.51.30 # LinusN: sure, but good players support it, so why shouldn't people use it? 13.51.51 # cue sheet != good 13.51.57 # so bad players, like rockbox, can support cue sheets? 13.52.02 # using mp3 at all is braindead, imho :> 13.52.06 # cue sheets are a strange inventuion 13.52.22 # cue sheet == hack to solve the gapless problem 13.52.47 # which we don't have 13.52.52 # well, given the fact that people just were not able to code gapless support at all in the old days (some still arenn't), i think it's an ok solution 13.52.52 # exactly 13.52.56 # not very nice, but hell 13.54.34 # but no, i'm afraid vbr with cue is rather common 13.54.49 # so if we're going to support cue sheets at all, we should support that too 13.54.59 # but that will involve a rather lengthy scan of the whole file 13.55.40 # guys... I'm not asking for cue support... rather support for adding tracks in other tracks, format sholdnt make any difference 13.56.27 # i'd like to discuss this with you guys, but i have to go to class :( 13.56.30 # already late 13.56.33 # sure, if you're going to ignore the technical difficulties it doesn't matter 13.56.34 # but it does matter 13.57.33 # the difficulties are the buffering between the two points.. and they are done generically for all formats right? 13.59.23 # preglow: Why not just split mp3+cue into individual mp3s? I don't get it... 13.59.45 # mp3directcut can do it 14.00.20 # that doesn't work for other multitrack formats though 14.00.59 # amiconn: dunno, i only have very few cue/mp3 files and can bear to seek 14.01.05 # maybe also an issue if you want to use the same files with a player that doesn't do gapless 14.01.20 # yeah, but i assume it was meant as a rockbox solution 14.01.41 # but anyway 14.01.48 # i doubt these splitter tools can split in the middle of a frame 14.01.52 # or can they? 14.02.06 # probably not 14.02.26 # preglow: No, I think they will do what lame -nogap does 14.02.53 # amiconn: exactly, and your track switch points will then possibly sound different 14.03.02 # i've known people to complain over less :> 14.03.41 # i don't get it. why even try to split in the middle of a frame? 14.04.42 # because the song switch might be in the middle? 14.04.51 # very possible 14.04.58 # cd frame sizes are not the same as mp3 frame sizes 14.05.00 # not even close 14.05.43 # how long is an mp3 frame anyway? 14.05.56 # 1152 samples 14.06.02 # per channel 14.07.50 # ...for MPEG version 1 14.08.01 # version 2 and 2.5 frames are 576 samples 14.08.20 # Layer 2 frames are 1152 samples, always 14.08.31 # i was speaking primarily in the context of cue files 14.08.38 # which are cd images, thus 44.1khz, thus layer1 14.08.42 # ehh, version 1 14.09.18 # so the resolution is 26ms - not that bad is it? 14.09.38 # Yes, and the maximum 'error' hence is ~13ms 14.09.45 # (+/-) 14.09.50 # which is too small to notice 14.09.57 # nah, not by far 14.10.01 # but it depends on the material 14.10.23 # unlikely it is, impossible, no 14.12.03 # OK, im thouroughyly confused by the plalist code.. how does it store the filename of any track inserted other than dirplay ? 14.12.33 # JdGordon: Back to your question (buffering part of a file), the short answer is that you can't. The codec itself is responsible for seeking, the playback engine knows nothing about the data it's loading. 14.13.02 # ok, but cant the codec be told where to seek and how much to buffer on load? 14.15.46 # JdGordon: It doesn't store filenames, that's the whole magic behind it needing very little ram, and being very fast 14.16.26 # amiconn: what does it store? 14.17.17 # it doesnt seem to store anything 14.17.33 # JdGordon: the relative index in the playlist file (but queued filed are stored in .rockbox/.playlist_control) 14.19.13 # * JdGordon gives up :p 14.19.42 # JdGordon: The codec can be told to seek, but it's the playback code that does the loading... What you're suggesting isn't possible unless the playback engine becomes aware of file formats (which isn't a bad thing). 14.20.59 # the codecs dont just have a generic seek() function which could be called on load? (or a start/end point pased to the codec onl load?) 14.21.11 # I dont understand why it would be format dependant 14.24.57 # JdGordon: it might be difficult for the playback engine to know how much to buffer 14.26.18 # does the codec seeking work on time offsets or file position? 14.26.42 # JdGordon: Time offsets. 14.26.55 # ok, so where is the problem? 14.27.20 # the playback would just do codec_load(file, start, end)... or something 14.27.41 # JdGordon: The codec isn't running when the file is being loaded... 14.28.47 # no, but it could store those 2 offsets somewhere untill its ready to buffer, or playback could send them when codec is ready 14.29.12 # JdGordon: then it would have to load lots of data it'd never play 14.29.27 # the loading is done before the codec is loaded 14.29.33 # oh 14.29.41 # but it doesn't have to be like that 14.29.51 # * JdGordon should stay out of things he obviously knows nothing about 14.30.31 # JdGordon: still you have identified some issues that should go to the cuesheet wiki page 14.31.35 # It's also not just a matter of extracting part of the data from the middle of the file. Most formats rely on information in the file header. That's why I think we should forget about adding sub-tracks individually to the playlist, and just deal with the whole file. 14.32.36 # so wouldnt that format then read the header, then skip as expected tt he start of the subtrack? 14.32.37 # At least until we have container-format parsing separated from the codecs themselves, allowing the playback engine to be more intelligent when buffering. 14.32.58 # JdGordon: Yes, but the codecs don't access the disk - they can only access data in the audio buffer. 14.33.15 # Oh, damn, more complexity :p