search for: getendianbytes

...nd to make room for the new bits. When pulling values out of > the accumulator, you do that based upon the number of bits > requested. The accumulator will have to be (long long) because you > will sometimes request more than 32 bits. > > In other words, instead of: > > GetEndianBytes(streamArray, streamOffset, numBytes); > > ... you should implement: > > (long long)GetBigEndianStreamBits(streamHandle, (unsigned)numBits); > > The return value will have to be 64-bit to handle totalSamples. > The nice thing is that you won't need any indexing or bit shi...

...tream implementation. But I'd be > really pleased if anyone pointed me out how to deal with endianness. Just because you've been able to hack around without a bitStream implementation doesn't mean you're doing it right! :-) I took a look at your code, and you're calling GetEndianBytes(adr, ofs, n); with n > 1, and that's wrong. You cannot look ahead in a stream, and so your code is already doing things in a way that is not to spec. You then use array indexes and bit shift operators to build multi-byte values. What's worse, I see that your code is looking at...

Thank you very much! But how to deal with endianness in the case of bit stream? Some blocks (for example MinBlockSize) require 16bits (simply swap first and second), some block (e.g.MinFrameSize) require 3 byte-array to be reverted. Finally totalSamples is stored in 5 bytes ( only last 4 bits from first one byte are used). It was a real issue to make it little-endian (here is how I did it: