Hi,
We are implementing the MPEG2 Audio Decoder and while going through the
standard found some discrepencies in the standard. Specifically in the case of
scalefactor decoding for Mixed block, the syntax of main data specifies for long
sfb boundary is 8 while the semantics says the no. of sfbs is 6. Which one is
correct ?
Acc to standard, the first 36 samples in mixed block will be coded as long
blocks and remaining as short blocks. In that case, we think it should be 6 as,
for samples 0-35 the first 6 sfbs will be from long block case (In case of
MPEG-1 it was 8). Then short scale factors will start from 36th sample which
correspond to 3-12 sfbs in short block. Is this logic correct ?? Please clarify.
We were going thro the net and found this site, which gives some discreprencies
in the standard... But still it was not clear whether it is 6 or 8 and so this
mail. Please clarify.
http://www.mail-archive.com/mp3encoder@geek.rcc.se/msg02383.html
regards,
Nagaraja S
Title: RE: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if
mp3encoder
RE: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
- From: Alex Broadhead
- Subject: RE: [MP3 ENCODER] Decoder quality comparison [quite detailed - sorry if repeat]
- Date: Wed, 19 Apr 2000 10:11:50 -0700
Howdy All,
I recently finished completely overhauling the ISO 'dist10' LSF decoder to
extract a layer-III only player for work. In the process, I discovered a
few bugs/inconsistencies in/between the 'dist10' distribution and ISO/IEC
11172-3 and 13818-3. I don't know if they would account for the differences
you are reporting, but they certainly might contribute.
Here's what I found:
1) In the joint stereo processing function, in the intensity stereo
block, for both mixed and short there is a bug in the code - after the lower
frequency bands are handled, the highest band, for which no scalefactors are
transmitted, is supposed to be filled with the values for the next lowest
band. However the code instead writes over the values in the 11th band by
mistake, and leaves the 12th (highest) band uninitialized. This is clearly
wrong, and fixing it makes a difference in the highest frequencies of
short/mixed intensity coded blocks.
2) In the requantization function, the boundary for mixed, LSF
blocks is wrong. For MPEG-1, it is band 8, but for MPEG-2, it should be 6.
I've never encountered any mixed blocks, so I only found this while
simulating mangled input bitstreams, where it causes hangs/crashes. The
same error is repeated in the LSF decode scalefactors function (8 for 6),
and this time it is also a discrepancy with the spec, which says 6.
3) The spec has a bug - when reading side info and
window_switching_flag is true, the spec says that region1_count can be set
to 36. This is totally false. The 'dist10' code has the correct
formulation, which is 20 - region0_count.
4) Finally, the spec is very misleading about the order of
processing. It lists joint stereo processing as occurring after reorder.
However, the 'dist10' code does reorder after joint. I'm sure you could
reverse this, but it makes a big difference in the joint stereo block. If
you just naively switch them, everything seems OK until you try to decode an
intensity coded block, at which point you get very different results.
I should point out that in testing I also observed numerous non-trivial
discrepancies between the output of L3dec (v.274) and the ISO code when
using LSF (i.e. MPEG-2's lower sampling frequencies) (or maybe intensity -
they typically switch on at the same time) which I could not account for
with the above buggage (actually, I didn't try bug 4). Either there are
further (undetected) bugs in 'dist10', or ISO and FhG disagree on how
LSF(/intensity) should be handled...
If anyone has any similar experience, I'd appreciate their comments,
Alex
> -----Original Message-----
> From: Matthew Lloyd [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 18, 2000 4:54 PM
> To: [EMAIL PROTECTED]
> Subject: [MP3 ENCODER] Decoder quality comparison [quite detailed -
> sorry if repeat]
...
> My first discovery was that out of the four WAV files I had,
> three were
> almost exactly identical. The decoded audio from aE4 and the
> Fraunhofer
> WinAmp codec was byte-by-byte identical with that from l3dec
> apart from the
> occasional 1-bit quantization error (v occasional - about 2
> or 3 a second
> I'd guess). However the Nitrane WAV, whilst identical in almost every
> respect and certainly identical below 13kHz, showed differences in the
> 13khz-16khz band.
...
> This is clearly a bug, either in fraunhofer's code or
> nitrane's code. I
> could not hear the differences (untrained ear) nor could I
> verify which was
> more 'correct' to the mp3 format since I know nothing of
> this. My immediate
> conclusion would be that Nitrane has a bug that is causing
> these errors.
> However, since Nullsoft have licensed Fraunhofer's mp3 decoding code
> already, for version v2.2, and since the v2.6 Nitrane
> decoder's about box
> still has a panel crediting the mp3 decoder license to
> Fraunhofer, why would
> Nullsoft exchange a perfectly good piece of Fraunhofer code
> for Nitrane code
> that produces these bugs? Are these bugs actually original
> bugs in the ISO
> implementation upon which presumably Fraunhofer's code is
> based? Are these
> differences worry-worthy?
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
