>
> True, it was the -t encode switch.
> By the way, isn't "lame -?" << -t disable writing wav header when
> using --decode >> a bit misleading about this?
>
Yes, that is a little misleading: "-t" option is listed twice,
since it disables wav headers when decoding, and disables
Xing headers when encoding.
> Thank you,
> Liviu
>
> P.S. The resulting .wav's are slightly _smaller_ than the original, see file
> listing below - t4.wav is the original wav, t4*.mp3 the encoded mp3's and
> t4*.wav the decoded wav's.
>
Could easily be a bug in LAME. But before I look into this, can
you do one more thing: compare the .wav headers? LAME writes
a very spartin .wav header. t4.wav may include some extra "chunks"
not in the LAME produced wav headers.
> 14,276,684 t4.wav
>
> 2,590,511 t4_b256_ms_h.mp3
> 1,862,685 t4_V1_b128_mj_q1.mp3
> 1,862,268 t4_V1_b128_mj_q1_t.mp3
>
> 14,275,816 t4_b256_ms_h.wav
> 14,280,424 t4_V1_b128_mj_q1.wav
> 14,275,816 t4_V1_b128_mj_q1_t.wav
>
>
There does seem to be a bug in lame 3.87 - the decoder no longer
recognizes the VBR header, and instead encodes it as silence.
This is why t4_V1_b128_mj_q1.wav is larger.
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
