Is there a way to predict this timeshift? Does anyone know if it's a
variable based on encoding or constant?
It's because of the encoder delay. Now (3.90) Lame writes a kind of header
into the first frame, and one of the fields of this header is the encoder
delay.
Gabriel Bouvigne wrote:
Is there a way to predict this timeshift? Does anyone know if it's a
variable based on encoding or constant?
It's because of the encoder delay. Now (3.90) Lame writes a kind of header
into the first frame, and one of the fields of this header is the encoder
Given that could a well written decoder strip it off and give time and
length coherency between source and result?
Yes, it's perfectly possible. However this tag is quite a new thing, and I
think that right now there is no encoder that uses (yet) this info.
On Wed, Dec 05, 2001 at 11:02:42AM +0100, Gabriel Bouvigne wrote:
Given that could a well written decoder strip it off and give time and
length coherency between source and result?
Yes, it's perfectly possible. However this tag is quite a new thing, and I
think that right now there is no
Ross Vandegrift wrote:
On Wed, Dec 05, 2001 at 11:02:42AM +0100, Gabriel Bouvigne wrote:
Given that could a well written decoder strip it off and give time and
length coherency between source and result?
Yes, it's perfectly possible. However this tag is quite a new thing, and I
On Wed, Dec 05, 2001 at 11:02:42AM +0100, Gabriel Bouvigne wrote:
Given that could a well written decoder strip it off and give time and
length coherency between source and result?
Yes, it's perfectly possible. However this tag is quite a new thing, and I
think that right
Hello all,
I've noticed that encoding/decoding an mp3 introduces a timeshit. For
example, encoding a 136,044 byte 44.1/16-bit WAV and then decoding and resampling
gives a 136,074 byte 44.1/16-bit WAV. The surprising thing is that the extra data
seems to be inserted at the
