mpg123 not included, why?

[Ian Malone]

On 12 January 2016 at 14:31, Fernando Cassia <fcassia at gmail.com> wrote:
>
> On Tue, Jan 12, 2016 at 9:21 AM, Ian Malone <ibmalone at gmail.com> wrote:
>>
>> If you want to do that
>> you have to cheat and cache everything before you start playback. Or,
>> in more general terms, doing anything non-linear with multimedia
>> information is very difficult to handle in a streamed manner
>
>
> No. I never said I wanted to "stream" anything. I wanted to play a local mp3
> file sitting on my hard drive, to the default speakers. Mpg123 serves that
> purpose.
> And as it fits the bill of "the unix way" (a simle, self-contained tool
> doing a single thing and doing it efficiently),IMHO it should be part of the
> standard toolset. That was my reasoning and I stick with that.
>

By stream I mean pipe in this context, a single data stream, which is
what people typically mean when they talk about "the unix way", where
separate processing steps can be chained together. Of course since
there isn't one Unix way people can mean lots of different things.

> Now, if we drift the topic to "how to do a mp3 player" I bet I could design
> a player using mpg123 and standard command line gnu tools that performs much
> faster than one relying on the tons of smegma that come along Gstreamer +
> GUI toolkits that Gnome/KDE multimedia APIs.
>

Of course you could, it's called mpg123. It has terminal controls, you
don't really need to add tar, awk or cpio to it to make it work. Now
let's see it support wav, Vorbis, Opus and AAC.

> What you call "cheating" (pre-loading the id3 info before loading every song
> instead of loading the whole file into ram, seeking to the end, and
> extracting the id3 info as each file is played) is actually efficient
> design, in my book.
>

It is cheating insofar as it does not work in a single data pipe
without caching the entire stream, which doesn't scale well for long
streams.

> Btw: id3 info could be obtained by using the http feature of requesting part
> of a file(*), by first obtaining the file size, closing the connection, then
> requesting the last "x" bytes (total file size - id3), that way you get your
> Id3 over "streaming" before requesting the whole file. :)
>

You are proposing having an http server in the way as *simpler*?
Anyway, again, id3 tag lengths are not fixed.

Media players do not fit well into the 'simple tool does one thing to
a file' model because they are always expected to do other things. An
interactive command line tool like mpg123 is already well beyond the
simple single data stream in single data stream out model.

-- 
imalone
http://ibmalone.blogspot.co.uk