-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have noticed that that the .raw files generated by minimad and madplay differ slightly. For example, decoding a small .mp3 file the result was: 2428416 with madplay 2433024 with minimad
What is the reason for this?
Thanks.
On Tuesday, September 23, 2003, at 06:16 PM, Rafael Avila de Espíndola wrote:
I have noticed that that the .raw files generated by minimad and madplay differ slightly. For example, decoding a small .mp3 file the result was: 2428416 with madplay 2433024 with minimad
What is the reason for this?
I think you have these numbers reversed; normally madplay may be able to decode an additional frame over minimad.
The reason is that the API for libmad requires that whole frames be followed by at least MAD_BUFFER_GUARD (8) additional bytes in order to be decoded. To ensure this property, madplay handles the end-of-file condition specially. For simplicity, minimad does not.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I have noticed that that the .raw files generated by minimad and madplay differ slightly. For example, decoding a small .mp3 file the result was: 2428416 with madplay 2433024 with minimad
What is the reason for this?
I think you have these numbers reversed; normally madplay may be able to decode an additional frame over minimad.
The reason is that the API for libmad requires that whole frames be followed by at least MAD_BUFFER_GUARD (8) additional bytes in order to be decoded. To ensure this property, madplay handles the end-of-file condition specially. For simplicity, minimad does not.
I had the correct numbers. Following minimad and madplay execution with gdb revealed that in this case the difference was caused by a xing frame.
Thanks Rafael
-
Rafael Avila de Espíndola -
Rob Leslie