mpg123 not included, why?

[Ian Malone]

On 12 January 2016 at 16:17, Fernando Cassia <fcassia at gmail.com> wrote:
>
> On Tue, Jan 12, 2016 at 10:59 AM, Ian Malone <ibmalone at gmail.com> wrote:
>>
>>
>>
>> You are proposing having an http server in the way as *simpler*?
>> Anyway, again, id3 tag lengths are not fixed.
>
>
> don't twist my words, Ian.
>
> I introduced a web server into the argument that you can't get id3 tags with
> a single tool, and you used the word "stream" by which I thought you mean
> music streaming from a web site (web server).
>
> So you CAN extract id3 data from mp3 files, whether locally (by using tail
> or id3tool or anything else) before loading the entire file. That was my
> point.
>
> And most MP3 files have ID3v1, not id3v2. ID3 v1 is fixed length @ 128
> bytes.
>
> http://id3.org/ID3v1
>

Where do I say anything else? Why are we on this bizarre sidetrack
about whether you can use tail to get id3 information? You're already
proposing effectively rebuilding id3info just because *part* of its
job can be done with text handling tools in some, but not all cases.
That is crazy and pointless. id3info is exactly the minimalist tool to
do this job and handle all the corner cases.

> ID3v2, on the other hand, is added at the start of the file. So you can
> check the last 128 bytes of the file to see if it's got ID3v1, and if not,
> check for ID3v2 at the start...
>

My point is still that you are scanning the whole file to do this. The
simple model for command line utilities that can be chained together
requires that a file argument can be replaced by stdin/stdout, which
for this case it cannot without taking liberties about what that
means. If I do xzcat < somefile > somefile.xz, data gets written as it
gets processed, we don't have to read and cache the whole of somefile
first.

Of course you can have single tools that act on files to get well
defined information. But while it's a useful model it doesn't work
well in all situations.

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