On 12 January 2016 at 13:39, Fernando Cassia <fcas...@gmail.com> wrote: > > On Tue, Jan 12, 2016 at 8:24 AM, Michael Schwendt <mschwe...@gmail.com> > wrote: >> >> Which would get funny, if you wanted to seek back and forth in a large >> chunk of data fed to a program via stdin, such as when searching for ID3 >> tags in an MP3 file. > > > Which gets back to my point, that doesn't prevent big media players from > implementing their own codecs, internally. > > Does Gnome/Nautilus mean that there is no place for the command line "tar" > command? or 'unzip' ? >
Of course not. However "the Unix way", while very powerful in certain contexts, doesn't work at all well for interactive use, or tasks that require communication between multiple data sources. There are command line encoders / decoders for many codecs. For some that does mean you have to wrangle with something like mencoder and worry about things like transport mechanisms. Which is the first thing you notice when dealing with anything more complex than mp3, mp3 itself mixes the transport and encoding, which makes it fairly simple to deal with. Actually, the various ID3 tags that Michael refers to are separate binary blocks bunged on at the end. Reading as a stream you can't actually access those, for example to display while playing, until *after* you've had all the audio data. To be stricly consistent with "the Unix way" (which has never really been the only way of doing things under Unix, but a convenient way of handling data that can be processed in a stream), you would have to stream the output of the decoder to the sound device too, probably via sox to convert the sample format (and possibly resample the frequency). Want to play back something that has a different sampling rate to your soundcard's default? You have to force resampling, because otherwise you'd have to communicate and negotiate sample rates out-of-channel. Similarly searching within a stream isn't allowed, because anything except a fixed bitrate input (which is very few audio codecs and almost no compressed video ones) requires the demuxer to be able to search through the input file (more trivially, going backwards is obviously not possible). -- imalone http://ibmalone.blogspot.co.uk -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
