How To

Is there a standard for reading bytes?


SP4CEBAR 2023-03-03 16:30 (Edited)

A file contains values, for example a file explanation may say:

If a file explanation doesn't say if the MSB (most significant bit) goes first or last, and it doesn't say which byte is more significant, what should I assume?


The byte that stores Parameter A could be made up of bits arranged like:

  1. "AAAAA---", or
  2. "---AAAAA"

The bits that store Parameter B are spread out over three bytes, these values can be arranged like:

  1. (3 bits from byte 1) + 2^3 * (8 bits from byte 2) + 2^11 * (6 bits from byte 3)
  2. (6 bits from byte 3) + 2^6 * (8 bits from byte 2) + 2^14 * (3 bits from byte 1)

Is there a standard or does it depend on the file?

SP4CEBAR 2023-03-03 16:40 (Edited)

Also, If I remember it correctly

NX does
- MSBit last
- MSByte last

MP3 files
- MSBit first
- MSByte first

Timo 2023-03-03 19:18

I would say there are several standards ;) So a file format description should say if it‘s MSB first or last.
I guess MP3 is even more specific because it‘s compressed and every bit counts.

SP4CEBAR 2023-03-03 23:21 (Edited)

Thank you
Only the data parts of MP3 files are compressed, the headers contain values made up of a fixed number of bits

Jeanmilost 2023-03-04 12:16

@SP4CEBAR it seems that your question is about endianness, right?

SP4CEBAR 2023-03-04 12:49

Yes, I've never heard about it tbh

Jeanmilost 2023-03-05 00:35 (Edited)

So as far as I know the system defines an endianness, which indicates the manner a value is written in memory. Normally Windows and iOS are little endian, meaning that e.g 3 will be written 00000011 whereas some Linux or MacOS systems, like the ones for PowerPC are big endian, meaning that 3 will be written 11000000. So the first thing to do is to define the endianness of the system. I assume that LowResNX should inherit the endianness from its host system, but it should be verified. A solution to do that would be to poke 1 in a 32 bit value, then peek the first 16 bit value. If this value isn’t 0 then the system is big endian.

Then a file may also define an endianness, this depends on the file itself. The endianness may be read from the file, or implicitly defined by the file format. If I remember well MP3 files are commonly written in little endian, so you shouldn’t have to worry about that if LowResNX is also little endian. However if you want to check, a possible solution would be to read the file signature (which may be FF FB or ID3 for a MP3 file, see: and check the order it is written. If you read an inverted value (FB FF or 3DI) then the file is written in big endian.

It’s all I remember about that. Hope it may help.

McPepic 2023-03-05 13:05

I thought that endianness only involved the order of multiple bytes that were part of the same value, rather than the order of bits in each byte?

SP4CEBAR 2023-03-05 13:30

@JeanMilost thank you!
@Mcpepic I think the two are used together... I mean, it wouldn't make sense to write:
%FFF as F0FF

Timo 2023-03-05 13:52

I also think it‘s only the byte order, not bits.
And yes, 0FFF might look like FF0F 😮.
I think it has something to do with the step from 8bit CPUs to 16bit, as they wanted to keep things compatible.

SP4CEBAR 2023-03-05 15:56


Jeanmilost 2023-03-12 10:03

@McPepic @Timo Oh my bad, you’re right, it’s byte order, not bit. Indeed FF FE in big endian gives FE FF in little endian. I was tired when I wrote my message above.

However the memory test I mention remains valid: write 1 as a 16 bit value and read the 8 first (or last) bit will determine the endianness, depending if the 8 bit value returns 1 or 0.

Log in to reply.