Incorrect 8 bit PCM render (FIXED)

[Tale]

When I render a WAV file with few seconds of silence in 8 bit PCM (without dither), and then add the resulting WAV file to a project, the meters indicate there is a DC signal of -48.2 dB instead of -inf dB (the render meter did indicate -inf dB BTW).

Apparently REAPER (v5.x, don't know about v4.x) seems to think that the 8 bit PCM value for silence is 127. However, I think this is incorrect, 128 is the correct value, and Audacity seems to agree with me.

I don't need 8 bit PCM myself, but I thought somebody else might. If so, and if this indeed is a bug, then I guess it would be nice if this could be fixed.

[For devs and/or those interested: I happened to spot this while adding 8 bit PCM support to WDL's WaveWriter and pcmfmtcvt (see the 'wavwrite' branch of my WDL repo).]

[ELP]

"128 is the correct value"
of course, yes.

0 ; 0x80 = 128

And yes really there must be a bug...
REAPER V5 and also V4.78 indicate, no matter which mixing depth,
0dB 8 bit wav as -48.1dB
which is false.

Oh oh
REAPER V5 & V4.78 Output


It should of course look like these output from an different program.


16/24/32 & 32float is ok Output Reaper = UFL ; 8 bit files within REAPER not

[Tale]

Thanks for confirming.

Originally Posted by ELP

0-255; 0x00-0xFF
-127 > -1 ; 0xFF-0x81
0 ; 0x80 = 128
1 > 127 ; 0x01 - 0x7F

Er... Just to make sure I understand 8 bit PCM correctly myself, when I convert from floating point to 8 bit PCM I get:

-1.0 => 0
-0.5 => 64
 0.0 => 128
+0.5 => 192
+1.0 => 255

Is that correct?

[ELP]

"-1.0 => 0
-0.5 => 64
0.0 => 128
+0.5 => 192
+1.0 => 255
"

Yes of course Tale ,
i make a little mistake inside above why the hell..
My big fingers were faster than my little brain

0-255
0x00 - 0x7F is of course amplitude -128 > -1
0x80 =128 DC 0
0x81 - 0xFF ampli 1 > 127

now

[Tale]

OK cool, thanks!

[ELP]

But all that doesnt matter, you found an maybe longstanding bug...

together with 8 bit files, Reaper produce an DC offset, where none should be

[Justin]

Hah that has to be some kind of record for unnoticed bug, dating to 2005 or 2006... Fixed in 5.01pre6 I think, thanks!

[bennetng]

I don't really understand this 2's complement thing. Regardless of -inf = 127 or 128, the values for + and - are still asymmetrical.

If -inf is 128, does it mean 0dBFS is either 1 or 255, 0 is unused?

If -inf is 127, does it mean 0dBFS is either 0 or 254, 255 is unused?

[Tale]

Originally Posted by Justin

Hah that has to be some kind of record for unnoticed bug, dating to 2005 or 2006... Fixed in 5.01pre6 I think, thanks!

Yeah well, I guess it's because, even back then, who really uses 8 bit, right? Anyway, fix(es?) confirmed, thanks.

Originally Posted by bennetng

I don't really understand this 2's complement thing. Regardless of -inf = 127 or 128, the values for + and - are still asymmetrical.

If -inf is 128, does it mean 0dBFS is either 1 or 255, 0 is unused?

If -inf is 127, does it mean 0dBFS is either 0 or 254, 255 is unused?

Actually I think it is the other way around: All values in the 0..255 are used, but converted to floating point +1.0 is not used (because 255 is slightly less than +1.0).

#include <stdio.h>
#include "WDL/pcmfmtcvt.h"
int main() { for (int i = 0; i <= 255; ++i) { double d; UINT8_TO_double(d, i); printf("%d %f\n", i, d); }}

0 -1.000000
1 -0.992188
2 -0.984375
3 -0.976563
4 -0.968750
5 -0.960938
6 -0.953125
7 -0.945313
8 -0.937500
9 -0.929688
10 -0.921875
11 -0.914063
12 -0.906250
13 -0.898438
14 -0.890625
15 -0.882813
16 -0.875000
17 -0.867188
18 -0.859375
19 -0.851563
20 -0.843750
21 -0.835938
22 -0.828125
23 -0.820313
24 -0.812500
25 -0.804688
26 -0.796875
27 -0.789063
28 -0.781250
29 -0.773438
30 -0.765625
31 -0.757813
32 -0.750000
33 -0.742188
34 -0.734375
35 -0.726563
36 -0.718750
37 -0.710938
38 -0.703125
39 -0.695313
40 -0.687500
41 -0.679688
42 -0.671875
43 -0.664063
44 -0.656250
45 -0.648438
46 -0.640625
47 -0.632813
48 -0.625000
49 -0.617188
50 -0.609375
51 -0.601563
52 -0.593750
53 -0.585938
54 -0.578125
55 -0.570313
56 -0.562500
57 -0.554688
58 -0.546875
59 -0.539063
60 -0.531250
61 -0.523438
62 -0.515625
63 -0.507813
64 -0.500000
65 -0.492188
66 -0.484375
67 -0.476563
68 -0.468750
69 -0.460938
70 -0.453125
71 -0.445313
72 -0.437500
73 -0.429688
74 -0.421875
75 -0.414063
76 -0.406250
77 -0.398438
78 -0.390625
79 -0.382813
80 -0.375000
81 -0.367188
82 -0.359375
83 -0.351563
84 -0.343750
85 -0.335938
86 -0.328125
87 -0.320313
88 -0.312500
89 -0.304688
90 -0.296875
91 -0.289063
92 -0.281250
93 -0.273438
94 -0.265625
95 -0.257813
96 -0.250000
97 -0.242188
98 -0.234375
99 -0.226563
100 -0.218750
101 -0.210938
102 -0.203125
103 -0.195313
104 -0.187500
105 -0.179688
106 -0.171875
107 -0.164063
108 -0.156250
109 -0.148438
110 -0.140625
111 -0.132813
112 -0.125000
113 -0.117188
114 -0.109375
115 -0.101563
116 -0.093750
117 -0.085938
118 -0.078125
119 -0.070313
120 -0.062500
121 -0.054688
122 -0.046875
123 -0.039063
124 -0.031250
125 -0.023438
126 -0.015625
127 -0.007813
128 0.000000
129 0.007813
130 0.015625
131 0.023438
132 0.031250
133 0.039063
134 0.046875
135 0.054688
136 0.062500
137 0.070313
138 0.078125
139 0.085938
140 0.093750
141 0.101563
142 0.109375
143 0.117188
144 0.125000
145 0.132813
146 0.140625
147 0.148438
148 0.156250
149 0.164063
150 0.171875
151 0.179688
152 0.187500
153 0.195313
154 0.203125
155 0.210938
156 0.218750
157 0.226563
158 0.234375
159 0.242188
160 0.250000
161 0.257813
162 0.265625
163 0.273438
164 0.281250
165 0.289063
166 0.296875
167 0.304688
168 0.312500
169 0.320313
170 0.328125
171 0.335938
172 0.343750
173 0.351563
174 0.359375
175 0.367188
176 0.375000
177 0.382813
178 0.390625
179 0.398438
180 0.406250
181 0.414063
182 0.421875
183 0.429688
184 0.437500
185 0.445313
186 0.453125
187 0.460938
188 0.468750
189 0.476563
190 0.484375
191 0.492188
192 0.500000
193 0.507813
194 0.515625
195 0.523438
196 0.531250
197 0.539063
198 0.546875
199 0.554688
200 0.562500
201 0.570313
202 0.578125
203 0.585938
204 0.593750
205 0.601563
206 0.609375
207 0.617188
208 0.625000
209 0.632813
210 0.640625
211 0.648438
212 0.656250
213 0.664063
214 0.671875
215 0.679688
216 0.687500
217 0.695313
218 0.703125
219 0.710938
220 0.718750
221 0.726563
222 0.734375
223 0.742188
224 0.750000
225 0.757813
226 0.765625
227 0.773438
228 0.781250
229 0.789063
230 0.796875
231 0.804688
232 0.812500
233 0.820313
234 0.828125
235 0.835938
236 0.843750
237 0.851563
238 0.859375
239 0.867188
240 0.875000
241 0.882813
242 0.890625
243 0.898438
244 0.906250
245 0.914063
246 0.921875
247 0.929688
248 0.937500
249 0.945313
250 0.953125
251 0.960938
252 0.968750
253 0.976563
254 0.984375
255 0.992188

BTW, here you will find some info on the subject:
http://wiki.multimedia.cx/?title=PCM#Sign

[bennetng]

Thanks! Nice information

[ELP]

really some longstanding,.....Tale. You get 10 points

"Tale: Yeah well, I guess it's because, even back then, who really uses 8 bit, right"

All these "loudness war kiddies" ^^
For such music it really doesnt matter
to use and or store as 4bit,8bit,16,24,32 or with thousends of bits
It phy. sounds all the same.

----------
But is really good that this is fixed, thanks Justin.
Only one 8 bit file inside an project and you get wrong DC offset.
----------

"bennetng : the values for + and - are still asymmetrical."

The range of integer is always asymmetrical!

Example:
16 Bit
0-65535 = 65536 values
65536/2
=
32768 ;C

0 - 32767 ;
=32768 values

32769-65535 ;
=32767 values
---

So remember ,@Audiophile users with extrasensory perception:

you have to use as much as possible the left of everything and you get an scientific higher resolution!! ..

True or False? Or is it maybe for "Audiophile extrasensory perception people" only half-true/half-false,
which would be the real scientific center position, but not exist in our binary world?