> > _very_ few. Every mdct sample is about 38 Hz wide, so you wouldn't even cut
> > away the first (or zeroeth, whatever) sample.
>
> There is no such thing as 'zeroeth' !
> Remember the "when does the millenium start" problem ? :-)
Hey, C and Perl both start arrays with index 0. I trust them more than
I trust historians.
>
> > The reason ISO recommends highpass filtering is to cut away the DC portions,
> > which mp3 can't directly represents (it is a combination of the 0'th and
> > 575'th sample. The 575'th normally gets set to zero, especially if you're
> > lowpass filtering).
> >
> > You get DC in a long block, if the sound contains some components < 19 Hz.
> >
> > DC leads to high-frequency echoes. (Some kind of phantom image of the true
> > sound at lower freqs).
>
> Hmm , can you explain why this happens ?
Okay, here comes:
- If you take the formulae for encoding and decoding 1 mdct block, and
combine them, it gives the original output + a half bandwidth modulated
mirror image. _If_ quantization would be perfect, overlapping blocks would
cancel this. (The mdct is a tdac transform (time domain alias cancellation)).
But of course, quantization is _not_ perfect. This is a general problem, not
only DC related.
- mdct works on the odd frequencies; this makes the problem worse for DC.
- If your frame is DC shifted, you typically get huge samples at mdct
index 0. Because the maximum sample value (after quant) is 8191+15, you end
up with the rest of that subband quantized not nearly good enough.
The 0'th subband is indices 0..3, i.e. 0..153 Hz (at 44.1 kHz samplerate).
I guess you can here 153 Hz...
- scalefactor allocation uses mean error, so if 1..3 can be reasonably
represented, the fact that 0 can't doesn't mean that much to the iteration
loops.
> Doesn't seem logical to me, but I'm no mp3/mdct expert.
>
> david balazic
It's just some math & observations.
Ciao,
Segher
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
