Hi
>
> > :: My purpose was to measure the computational accuracy of
> > audio decoders in the
> > :: manner described by ISO/IEC 11172-4.
> > ::
> > The result is a ISO/IEC 11172-4 compliant decoder. It's not
> > so much better
> > than a ISO 9001 certificate. A decoder with a bug fails the test.
> > But not vice versa.
>
> What would 'not vice versa' mean in this case? That a decoder without bugs
> doesn't pass the test? (Is this possible?) That a decoder with bugs can
> pass the test? (This is certainly possible (as Mark pointed out much
> earlier), but also certainly beyond the scope of Rob's current effort.)
>
Let me join at this point.
Vice versa means here that that decoder witout a bugs can fail the test.
That test suit contain a set of coded streams and decoded PCM files.
(In some parts "reference decoder" is supplied instead of PCMs.)
I suppose you are talking about
ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio/mpeg2/compliance/testdata
and
ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio/mpeg1/compliance.
I used a script which decodes test streams and compare results with
supplied PCMs. The problems are the following:
- PCM can has either 16 or 24 bit samples;
- some PCMs has larger size than they should, usually they are padded
with zero samples
- in one stream stereo and mono frames are mixed! (modes*)
- one stream (sync*) is a special to test decoder for syncronization.
(main_data_begin > 0 in first frame). UNless the process of recovering
is not standartised, you can have very different samples in first frames
and it is possible to catch syncronization earlier than it is done in
reference PCM.
- some tests are for the MultiChannel extension. While reference code exist
for L1 MC and L2 MC, I failed to locate any L3 MC sources, even decoders.
(Please, let me know if you have any.). After I've tried to implement
decoder using only spec (13818-3), I'm doubting in some reference PCM.
To pass all this test you should explore each first, adapt decoder or test
program for that if it is possible.
On success pass you usually won't have maximum error more than 1.
And the probability of the error is about 0.001 if rounding to nearest
is performed (for single float internal precision).
Really it is very good tests. At least they check a lot of possible
modes and settings. I've locate a lot of bugs with it.
Don't try to hear these streams - they are for digital testing.
You can test very precise a decoder if you have time. Or if it is your
decoder or your occupation.
...
>
> > But with round-to-nearest-integer you only got a usable
> > dynamics of 55 dB
> > (CCIR). With better methods you can increase this value up to
> > 86 dB (CCIR).
>
> These numbers fly in the face of the standard statistical modelling of fixed
> quantization, which claims (under a number of assumptions, some of which
> could be bad in this particular case, I suppose) that SNR(dB) = 6B - 7.2,
> where B is the number of bits. [Rabiner & Schafer, Digital Processing of
> Speech Signals, p.185, c. 1978] I guess I'll have to check out the CCIR
> definitions when I get some time.
>
As I understand:
Rounding to nearest means maximum error is 0.5, so we have
10*log10((32767 / 0.5) ^ 2) = 96 dB.
Magic number for mpeg audio encoder.
(^2 means square - we sense an energy of a signal)
...
Regards,
-Leonid
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
