On Jan 25, 2004, at 11:08 PM, Grigory A. wrote:
In my system minimum accessible variable is 16 bits wide. So I can use two technique I. Use low part of my 16 bits wide char. Use default #define CHAR_BIT 8
- this one working well.
II. Try to use #define CHAR_BIT 16. This one has several problems
- in decode_header() here
sync: ... else if (!(ptr[0] == 0xff && (ptr[1] & 0xe0) == 0xe0)) { ... goto fail; }
I am trying to solve this problem for the next libmad release, and will probably be using an expression like follows:
((ptr[0] << CHAR_BIT) | ptr[1]) >> (CHAR_BIT * 2 - 11) == 0x7ff
- III_huffdecode() function. I guess problem is here:
// ---- align bit reads to byte boundaries ----- takes up to 32 bit ?? cachesz = mad_bit_bitsleft(&peek); cachesz += ((32 - 1 - 24) + (24 - cachesz)) & ~7; ...
or here:
if (cachesz < 21) { unsigned int bits; bits = ((32 - 1 - 21) + (21 - cachesz)) & ~7; ...
It isn't work - at the middle of mp3 file I have MAD_ERROR_BADHUFFDATA
I'm not sure why you are getting this error...
So could you say to me these numbers: 32, 24, ... - what is the reason and how to calculate them for my case #define CHAR_BIT 16 ?
I don't think you should need to change these values. The idea is to build up a cache of bits that is (in this case) at least 21 bits in size, but strictly less than 32. The calculation ensures that bits are always read in multiples of 8, but it should not matter if CHAR_BIT is different than this.
And what I need to do more - to work with 16 bits wide char?
The only other place I've identified a problem is in mad_stream_sync(); the solution should be the same as for decode_header().
If you find anything further, please let me know.
Thanks,