3

I have come across this MSDN link: Intro to Audio Programming, Part 2: Demystifying the WAV Format. The post says that:

16-bit samples range from -32760 to 32760

which is not +/-(2^16)/2 because of

some crazy business involving Endianness and 2’s complement

There are multiple mistakes in this post, but this part irritated me the most. How much of that is true if anything?

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
user1146657
  • 194
  • 3
  • 15
  • 1
    Some very early oversampling converters had trouble with sample values that went all the way to the rails; some CDs couldn't be played on early CD players without distorting badly. Those problems were fixed a long time ago, but the data range restriction could be based on a desire for compatibility. Doubtful that endianness or 2's complement have anything to do with it. – Mark Ransom Oct 11 '17 at 20:05
  • @MarkRansom Interesting theory, thanks for the insight. – Kaganar Oct 11 '17 at 23:08

2 Answers2

4

The post is wrong in this regard. First, endianness has absolutely nothing to do with anything at all. But there is an issue with 2s complement which is that there are more negative values than positive values. Often times when performing signal processing the values will be converted to double precision in the range of -1.0 to 1.0 only to later to convert to the desired output bit resolution. If you were to multiply by 32768 and convert to an integer then you'd obviously get an overflow on the positive 1.0. So it is best to multiply by 32767. I don't know if this is formalized in any way but in my experience that is just the way it is. And if you follow this assumption you run a small risk of encountering a wave file with a value of -32768 in it and you'll get a number slightly less than -1.0 when converting to float.

jaket
  • 9,140
  • 2
  • 25
  • 44
  • I did some tests and it appears that it is safe to divide everything by 32768 . Because of how truncation works when casting from float to short int. If you modify floats, you need to clamp between -32768 and 32767 after multiplying anyway. In other words make sure that max value is < 1.0f; – user1146657 Feb 24 '16 at 15:48
2

I don't know if this is formalized in any way.

Yes! It is! Both what appears to be official RIFF spec and Broadcast WAVE format spec (which is supposed to be consumable by WAVE compliant applications) assert a pretty clear 16-bit sample range of -32768 to 32767 as jaket posited.

I've found I often need to take MSDN articles with a grain of salt, but they're sometimes hard to ignore since they're presented authoritatively. Searching the 'net for "wav 32760" will uncover some of the damage this article has done.

Kaganar
  • 6,540
  • 2
  • 26
  • 59
  • A spec that is a superset of another could easily have a greater data range than the one it is based on. – Mark Ransom Oct 11 '17 at 20:02
  • @MarkRansom In general that's a fair point. I've updated with a reference to what appears to be the official RIFF spec and specified more carefully why BWF applies here -- either way you look at it, 32760 appears to be a spurious number. – Kaganar Oct 11 '17 at 21:28
  • Nice find on that RIFF spec! It does indeed give an explicit -32768 to 32767 range. See my comment on the question for my own theory on how the restricted range came to exist. – Mark Ransom Oct 11 '17 at 21:37