Testing for "MP3-ness" of input

[Ryan C. Gordon]

> Clearly that's not good enough for auto-detecting the type of sound, but
> maybe we should skip the test if the user insists that it is MP3? I've
> included a completely untested patch - I'm still at work and won't be
> able to even compile it until I get back home - to show how I mean. Does
> it seem like a reasonable idea?

I was planning on doing this for Shorten (.SHN) support, which has a
32-bit magic number ("ajkg" as an ascii string), which is usually at the
start of the file, but can be at any byte offset, in which case we can
throw away the data prior to that. That is obnoxious (as I bet that
sequence shows up in other binary files), so, by default, that decoder
will onyl search for the magic number if the extension passed in to the
open() method is (case insensitive) "SHN", otherwise, it has to be at
offset 0.

So, in short, yeah, let's do that. We'll probably need to for something
like icecast streams anyhow, which I bet don't necessarily give you a
valid header.

(do you want me to keep carbon copying this address, or is this new
address subscribed to the mailing list now?)

--ryan.