No mate, that's not a bug. It's a feature! ;) In the absence of a global file identifier specification to prevent collisions, a file extension can serve as a hackish substitute. A global file type attribute for every file (built into the file system) would be much more elegant. 128 bits should give us enough types to last awhile. =)
Unfortunately, simply attempting to extend existing crufty operating systems will only create more non-orthogonal and demented code as long as a designer cares about "backward-compatibility." Intentionally delving deeper into special cases may yield pathologically cryptic or disfunctional code. Specifically, embedding knowledge of RIFF WAV (PCM) in the MPEG interpreter (and vice versa) violates modularity. While not difficult to implement for this case, why stop there? Why not embed knowledge of every other input audio format supported into every input audio format interpreter? If we do stop at RIFF WAV and MPEG stream identification, then we can successfully limit our dementia. With only some brain-damage, we could unify identification of MPEG audio stream with RIFF WAV as a pre-filter. If anyone wants "modularity", we can show them the single module, and say, "You want modules? Here's your stinkin' module!" =) However, addressing the "30 gazillion" error issue itself is worthy regardless of file identification. I propose a functionality roughly like an imagined "--sanity-max_consecutive_resync" option. Despite the pretentious assertions and flippant impetuous arrogance of Mr. Poag's peculiar report and politically incorrect attempt at humor, this report does reaffirm several traditional software design principles. =) Among them: - Users may do weird things. Don't trust them. When they do, bombard them with tons of cryptic error messages to discourage them from doing so again. But whatever you do, don't bombard users with tons of cryptic error messages for doing normal things. That would just encourage them to do weird things. - One man's crap is another's fertilizer. Often, that man's crap could also serve as that same man's fertilizer, but he just doesn't want to deal with it. - Bones contain phosphorus. So does crap. Extracting phosphorus from them to make fireworks is not wise. The addition of phosphorus creates pyrotechnic compositions highly sensitive to friction or shock. This sensitivity to ignition is quite useful in matches. Kind regards, - John On Thu, 21 Nov 2002, Bowie J. Poag wrote: > > Howdy all, > > Here's a nice bug.. lame 3.93 (and from the looks of it, every version > before it..) identifies files based purely on the friggin suffix of the > filename. World-class coding there, guys. (*chuckle*) .... Anyway, I've > managed to control my laughter long enough to post a note about it. > [...] > bitstream problem: resyncing... > bitstream problem: resyncing... > bitstream problem: resyncing... > bitstream problem: resyncing... > Error: number of channels has changed in MP3 file - not supported > Error: sample frequency has changed in MP3 file - not supported > (...same messages repeated about 30 gazillion times...) > [...] > To further prove my point, rename foo.MP3 back to foo.wav, and lame > encodes it without complaint. > > Whoever is responsible for that piece of crap-code aught to be shot, > hung, drawn, quartered, buried, dug up, their bones crushed into powder, > the phosphorous extracted from them and used in fireworks that spell out [...] _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
