[EMAIL PROTECTED] discourseth:
> OK, here is the scoop. Given that you are seeking to frame n, you may
> need to back up m frames, decode and toss these m frames and then
> docode and use frame n. The hitch is that m is not known a priori -- it
> varies depending on the bitrate. It may be large with low bitrate
> streams. I know where in the decoder to check to see if the decoder is
> 'happy' with the decoded frame.
> Given this, I suggest that we can modify the decoder to include this
> check and then through empirical tests find out how many frames we need
> to back up given a particular bitrate. We can implement the seek so
> that it would be intelligent enough to catch when its guess as to how
> far to back up was wrong, and have it back up further.

Iterative deepening, doubling the backup each time would seem in
order.  That way you're guaranteed that >50% of the time you spend in
backup isn't `wasted'.

> At this point, I will do some of these empirical tests to see what the
> realistic numbers are. Then, we can take a look at it and see if we
> want to proceed with this approach.
> However, I will not be able to get around to doing that until mid
> september since Burning Man is just around the corner. How does that
> sound?

That sounds good.  I'm going to go ahead with my toc hacks using
mpg123 code for now since I promised users mp3 by the equinox.
However, I definitely want to pursue these quality issues and
switching to xing-based wouldn't be difficult and may be advisable for
other reaons as well.

Btw, the artist who's work I've been using for test purposes will be
playing at Burning Man on the main stage for the community dance after
the burn, probably around midnight.  His name is Astral Matrix

My working toc file format is as follows:
<mp3 file size>
<16-bit big-endian offsets from current point to next frame>...

Let me know if this seems obviously defficient in any way.

> I really like your idea, so its easy for me to get excited about this.
> One other thing I was thinking about -- since FreeAmp deals with the
> input and the output, would it make sense to have FreeAmp also deal
> with the output? That way you get suppport for 3 platforms, with 5
> different sound architectures.

I'll admit that I'm a bit of POSIX chauvinist, however, you know I'm
also into `device-independent'/networked i/o, so there may indeed be
some room for fun here.  Note that I'm going to be supporting multiple
cheap soundcards later this year (via separate processes with a
well-defined protocol) for both cue and surround sound.  This may be
another area where coordination with freeamp would be worthwhile.

> > 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.
> Cool, even if you don't want to use FreeAmp, I can help you build a
> more accurate seek.

You're the best! :)


Reply via email to