Jonathan Gordon wrote:
Firstly, another bit needs to be stolen from the playlist index
variable which lowers the maximum playlist size to 128M instead of
256M (still plenty big enough for anyone).
This bit will be used to determine if the track has start/end position
which would be stored in the 8 bytes after the track name.
A new function would be added to add an entry with time (so minimal
changes need be made elsewhere).
I think thats the easy bit. the bit I'm stuck at is telling the
playback engine to buffer only the parts of the track requested.
Once this is done then a cue parser would need to be added and the
playlist viewer would need some prettying up to make it work properly,
but there is no point working on them until this works.
So, would this work? and can anyone help get the playback part working
once the position info is there?
Question is, when would this information be added? If done during
playlist load, it slow things down a lot, and adding it afterwards seems
tricky (and would cause a jumping playlist count).
Another thing that complicates matters is that some codecs need to read
data from the file header, so just buffering a part in the middle
wouldn't work for them.
Btw, this notion of several tracks in one file would be useful for some
other formats too (like Vorbis).
