🚀 go-pugleaf

This is what I use for 8-bit samples :-

int lv=(int)((unsigned char)wvhdr->lpData[0])-128;
-- 
Mark Jacobs

"Fraser Ross" <fraserATmembers.v21.co.unitedkingdom> wrote in message
news:4166532e@newsgroups.borland.com...
| When using sound samples that are signed 8 bit is there a midpoint value?
| Since there is an even number of possible values there is not a logical
| midpoint.  Should I view 0 as a positive value so that there are 128
| positive values and 128 negative values or call it the midpoint and not use
| the value -128?

"Mark Jacobs"
> This is what I use for 8-bit samples :-
>
> int lv=(int)((unsigned char)wvhdr->lpData[0])-128;
> -- 

That isn't an answer to my question.  BTW I don't think the cast to int is
necessary.

My former suggestion of 128 positive values and 128 negative values and
using 0 as if it is the midpoint seems to be the norm.

Fraser.

The midpoint is -0.5.  When rounded it is 0 so the format makes logical
sense.

Fraser.

Fraser Ross wrote:

> "Mark Jacobs"
> 
>>This is what I use for 8-bit samples :-
>>
>>int lv=(int)((unsigned char)wvhdr->lpData[0])-128;
>>-- 
> 
> 
> That isn't an answer to my question.  BTW I don't think the cast to int is
> necessary.
> 
> My former suggestion of 128 positive values and 128 negative values and
> using 0 as if it is the midpoint seems to be the norm.
> 
> Fraser.
> 
> 


Yes, that answers your question, and actually in a very clear manner.

Recorded audio samples are either unsigned 8-bit or signed 16-bit. If 
there is an exception to the rule, I've never heard of it.

When dealing with signed 16-bit samples no problem. When dealing with 
unsigned 8-bit values there is an issue, which you seem to know of.

Most audio transformation algorythms are designed for signed wave forms 
and feeding them with an unsigned wave form would result in strange 
result (although some music enthousiasts like strange result). Therefore 
you want to convert the unsigned wave form into a signed one. To do this 
you substract 128 ((2^8)/2) from you unsigned samples as you transfer 
them into a signed container. No mathematician could deny that formula, 
it's basic arythmetic. Knowing the middle-point is irrelevant. There is 
no middle-point in an audio sample. If you believe a middle-point would 
be a point of silence you are off-track. Don't forget to transfer your 
samples into unsigned container when done processing before you try to 
play it back.

Mark Jacobs answer is the only good answer to your question. If you 
don't trust that answer do some research (although you will probably 
find that audio experts don't publish much free stuff on the net -- 
actualy they don't even publish much for-a-fee stuff anywhere).


Hope this helps and have fun with your audio samples,

Tom :)

Thanks Tom. That formula certainly works on all PC systems I've ever tried it
on! Example apps using 8-bit unsigned samples are in VU meters at
http://www.jacobsm.com/index.htm#sft - look at MJ Player and MJ Calculator.
-- 
Mark Jacobs

"Tom|420" <tom420.duhamel@gmail.com> wrote in message
news:417db647$1@newsgroups.borland.com...
| Fraser Ross wrote:
|
| > "Mark Jacobs"
| >>This is what I use for 8-bit samples :-
| >>int lv=(int)((unsigned char)wvhdr->lpData[0])-128;
| >
| > That isn't an answer to my question.  BTW I don't think the cast to int is
| > necessary.
| > My former suggestion of 128 positive values and 128 negative values and
| > using 0 as if it is the midpoint seems to be the norm.
|
| Mark Jacobs answer is the only good answer to your question. If you
| don't trust that answer do some research (although you will probably
| find that audio experts don't publish much free stuff on the net -- 
| actualy they don't even publish much for-a-fee stuff anywhere).

Mark Jacobs wrote:

> Thanks Tom. That formula certainly works on all PC systems I've ever tried it
> on! Example apps using 8-bit unsigned samples are in VU meters at
> http://www.jacobsm.com/index.htm#sft - look at MJ Player and MJ Calculator.

No problem sir. I hate that when someone doesn't trust an answer which I 
know is right. May I suggest that you explain your answers in the 
future? I must admit that I don't always trust an answer given just as 
plain as this. Often, even if you don't understand the explanations, you 
at least know that the person who answered knows what he is talking about.

I visited you website last night, and I must blame it to be the cause of 
getting to bed too late :P  I like you philosphy. Didn't try your 
software but I should eventually.

Have a nice day

Tom :)

The formula does not answer my question.  I did not even mention unsigned 8
bit values or any 16 bit values.

Fraser.