> >
> > 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:
>
[...SNIP...]
> granule 2 is the first granule that is encoded. granule 1 is
I assume you mean 1+2 is the first encoded? 1 granule = 1152 samples.
Overlapping and stuff.
> 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.
>
Ok. But, unfortunately, we _can't_ ignore quantization, because we have a
_terribly_ bad granule-pair to encode: granule 2 contains sound which is
not just fading in, granule 1 is zeroed, so our encoding will be decoded
quite badly if there is _any_ quantization. And in the 1st block you output,
you don't have any bitreservoir to save you, either, I'm afraid.
> 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.
I don't understand this. I would think it would affect 0 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.
You can eliminate the poly bank delay as well, I think.
>
> Any idea how bad this corruption is?
The poly phase bank uses quite steep filters. Basically, the poly bank
is a 512 point fft, then a window (almost rectangular), fft back, dct.
>
> 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/ )
>
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
