ID3v2: Programmers' habits when describing bit-operations

Question

Hi.
I'm trying to implement a class that can read ID3v2 tags from MP3 files. The id3.org site seems to be the only source on the net where you can get information about the organisaton of ID3 tags.
Unfortunately I haven't worked with bit operations before and get quite confused about the fact why so many programmers describe the order of bits in octal values.
Let me quote a part of the description of ID3v2:
The ID3v2 tag size is encoded with four bytes where the most significant bit (bit 7) is set to zero in every byte, making a total of 28 bits.
I could understand that part. But the following leaves a huge question mark over my head...
The zeroed bits are ignored, so a 257 bytes long tag is represented as $00 00 02 01. ... An ID3v2 tag can be detected with the following pattern:
$49 44 33 yy yy xx zz zz zz zz
Where yy is less than $FF, xx is the 'flags' byte and zz is less than $80.
Can somebody of the veterans try to help me understand the first line, where the author describes in octal basis how these four bits are structured? Moreover I'd like to know what advantages it has to express bytes in octal values.
Regards,
Wan-Hi

Answer 1

...why so many programmers describe the order of bits in octal values.I doubt it. The endianness of data is either big-endian or little-endian (x86).
The ID3v2 tag size is encoded with four bytes where
the most significant bit (bit 7) is set to zero in
every byte, making a total of 28 bits.
The zeroed bits are ignored, so a 257 bytes long
tag is represented as $00 00 02 01.
That's not octal. it's hexadecimal.
0x00 0x00 0x02 0x01
In binary
  0000 0000 0000 0000 0000 0010 0000 0001
Strip out the msb in each byte
  x000 0000 x000 0000 x000 0010 x000 0001
and you you are left with 28 bits
  0000000000000000000100000001
or
  0000 0000 0000 0000 0001 0000 0001
or in hexadecimal
  0x0000101
or in decimal
  257