As you have found out correctly, the length field describes the following script length. Then the SigScript follows:
004730440220762CE7BCA626942975BFD5B130ED3470B9F538EB2AC120C2043B445709369628022051D73C80328B543F744AA64B7E9EBEFA7ADE3E5C716EAB4A09B408D2C307CCD701483045022100ABF740B58D79CAB000F8B0D328C2FFF7EB88933971D1B63F8B99E89CA3F2DAE602203354770DB3CC2623349C87DEA7A50CEE1F78753141A5052B2D58AEB592BCF50F014CC9524104A882D414E478039CD5B52A92FFB13DD5E6BD4515497439DFFD691A0F12AF9575FA349B5694ED3155B136F09E63975A1700C9F4D4DF849323DAC06CF3BD6458CD41046CE31DB9BDD543E72FE3039A1F1C047DAB87037C36A669FF90E28DA1848F640DE68C2FE913D363A51154A0C62D7ADEA1B822D05035077418267B1A1379790187410411FFD36C70776538D079FBAE117DC38EFFAFB33304AF83CE4894589747AEE1EF992F63280567F52F5BA870678B4AB4FF6C8EA600BD217870A8B4F1F09F3A8E8353AE
The script starts with a hex "0", which compensates for a very early "off by one error" in the execution routines of the checksig routines. An element too much was popped off the stack. This "bug" is so long in the system, that everyone got accustomed to it, and removing it requires an enormous effort. So it became a feature :-) Even more, if there are tx, which have an execution time in the future, they wouldn't work anymore...
how did the explorer find out that it is 2-3 multisig. In the
first place how to identify a multisig?
The explorer finds this in the script sig. There is the two signatures, and the part for the multisig:
<sig1> <sig2> <length> OP2 <pubkey1> <pubkey2> <pubkey3> OP3 AE
to be better able to view, I have decoded the script a bit. The sigs start with hex 0x47 or 0x48, and end with 0x01. They are ASN1-DER encoded, providing a view into the R and S fields, and have surrounding length information. After the second 0x01, follows the length field, and then the multisig OPcode (0x02) and the 3 pubkeys.
00: OP_0, OP_FALSE: an empty array is pushed onto the stack.
<sig1>
47: OP_DATA_0x47: push hex 47 (decimal 71) bytes on stack
30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
44: OP_LENGTH_0x44: length of R + S
02: OP_INT_0x02: type tag INTEGER indicating length
20: OP_LENGTH_0x20: this is SIG R (32 Bytes)
02: OP_INT_0x02: type tag INTEGER indicating length
20: OP_LENGTH_0x20: this is SIG S (32 Bytes)
01: OP_SIGHASHALL: this terminates the ECDSA signature (ASN1-DER structure)
<sig2>
48: OP_DATA_0x48: push hex 48 (decimal 72) bytes on stack
30: OP_SEQUENCE_0x30: type tag indicating SEQUENCE, begin sigscript
45: OP_LENGTH_0x45: length of R + S
02: OP_INT_0x02: type tag INTEGER indicating length
21: OP_LENGTH_0x21: this is SIG R (33 Bytes)
02: OP_INT_0x02: type tag INTEGER indicating length
20: OP_LENGTH_0x20: this is SIG S (32 Bytes)
01: OP_SIGHASHALL: this terminates the ECDSA signature (ASN1-DER structure)
4C: OP_PUSHDATA1: next byte is # of bytes that go onto stack
C9: OP_Int(0x01-0xff): 201 bytes onto the stack
52: OP_2: the number 2 is pushed onto stack
################### we go multisig ####################################
41: OP_DATA_0x41: uncompressed pub key (65 Bytes)
41: OP_DATA_0x41: uncompressed pub key (65 Bytes)
41: OP_DATA_0x41: uncompressed pub key (65 Bytes)
53: OP_3: the number 3 is pushed onto stack
################### 2-of-3 Multisig ###################################
AE: OP_CHECKMULTISIG: terminating multisig
You find a very good explanation in chapter 6 "Transactions" and 7 "Advanced Transactions and Scripting" of Andreas' wonderful book "Mastering Bitcoin", which is also online available.