On Tue, Jan 11, 2011 at 3:17 AM, Thomas Orgis <thomas-forum@...:
> > There might be an API possibility where you return a special code to the
> > calling program and allow them to either continue reading or not...
> Ah, well, it is a question how much the libmpg123 library can do. Ususally,
> it's the program using the library that knows if there is web radio going on
> or not. Then it can just disable gapless code. Perhaps the library could try
> to mangle the default to off when it gets an ICY interval... but I'm not
> sure if this logic should go there.
> > I don't personally understand the difference between cases 2 and 3... or
> > 3 simply an extension of 2?
> > But, what are these false positives? What are the consequences?
> Point 2 means that gapless decoding will be disabled for all streams played
> from HTTP. That can also hit a set of files that you put on a HTTP server as
> means of distribution -- where you indeed want the gapless decoding,
> Point 3 is about doing the gapless work as normal, to indeed chop the
> leading jingle to its intended sample-accurate length, but then reasoning
> about all the MPEG-shaped data still coming and deciding that one might
> treat it as the next "file". This was meant regardless of the stream coming
> from HTTP or not (as libmpg123 doesn't really care about that) -- and so
> could start interpreting junk that people attached to MPEG files locally.
> People do everything feasible. Fact is, though, that curently, libmpg123
> indeed parses (and decodes, if possible) the trailing junk, but does not
> produce any output samples because of the sample count limit. That needs to
> change anyway; gapless decoding should at least return MPG123_DONE and stop
So you're leading us to one conclusion, really, and that's that ideally the
person using the library in their code should explicitly decide whether or
not any stream is gapless or not.
Here's a first cut... three decoding modes.
ONE_SHOT: you read one mpg file/equivalent and stop cleanly, regardless of
whether there's any further data coming.
GAPLESS: when one file finishes, you continue to read on that stream.
BEST_GUESS: This is what older code will use by default - where you look
ahead at material after the end of one mpg file, attempt to parse at least
some of it, and continue the stream if successful (adjusting the sample
length) or emit MPG_DONE (and a warning to stderr) if you can't parse the
remaining data in the file or stream.
> > Since good error recovery is apparently a feature of yours, recovering
> > this might be good.
> Damn, now you cornered me! ;-)
> > The fact that far more people listen to net.radio than play multiple
> > from http on a command line! So IMHO mpg123 should be concentrating on
> > net.radio listeners more.
> Hm, well, I don't like trade-offs until it is clear that one cannot reach a
> compromise without losers... that's what this discussion is for.
> Alrighty then,
> Gaining the trust of online customers is vital for the success of any
> that requires sensitive data to be transmitted over the Web. Learn how to
> best implement a security strategy that keeps consumers' information secure
> and instills the confidence they need to proceed with transactions.
> mpg123-users mailing list
http://radio.swirly.com - art music radio 24/7 366/1000