On Tue, Jan 6, 2015 at 5:02 PM, E Hartley <[email protected]> wrote:
> > My immediate suggestion is that the Lame encoding is at fault rather than > the Apple decoder. There is an understanding in MPEG that decoder > compliance is verified against reference bitstreams and that encoders must > produce bit streams / files capable of being decoded by the reference > software. No attempt is made to specify encoders. The fact that the fault > is appearing at the end of the file makes me think that the encoder is not > encoding the data or padding correctly for an audio file that is > temporarily smaller than an integer number of encoding units. The way to > verify this is either to dig into the MP3 file and inspect the structure or > decode it against the reference software. Neither of these are entirely > trivial. > You're seriously suggesting that the most widely used encoder in the world, one of the highest rated in almost all tests, and one whose source is all available has a problem? It isn't unbelievable but is an extraordinary claim. Compared to a bug that has nothing to do with the encoder or decoder, I'd wager on the latter.
_______________________________________________ Do not post admin requests to the list. They will be ignored. Coreaudio-api mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/coreaudio-api/archive%40mail-archive.com This email sent to [email protected]
