Time code example and time code byte endianess

[JeromeMartinez]

I try to understand the example in https://github.com/ietf-wg-cellar/matroska-specification/blob/master/block_additional_mappings/smpte-st12-1-timecode.md.

I have split the example and manually decoded it, here is my outcome (lower case for units, upper case for tens, B for binary group and flags, first line the binary example, second line the mapping, third line the decoded value, fourth line the expected decoded value based on time code string if not same as manually decoded value):

10000000 01100000 01100000 01010000 00100000 00110000 01110000 00000000
ffffBBBB FFDCBBBB ssssBBBB SSSPBBBB mmmmBBBB MMMBBBBB hhhhBBBB HHBBBBBB
   8   0  110   0    6   0   21   0    2   0   11        7   0  000   0
                     4       50                30

I have well frames (18) and hours (7) but everything else seems wrong, What am I missing in my decoding?
Note that I considered that each group of bits (units of frame etc) is with MSB first (bit order is big endian) and byte sequence is little endian for catching the units of frames of 8, but I read in SMPTE ST 12-1 that first bit is LSB, is it sure that first bit is MSB?

If I check e.g. time code in Dolby E (Dolby E high level frame description, page 25), SMPTE time code is in pure big endian (but mangled! in order to have binary groups in whole bytes) so units of frame are in the last byte (1000 would be the 4 LSB bits of last byte)

So if I do as I understand the current MKV spec, with "big endian" (as in Dolby E) with SMPTE ST 12-1 order, IMO example "07:32:54;18" would be:

00000000 00000111 00000011 00000010 00000101 00000100 00000101 00001000
BBBBBBHH BBBBhhhh BBBBBMMM BBBBmmmm BBBBPSSS BBBBssss BBBBCDFF BBBBffff
     0 0    0   7    00  3    0   2    00  5    0   4    001 1    0   8

Note that SMPTE ST 331, as well as DV, have a different way to pack: beside the removal of the binary groups, bits in a byte are in big endian order, but bytes in the sequence are in little endian, which leads to this bits (verified with a MXF demuxer with ST 331 support):

01011100 01010100 00110010 00000111
CDFFffff PSSSssss BMMMmmmm BBHHhhhh
01 1   8 0  5   4 0  3   2 00 0   7

So IMO we need to be clear about bit order in a byte and byte order in a sequence.