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).
Received on 2006-12-13