On 17 Aug, [EMAIL PROTECTED] wrote: > > I don't think it's just a matter of the accuracy of the seek. As I > understand the spec (and some experiments confirm it), if you seek to > frame N and decode it, the results aren't necessarily the same as they > are when you've decoded frames 0 through N-1 first. I believe I've > heard the results of this and they aren't acceptable (and I'm not even > an audiophile). 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. You incur extra decode overhead, but its doable. Let me go and ask the person who wrote the decoder for details, but I suspect it will be something along those lines... > 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. > 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. --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
