::
:: FK> May be mpg123 in october. I try to convince Michael Hipp to use my
:: FK> ultra-fast round-to-nearest-integer routines°°). If he uses these
:: FK> routines, it becomes very easy to use other quantization routines by
:: FK> simple replacing 2 routines by another and recompiling. Currently the
:: FK> quantization is spreaded around the whole program.
::
:: I guess I don't get your point. I understand your concern about quantization
:: noise in the last step of the decoding process, but this seems unavoidable, no
:: matter how you go about it.
::
Yes.
:: The amount of quantization noise is directly related to the precision of the
:: output, since as you noted, floating point output incurs no rounding. But even
:: floating point output has only a certain level of precision, and quantization
:: has already taken place.
::
Yes. So I wrote in braces: first approach.
:: 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.
:: 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 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.
But calculating the audible distortion by the RMS of the differences has
nearly nothing to do with human perception.
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).
:: 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.
:: 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.
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 !!!
--
Mit freundlichen Grüßen
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721 home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
