[EMAIL PROTECTED] discourseth:
>
> You can get around this. I don't know about other decoders, but with
> the Xing decoder (which we are using) you should be able to feed the
> decoder the preceding frame(s) and decode them, toss them and then
> decode the frame you want.
Oooh..if there's a limit to how many frames we need to `prime' with
then this sounds good.
> You incur extra decode overhead, but its doable.
Overhead is OK..I'm dealing with disk accesses after all. (I
pre-schedule them cleverly :)
> > Also, I'm not sure how you could seek to the right frame in the first
> > place given that any number of frames in between may or may not have a
> > byte of padding each. This problem *could* be resolved by maintaining
> > a frame-map in an auxiliary file..really just a bitmap of the frames
> > with padding bytes.
>
> Especially in the case of VBR. When I was working at Xing, I worked
> with the other engineers to create the Xing TOC in the private data
> bits. It contains just what you describe -- we could easily enough come
> up with something analogous that we can use for CBR and VBR files that
> have no TOC.
Hmm..if this all came together it would truly be a breakthrough.
Thanks mucho for you enthusiasm!!
> > Now, I know you could do this really easily, but I don't think you
> > should until/unless the other concerns are resolved. I really hope
> > I'm wrong about them. Please let me know if you find out anything.
>
> Ok, I see where you're coming from. That should be easy enough to do.
BTW, I've familiarized myself with the xing API, so ultimately I can
use either that or a frame-server depending on what works out best
all-around.
Eric
