> > Hello Segher,
> >
> > Friday, May 19, 2000, 10:48:54 AM, you wrote:
> >
> > >> After reading that extensive explanation that you posted a few weeks
> > >> ago, I'm under the impression that 96 0-samples won't change a thing
> > SB> Actually, 576 samples.
> >
> > 50% of granule of "SHORT_TYPE" or "STOP_TYPE" is 96 samples.
>
> 50% of short type is 192 samples
> 50% of stop type is 576 samples
>
> >
> > >> because these are the cause of the 0->1 factor up to 50% of the first
> > >> frame. Apologies for assuming the fix would be easy.
> > SB> Sorry, it's impossible even.
> >
> > It's hard to believe there is no way to (*)remove that "fade-in" or
> > "fade-out" effect by:
> > - feeding the encoder something for the 0th frame, so that the 1st 50%
> > of the 1st frame does not "fade"
> > - feed the encoder a modified first frame that compensates for the
> > 50% fade
> > - change the code so that frame 1 and last don't use 50% overlap.
>
> It's not the fade that is the problem, it's the mdct aliasing.
>
I disagree. There may be some problems created by the *filterbank*,
but the only attenuantion caused by the MDCT will be the first 96
samples. Here's an example:
granule 1 granule 2
576 samples 576 samples
| 192 | 192 | 192 | 192 | 192 | 192 |
data: < all zeros' >< real data >
short block <--------->
<--------->
<--------->
end block <---------------------->
output: | 192 | 192 | 192 |
granule 2 is the first granule that is encoded. granule 1 is
the ficticious previous granule that doesn't really exisit, except
that the output of the decoder for granule 2 is going to be combined with
the data in the buffer which would have held the decoded output of
granule 1. I will assume the decoder initializes this buffer with
zeros.
Lets ignore quantization. The lapped MDCT followed
by the IMDCT is lossless. That means that the IMDCT output
from granule 2 when added to the IMDCT output from granule 1
is indentical to the input.
In our case, the decoder just sets the granule 1 IMDCT output to all
0's because it never actually computes this and is just initializing a
buffer. But the output of granule 2 IMDCT is computed correctly.
output = granule_1_ouput + granule_2_output
granule_1_output: encoder uses all 0's, which is incorrect since
the MDCT (if it was performed) would have seen
some of the data in granule 2.
granule_2_outptu: correct
Therefor, the output will be correct *except* where it uses data from
granule 1, but this can effect at most the first 96 samples.
However, the polyphase filterbank is another story, and this
is something I hadn't thought about when I claimed only
the first 96 samples will be attenuated:
The data (with first 96 samples corrupt) is then sent to the
inverse polyphase filterbank. I dont know much about how this
albatross works, but I think it has an effective window length of
512. So the bad data in the first 96 samples can corrupt
samples up to 96+512.
Any idea how bad this corruption is?
btw, you cant check in it lame because it looks like the
filterbank (although the delay is only 48), is not "primed"
correctly, so the first 286 samples will be ignored.
I will fix this and post more about it next...
Mark
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
