Of course it does leave 51 chars in base58 encoding. It is by no means surprising. As I said above, 152 flames, if you assume a flame codes only 2 bits i. e. two colors, inner and outer (with length bits EXCLUDED, exactly how you did exclude length information but using a different method), code 304 bits which is exactly the WIF length and as I said above, this is exactly the reason this theory was so appealing to many forum members (around page 29 of this thread I think)
Just to clarify terminology, WIF format is not 304 bits (my mistake on a previous post too, BTW).
WIF implies a base58 encoding because it's the format you import into a wallet. In this case, it would be either 306 bits for a non-compressed version and 312 for compressed version assuming 6 bits per char.
304 bits = 38 bytes which is enough space for a compressed 'raw' key (not base58, but the bytes before it gets base58 encoded) which fits just the inner/outer color informatin.
I think the subtle difference here is I don't exclude ALL length information when making the key. I include 2 bits to get up to that 306 number so I can make a base58 string. But I agree, this is not that surprising since I outlined all this around page 25 of this thread.