[EMAIL PROTECTED] discourseth:
> On 17 Aug, [EMAIL PROTECTED] wrote:
> > Re the ui/pmo idea: Since I posted it I've run into a nasty technical
> > problem/realization: mp3 files aren't really seekable (that reservoir
> > of bits).  This is not good for loops, etc.  I think what I may end up
> > doing is decoding the mp3 into a temporary pcm file, showing how much
> > has been decoded in a meter and announcing `seeking' when the user
> > tries to go to a part that isn't decoded yet.  It's ugly, and I'd like
> > to be told there's a better way.
> 
> Well, FreeAmp supports seeking -- currently we don't really care about
> being frame accurate. But, let's assume for the moment that we could
> make it frame accurate and then support SMTP timecodes if we want to go
> that far.

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).

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.

> What interface do you need in your end? Give me a better idea
> of how you need to request the audio data, and I'll see if I can cook
> up something that meets your needs.

DIRT SIMPLE SPEC FOR THE ORIGINAL PLAN
(no symbolic control protocol needed..you can just use sscanf() :)

Frame-server is invoked on a file name.  It writes an acknowledgement
line to stderr..either:

  nak:<reason the file is no good>

or

  <decoded frame size>:<number of frames>:<sampling rate>:<number of channels>

It then reads lines from stdin of the form:

  <frame to seek to>:<number of frames to decode>

It writes decoded frames to stdout.  On receiving EOF on stdin it
exits.

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.

Eric

Reply via email to