From: Mark Taylor <mt@mp...> - 2001-09-17 20:30:28
> AL> are there issues which prevent the next version of lame to be a stable
> AL> release?
> well, I thought for a stable, it'd be very nice to have
> + nogap working correctly (needs work, AA + A_____B issue still unfixed)
> + that LAME Tag implemented completely (works now, but lacks delays
> and replaygain fields)
> could Robert/Mark/Gabriel please look into this delay fields? It's just
> two fields, one expresses the exact number of added encoder delay to
> the start (header not included) and the other the number of
> padding-0-samples at the end of the file.
I added a new function to the API
to compute the amount of padding that LAME appends to the end
of the input. I also added the code to VbrTag.c to retreive
this information, but wasn't sure how to pack it into the
Right now the padding POSTDELAY + enough to pad out a complete frame.
(POSTDELAY=288, is set in encoder.h). But we have to check some
decoders (including the one in lame) and see how much data they need
to encode the last frame. Suppose an mp3 file contains frames 0..N.
Because of frame overlap, we can correctly decode the first granule of
frame N, but the second granule needs 288 samples from frame N+1. So
decoders have a few choices:
1. dont bother with frame N, only fully decode frame N-1.
2. dont bother with granule 1 in frame N, only fully decode
granule 0 in frame N.
3. Recognize that this is the last frame in the stream, decode
granule 1, but only output the "correct part" = the first half
4. Fully decode frame N, assuming frame N+1 is all 0's.
I'm sure most do #1, which means we need to increase the padding
to pad out the current frame *and* add another frame.
Right now, LAME makes the extremely unlikely assumption the
decoder is doing #3, which is why POSTDELAY = 288. We should probably
raise this to 1152, which would mean pad out to a complete frame
*and* add an additional frame of padding.
Monday, September 17, 2001, 10:30:23 PM, you wrote:
MT> I added a new function to the API
MT> to compute the amount of padding that LAME appends to the end
MT> of the input. I also added the code to VbrTag.c to retreive
MT> this information, but wasn't sure how to pack it into the
int enc_delay=lame_get_encoder_delay(gfp); // encoder delay
int enc_padding=lame_get_encoder_padding(gfp); // encoder padding
tomorrow I'll see if it makes sense to me. if it works, I'll post the
diff, but I won't commit the CVS myself.
thanks very much Mark
MT> Right now the padding POSTDELAY + enough to pad out a complete frame.
MT> (POSTDELAY=288, is set in encoder.h). But we have to check some
MT> decoders (including the one in lame) and see how much data they need
MT> to encode the last frame.
naah, let that up to the decoders. Important only is now the decoder
CAN know exactly how much samples were added to start, and to end of
the file and do as it pleases. Not a concern of the encoder to account
for any decoding info imo.