Byte Wrapping
Blitz3D Forums/Blitz3D Programming/Byte Wrapping
| ||
| Hey all, it's been a while. I've been following posts here, but I haven't logged in for quite some time. I have a question about byte wrapping. I am considering writing a program that manipulates sound waves (just an idea, I may not go through with it because it would be a lot of work), but I got wondering about how to handle a sound wave that clips. If Blitz byte wraps, how can you tell if a sound wave is going to clip due to amplification and stop it from wrapping? From my perspective, there really doesn't seem to be a way to predict this other than setting a threshold which stops the byte from expanding further. You can't use a comparison operator because the wrap occurs before the check. Thoughts? |
| ||
| "Byte wrap"? I assume you mean integer overflow, right? Are you planning on doing math operations on single bytes, or using the term to mean overflow in the general case? If you're using individual bytes, you should be able to either predict overflow scenarios, or more likely just clamp the value in a second operation..? Anyway, one possible solution would be to use floats as much as possible, since floats don't overflow, they just go to + or - Infinity (and have a ridiculously large range before that). You could do a preliminary loop over the byte steam and just expand it into a bank four times the size? |
| ||
| Yeah, I'm talking about integer overflow. I've always heard it called byte wrapping, but a quick Google search shows that integer overflow is the correct term. So floats won't overflow, huh? I guess that makes sense because it's called integer overflow and not floating point number overflow. So if I understand this right, you're saying something like this: ;with the overflow problem Local myNumber% = 4294967295 ;max for 32 bits myNumber = myNumber + 1 Print myNumber ;should print 0 ;same situation, but floats are used Local myNumber# = 4294967295.0 myNumber# = myNumer + 1.0 Print myNumber ;should print 4294967296.0, which I can then assume has clipped and reset back to 4294967295.0 I am going to give this a couple of test shots. If this is the case, then it's easy enough to convert to and from integers based on what I need the program to do. This is very handy information. |
| ||
| Floats won't overflow, but it comes at the cost of precision; e.g. above ~16000000 a float is unable to distinguish individual integers any more (i.e. eventually, adding 1 to N will return N; a bit further along, adding ten to N will return N). They cluster their representable values very densely around 1.0 (fully half of all values fall between -1.0 and 1.0), and this trails off in a long curve (the curve going all the way to infinity) until eventually values as high as thousands can slip between the gaps. Thus a larger overall range can be represented in the same space as an integer; it also means that the integer max value you have there cannot be accurately represented in floating point at all. In practice this kind of behaviour is normally exactly what you want for "analog" values such as colours or sounds, because it works well with perception. |
| ||
| So you're saying that it can only hold a limited number of significant figures? That makes sense. The range is good enough for what I need it to do. It's been a LONG time since I've programmed, and it's hard going from studying calculus for a whole semester back to programming. I'm trying some of this stuff posted above, but I'm getting negatives coming out. If memory serves me well, my range will either be from 0 to 4294967295, or from -2147483647 to +2147483647. I'm thinking the negatives would be more suited to what I'm trying to accomplish because waves can fall above or below the state of rest at 0. Anyway, just thinking out loud. |
| ||
| Doing some testing, and this system works excellent! I can at least see whether or not the simulated integer exceeds the clipping range and avoid the overflow. Thanks for the help. |
| ||
| I'm getting negatives coming out. If memory serves me well, my range will either be from 0 to 4294967295, or from -2147483647 to +2147483647 Yeah B3D doesn't support unsigned integers, so it wraps from +2147483647 to -2147483648. For addition and subtraction this actually makes no difference (on x86), as the internal representation of the negatives and the high-positives is identical anyway, so you can pass "negative" numbers to a C lib expecting an unsigned integer. |
| ||
| Actually this might not be a bad thing where sound is concerned, since amplitudes can be +ve or negative, sounds counter-intuitive I know, but i's how wavefunctions can be combined to 'cancel out' with interference. |
| ||
| Right, that makes sense. Sound is either compressed air or expanded air, so having positive and negative values are best for this system. |
| ||
| remeber that CD sound quality only uses 16 bit numbers so only 65536 voltage levels are considered. (at the very end, numbers are converted to anlog electronic singnals and handling more precision is unnecesary) the x1 cd velocity was from the following magicla formula: 44100 x 2 x 2 = 176,400 bytes per second, so a 80 minutes audio CD stores 800 MB aprox 2Bytes per sample, 2 channels (right and left), and 44100 samples per second. with 44100 samples per second you can store sounds with at least 20050 hz, wich is far beyond what ours ears can sense. so, i dont figure why you need more than 16 bits, probalby i missread the thread. For the electronic point of view, a sample of 1000 0000 0000 0000 is exaclty the middle of the total, you can see it as an unsigned int any value above that is positive, any behind is negative. It only has a DC constand added, or if you prefere it uses a notation called: in eccess Basically the signal is allways positive and in a final stage is filtered and the DC (excess) is discarded, resulting in moving backward or forward the speaker membrane... and sounds! About overflows, any finite representation may overflow, the thing is to use the correct amount of bits. Our machines becomes greater day by day but will never has infinite storage. (well... with today methods and technology) |
   |