In reply to:

---

Incidentally, if you're switching to the Xing VBR encoder that's in AudioCatalyst, I suggest that you skip the middle bitrate setting (called "Normal") altogether and go straight for the next one up, the one called "Normal/High".

---

Agreed - this is what I almost always use, and I can definately tell a difference at this stage.
-mark

...proud to have owned one of the first Mark I units

In reply to:

---

The Xaudio decoder is, as with almost all decoders, +- 0.5 bit (ie, the lowest bit of the output can differ from that of the frauhofer reference decoder).

---

The Xaudio decoder produces different output depending on platform. According to the compliance tests I have performed, the x86 version indeed passes the strictest accuracy test, but the ARM version passes only the limited accuracy test.

What do I mean?

Part 4 of ISO/IEC 11172 defines the compliance tests for MPEG audio and video. Section 2.6.3 defines the computational accuracy tests for audio decoders. It states, "To be called an ISO/IEC 11172-3 audio decoder, the decoder shall provide an output such that the rms level of the difference signal between the output of the decoder under test and the supplied reference output is less than 2^(-15)/sqrt(12) for the supplied sine sweep (20Hz-10kHz) with an amplitude of -20dB relative to full scale. In addition, the difference signal shall have a maximum absolute value of at most 2^(-14) relative to full-scale."

Then it says, "To be called a limited accuracy ISO/IEC 11172-3 audio decoder, the decoder shall provide an output for a provided test sequence such that the rms level of the difference signal between the output of the decoder under test and the supplied reference output is less than 2^(-11)/sqrt(12) for the supplied sine sweep (20Hz-10kHz) with an amplitude of -20dB relative to full scale."

The tests treat the decoder output as 24-bit signed fractional values in the range [-1, 1). In other words, the binary point is immediately after the sign bit. For the purposes of compliance testing, where only 16 bits of output are available, the remaining bits are set to zero. When I tested version 1.3.1 of the Xaudio decoder library under both x86 and ARM, here's what I found:

Xaudio 1.3.1, x86
  RMS level = 8.602 x 10^-6 (under 8.810 x 10^-6; full accuracy compliant)
  Max diff = 1.538 x 10^-5 (under 6.104 x 10^-5; full accuracy compliant)

Xaudio 1.3.1, ARM
  RMS level = 2.065 x 10^-5 (over 8.810 x 10^-6 but under 1.410 x 10^-4; limited accuracy compliant)
  Max diff = 6.580 x 10^-5 (over 6.104 x 10^-5)

As you can see, Xaudio's accuracy under ARM is worse than +- 0.5 bit; it's more like +- 2 bits, i.e., the 16-bit integer value can differ from the reference output by as much as 4 in either direction.

I'd be happy to share the Perl scripts I used to calculate these. The bitstreams and reference output used for compliance testing can be found here.

I'm curious; what decoder are you considering switching to?

-v

In reply to:

---

Being engineer types, we spent a little while trying to figure out what could possibly change in the audio signal that could cause a change in the apparent _height_ of a voice. Can any of you audiophiles shed some light on this one?

---

I'll chime in on this one. The reason, simply, is that your ears are not round.

The main theory of why a persons ears have all the little dents and whorls and are generally asymmetrical is to do with the person's ability to locate a sound in space. The shape of the ear affects the way sound enters the ear - sound from behind you generally loses some of its high frequency components. Normally, you can tell where a sound is coming from in the horizontal plane by a combination of phase changes, timing changes, and frequency and volume alterations (as the sound travels around your head, for example). Positioning a sound in the vertical plane is done by associating various frequency responses with various 'heights'.

Now, the frequency response graph is an arcane thing, but generally, for instance, sounds coming from behind and below lose more of their high frequency components. Therefore, all other things being equal, something with boosted trebles sounds like it's coming from above. If the MP3 recording had some treble distortion, which in other points in this thread has been pointed out to be the case, it might simulate this effect.

That's my guess, anyway.

Save the whales. Feed the hungry. Free the mallocs.