How to translate PCM to floating-point

DSP, Plugin and Host development discussion.
RELATED
PRODUCTS

Post

BachRules wrote:Wondering how PCM is translated to floating-point.
BTW, "PCM" doesn't mean it's integer—it's still PCM when it's floating point, so you're really asking how to convert integer samples to floating point.

And PCM doesn't even imply linear samples (LPCM does), although it's the most common, especially since 16-bit and higher became cheap long ago, and these days people assume its linear unless noted otherwise.

Just clarifying semantics ;-)
My audio DSP blog: earlevel.com

Post

earlevel wrote:
BachRules wrote:Wondering how PCM is translated to floating-point.
BTW, "PCM" doesn't mean it's integer—it's still PCM when it's floating point, so you're really asking how to convert integer samples to floating point.

And PCM doesn't even imply linear samples (LPCM does), although it's the most common, especially since 16-bit and higher became cheap long ago, and these days people assume its linear unless noted otherwise.

Just clarifying semantics ;-)
Thanks, I appreciate it. I was brainwashed by misleading notation in Reaper:

Image

Or I misinterpreted good notation in Reaper. Either way.

If I called it "fixed point", would that be clear, at least in this context? Unfortunately having the same abbreviation as floating point though.
If you criticize Spitfire Audio, the mods will lock the thread.

Post

BachRules wrote:
earlevel wrote:
BachRules wrote:Wondering how PCM is translated to floating-point.
BTW, "PCM" doesn't mean it's integer—it's still PCM when it's floating point, so you're really asking how to convert integer samples to floating point.

And PCM doesn't even imply linear samples (LPCM does), although it's the most common, especially since 16-bit and higher became cheap long ago, and these days people assume its linear unless noted otherwise.

Just clarifying semantics ;-)
Thanks, I appreciate it. I was brainwashed by misleading notation in Reaper:

Image

Or I misinterpreted good notation in Reaper. Either way.

If I called it "fixed point", would that be clear, at least in this context? Unfortunately having the same abbreviation as floating point though.
I see, interesting in Reaper...but I'll guess that they are being influenced by the sketchy definitions in the wave file format. Floating point was added later in the spec, and they use an "IEEE floating point" format code that is distinct from the original "PCM" code. So while the choice between the two is really integer PCM or floating point PCM, it doesn't read that way—it reads as PCM or floating point. (And mulaw and alaw are distinct from PCM, even though they are PCM, because when the spec says PCM is means LPCM.)

Anyway, it's hardly a big deal, but if they use "FP", I suppose that they should have used "Int" for the integer/fixed. While, technically, we may do our calculations in "fixed point", the samples themselves are equivalently "integer"—the only difference is the way in which operations such as multiplication work. And it avoids the "FP = fixed point" issue.

