SP4CEBAR 2023-03-03 16:30 (Edited)
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:
The bits that store Parameter B are spread out over three bytes, these values can be arranged like:
(3 bits from byte 1) + 2^3 * (8 bits from byte 2) + 2^11 * (6 bits from byte 3)(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: https://en.m.wikipedia.org/wiki/List_of_file_signatures) 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
@Jeanmilost
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
Interesting
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.