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?
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.
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
----- Original Message -----
From: "Mark Taylor" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, October 01, 2000 8:41 PM
Subject: Re: [MP3 ENCODER] lame 3.87 encode-decode roundtrip
>
> >
> > Please pardon the question if naive but I couldn't find the answer
> > elsewhere...
> >
> > I encode the same .wav to 2 different .mp3's - first one CBR
(-b256 -ms -h),
> > second one VBR (-V1 -b128 -mj -q1).
> > Then I decode (--decode) the 2 .mp3's back, and the resulting .wav's
have
> > different sizes, both of them different from the original one.
> >
> > Is this expected behaviour?
> >
> > Best Regards,
> > Liviu
> >
> >
>
> The docoded files should both be the same size, and they should
> both be a little larger than the original wav.
> Can you try encoding the VBR file with the -t option?
> lame --decode may decode the Xing VBR header into 1152 samples
> of padding.
>
> Mark
> --
> MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
