> Date: Thu, 7 Mar 2002 08:34:01 +0100 > > > MP3 files encoded with LAME 3.91 don't start with a real MPEG frame, but > > with a block of zeros the exact length of a frame (for CBR). This is not a > > problem for a decoder since it will ignore that "frame", but I belive is a > > bug anyway. Besides, for calculating the duration of the file, this adds > > aprox 26ms at 44100Hz. This didn't happen with version 3.88 Beta. > > It's not a bug at all, and is made on purpose. The first frame includes some > usefull info about encoding parameters. > The best way to deal with it would be if the decoder was ignoring this one. > As an example, if you decode with Lame --decode, Lame will ignore this > frame. > > Regards, > > ---- > Gabriel Bouvigne
But the first frame is still supposed to be a valid MPEG frame. It sounds like lame is writing the 0's, but then not going back at the end of the encoding and filling in the data (including the correct MPEG headers). This certainly works when lame is run as a command line application, maybe the frontend being used is doing something funny with the files so that lame isn't able to rewind the output file? Mark _______________________________________________ mp3encoder mailing list [EMAIL PROTECTED] http://minnie.tuhs.org/mailman/listinfo/mp3encoder
