On 12 January 2016 at 14:31, Fernando Cassia <fcassia(a)gmail.com> wrote:
On Tue, Jan 12, 2016 at 9:21 AM, Ian Malone <ibmalone(a)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
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
Btw: id3 info could be obtained by using the http feature of
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.