Quote:
Originally Posted by madshi
I don't see that in the source code. When "opts.pad_start" is 0, there is an additional "aften_encode_frame" call in the source code, where the first 1280 samples are set to zero and only the last 256 samples are real samples. When "opts.pad_start" is 1, there is no padding at all, as far as I can see from the source code.
Or is there some magic going on behind the scenes? But how can an additional "aften_encode_frame" call result in less padding?
I think the code should read "if(opts.pad_start)". But well, maybe I'm embarassing myself right now...  |
I'll try to explain the process better.
The encoder reads 1536 samples (1 frame) at a time, but due to the overlap/add process it needs 256 samples from the previous frame. At the start of encoding, those "delay" samples are just initialized to zero. This is the standard way of doing things, but will end up delaying the decoded output. When the option to get rid of the delay is turned on, Aften reads 256 input samples to prime the delay instead of zeros. That eliminates the decoding delay. The call to encode_frame() is really only used to get those samples into the delay buffer. The resulting frame is not actually written to the file output.
Hope that helps.