Roel VdB wrote:
>
> Hello David,
>
> Monday, May 22, 2000, 9:50:14 AM, you wrote:
>
> DB> How about prepending some "dummy" data to the input ( zero value samples
> DB> ), note its length and then encode it together with the normal input.
> DB> When decoding , just discard the noted length of samples ( + plus the
> DB> ones added by the decoder delay ) from the decoded data and start
> DB> playing
> DB> at the "right" spot ?
>
> DB> Because you are not cutting mp3 data , but normal samples , there should
> DB> be no added distortions. I think ... :-)
>
> This is what I initially suggested. That would somewhat work with a full album (1
>big wav), but if you rip
> track by track you have problems with the first/last frame: it
> fades in/out.
>
> The reason this happens is because the data before/after are _already_ 0's.
> It would make no sense to add more 0's because you would still get
> that fade. Adding more 0's would only delay the problem.
> Segher Boessen says you can clearly hear this when the two
> things are concatenated back together later and played as 1 whole.
Are you saying that lame ( or mp3 in general ) can not handle sound
coming
after a period of silence ? I find it hard to believe.
[ snip ]
> DB> - remove samples from the end of decoded.raw , until
> DB> length_of(decoded.raw) == length_of(music.raw)
>
> this is happening to great extent already in the new "--decode"
> function of Mark Taylor.
Hmm , where does it get the "length_of(music.raw)" ?
david
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
