Howdy,
> :: 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.)
> :: To do so requires obtaining the PCM output from the
> decoder, in whatever
> :: precision. You'll notice I was only able to obtain 16-bit
> precision from
> :: most of the decoders, so for these decoders the
> quantization noise is
> :: presumably +/- 1.526e-5 in the best case, and indeed this
> shows in the
> :: results. The compliance tests, however, allow this to be up to +/-
> :: 6.104e-5 and still be compliant.
> ::
> This is the RMS errors, not the audible noise. Especially on
> 96 kHz (MP3
> can't handle this) there are approximately 50...55 dB between
> RMS error and
> audible noise.
I don't think Rob ever claimed to be measuring audible noise - he is just
checking compliance, which deals with matching PCM output, i.e. RMS error.
> :: I think it's clear that output with more precision can
> reduce the resulting
> :: quantization noise, but that doesn't negate the test
> results for decoders with
> :: less precision, nor should the quantization strategy have
> any bearing on the
> :: tests.
> ::
> There are alot of buggy MP3 decoders out there.
Well, duh. And compliance checking is one way to find them.
> But calculating the audible distortion by the RMS of the
> differences has
> nearly nothing to do with human perception.
Perhaps you should explain this to the MPEG committee.
> 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.
> :: signal and the reference output signal, both of which
> have the same sampling
> :: frequency. If you want to optimize the output quality by
> resampling to a
> :: higher frequency based on internally higher precision
> samples, fine, but this
> :: doesn't change the fundamental computational accuracy of
> the decoder as
> :: measured by the compliance test.
> ::
> :: Do you disagree, or aren't the compliance test results
> therefore valid?
> ::
> compliance test are simple statically tests. Not less and not
> a little bit
> more.
I'm not sure when anyone claimed anything different?
> :: FYI, the strategy I took with MAD was to provide full
> (28-bit) internal
> :: precision output from the decoder library API and let the
> application decide
> :: how to scale or resample it to however many bits of
> precision it wants. So
> ::
> I want 86 dB (CCIR). That can be achived with 16 bit/44.1 kHz HQ
> quantization, by 13 bit/96 kHz HQ quantization or by 22 bit/44.1 kHz
> round-to-nearest-integer quantization.
Perhaps you should do us all a favor and come up with you own compliance
testing standard then? One which could evaluate how closely each decoded
file sounds like the reference decoded file? This is an extremely difficult
problem, as I'm sure you know.
> You don't need a color printer with (2^24)-1 color cartridges
> to print a true
> color picture. 4 or 7 are enough.
>
> Buy a sound card and listen to the test files !!!
Why? Rob is just trying to check MPEG compliance, which, as you have
overstated, has nothing to do with how files sound. (This is hardly true,
but, given that compliance can be checked without listening to the files, is
effectively unimportant.)
Not meaning to flamebait, but this thread seems to be generating an awful
lot of heat at this point, and not much light.
Frank: if your point is that a compliant bitstream is generally not the
best sounding one (where 'best' is defined by your taste), your point is now
well taken, and we can all read up on more effective interpolation schemes
to our hearts' content. If, however, your point is that Rob was wasting his
time by doing the compliance testing, your point is not well taken; many
people on this list actually appreciate and encourage this sort of selfless
activity. ISO 11172-4 may seem or even actually be stupid (it is from ISO,
after all), but it's what we have to work with, for better or worse.
Rob: Thanks for your work and your patience - I appreciate it.
Alex
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