PCM just means that the samples are evenly spaced, and the values of the samples are modulated and coded into a sample value. (I'm guessing at the thought process.) If you view sampling as multiplying (modulating) the analog signal by an impulse train, followed by coding each resulting sample into a value for digital storage, then "PCM" seems pretty descriptive and accurate.
My audio DSP blog: earlevel.com

Post

earlevel wrote:I see, interesting in Reaper...but I'll guess that they are being influenced by the sketchy definitions in the wave file format. Floating point was added later in the spec, and they use an "IEEE floating point" format code that is distinct from the original "PCM" code. So while the choice between the two is really integer PCM or floating point PCM, it doesn't read that way—it reads as PCM or floating point. (And mulaw and alaw are distinct from PCM, even though they are PCM, because when the spec says PCM is means LPCM.)

Anyway, it's hardly a big deal, but if they use "FP", I suppose that they should have used "Int" for the integer/fixed. While, technically, we may do our calculations in "fixed point", the samples themselves are equivalently "integer"—the only difference is the way in which operations such as multiplication work. And it avoids the "FP = fixed point" issue.

PCM just means that the samples are evenly spaced, and the values of the samples are modulated and coded into a sample value. (I'm guessing at the thought process.) If you view sampling as multiplying (modulating) the analog signal by an impulse train, followed by coding each resulting sample into a value for digital storage, then "PCM" seems pretty descriptive and accurate.
I'll call them "Int". It is good to get this sorted out; thanks.
If you criticize Spitfire Audio, the mods will lock the thread.

Post

4)

Int to Float:

Code: Select all

(integer>0?integer/0x7FFF:integer/0x8000)
Float to Int:

Code: Select all

float>0?float*0x7FFF:float*0x8000
dubious.
If you criticize Spitfire Audio, the mods will lock the thread.

Post

earlevel wrote: PCM just means that the samples are evenly spaced, and the values of the samples are modulated and coded into a sample value. (I'm guessing at the thought process.) If you view sampling as multiplying (modulating) the analog signal by an impulse train, followed by coding each resulting sample into a value for digital storage, then "PCM" seems pretty descriptive and accurate.
If I'm not mistaken, the WAV file specifications actually refer to linear, integer PCM as simply "PCM" and calls everything else something else. So technically in terms of WAV file encodings, calling it simply "PCM" is the correct thing to do. ;)

Post

BachRules wrote:
4)

Int to Float:

Code: Select all

(integer>0?integer/0x7FFF:integer/0x8000)
Float to Int:

Code: Select all

float>0?float*0x7FFF:float*0x8000
dubious.
That one doesn't make sense. Yes, binary integers, as we commonly store them in computer memory, are asymmetric with respect to their *maximums*. The run from -1.0 to almost +1. But we're talking about a single bit increment that missing, not the whole freaking scale of 0-1.0 being off (scaled to 0-0x7FFF).

Grab a CD of your choice. How many samples are 0x8000 or 0x7FFF? Most likely, it was mixed at least a little bit lower, so that the rails never get hit (ideally). Let's say you have a nice, symmetrical sine wave in floating point that runs -0.5 to 0.5. So, instead of converting that to integer samples with peaks at 0xC000 and 0x4000, you're going to have it go from 0xC000 to 0x3FFF and a half bit? (Sure, it will round up, or truncate down, but the point is, why scale the two sides of zero differently?)

The people who used this method were using flawed logic. They decided to retain *one* arbitrary, rarely used value (1.0) by messing up *32767* other values (and of course, logic dictates that you'd do the same with 24-bit and screw up 8,388,607 values). Maybe the converters in question were calibrated so that 0x7FFF was exactly -0x8000, but that too would be nuts.

I guess I could have cut it shorter by saying:

1. True: +1.0 is not representable in this integer system
2. False: +1.0 equals 0x7FFF

This scheme pretends that #2 is true.
My audio DSP blog: earlevel.com

Post

mystran wrote:
earlevel wrote: PCM just means that the samples are evenly spaced, and the values of the samples are modulated and coded into a sample value. (I'm guessing at the thought process.) If you view sampling as multiplying (modulating) the analog signal by an impulse train, followed by coding each resulting sample into a value for digital storage, then "PCM" seems pretty descriptive and accurate.
If I'm not mistaken, the WAV file specifications actually refer to linear, integer PCM as simply "PCM" and calls everything else something else. So technically in terms of WAV file encodings, calling it simply "PCM" is the correct thing to do. ;)
That's pretty much what I was saying, sorry if it wasn't clear. But redefining the term doesn't make it "the correct thing to do". "PCM" doesn't imply linear, and it doesn't imply integer. It doesn't even imply the binary number system.
My audio DSP blog: earlevel.com

Post

earlevel wrote:
mystran wrote:
earlevel wrote: PCM just means that the samples are evenly spaced, and the values of the samples are modulated and coded into a sample value. (I'm guessing at the thought process.) If you view sampling as multiplying (modulating) the analog signal by an impulse train, followed by coding each resulting sample into a value for digital storage, then "PCM" seems pretty descriptive and accurate.
If I'm not mistaken, the WAV file specifications actually refer to linear, integer PCM as simply "PCM" and calls everything else something else. So technically in terms of WAV file encodings, calling it simply "PCM" is the correct thing to do. ;)
That's pretty much what I was saying (see first paragraph), sorry if it wasn't clear. And sure, I get it that it was a dialog that saves to WAV. But my point was that I was explaining why the OP and subject line is not appropriate.

And I get your point that the suffixes in the formats of the Reaper dialog "is the correct thing to do". But I disagree. It would only be "expected" by someone intimately familiar with the WAV file format (a programmer who worked with the format). Others, not intimately familiar with the format spec, would either understand what PCM is, or not, and the choices used does not make it more understandable for either. For those, there is nothing "correct" about using terminology that's incorrect but is a convention that's well-known to other people familiar with the spec. In other words, it was "correct" to the Reaper programmer(s) involved, but just passes on incorrect terms to most of the rest of the Reaper users.

And why not 16-bit Int, 24-bit Int, 32-bit FP? That's almost always how I hear people discuss it. The dialog should display the formats in sample types as people know them, not how an underlying spec refers to them.

No big deal, just disagreeing that there is anything correct here. And it would be different if it were incorrect yet helpful. But I don't see anything helpful in the choice.
My audio DSP blog: earlevel.com

Post

Reaper declares Int 0x800000 equivalent to FP -1.0 throughout all time and space by dictatorial fiat:

http://forum.cockos.com/showpost.php?p= ... stcount=74
If you criticize Spitfire Audio, the mods will lock the thread.

Post

BachRules wrote: Thu Jun 26, 2014 6:34 pm So there's no standard defining what represents a clip in a 32-bit FP WAV file?
There are standards...

AES17 defines the meaning of full-scale amplitude:
amplitude of a 997-Hz sine wave whose positive peak value reaches the positive digital full scale, leaving the negative maximum code unused.

NOTE In 2's-complement representation, the negative peak is 1 LSB away from the negative maximum code.
As does IEC 61606-3:
amplitude of a 997 Hz sinusoid whose peak positive sample just reaches positive digital full-scale (in 2’s-complement a binary value of 0111…1111 to make up the word length) and whose peak negative sample just reaches a value one away from negative digital full-scale (1000…0001 to make up the word length) leaving the maximum negative code (1000…0000) unused
They don't explicitly map it to ±1.0, but I think that's implied by mapping it to 0 dBFS?

Post Reply

Return to “DSP and Plugin Development”