If you know the bias, then you can surely estimate the bit rate. Of course you could get very unlucky and wait a long time for bits, even with an unbiased underlying source. But that's the nature of these methods.
Or you could pump the heavily biased bit stream into a modern cipher and get a - for all intents and purposes - super high quality, completely unbiased random stream with the same bandwidth characteristics as the input.
And, as a matter of fact, much faster than the input if required.
Things are not so simple: how do you key the cipher? with the same randomness as the input string? If so, then that input distribution could be a bad one for the cipher, in that it might fail to generate a sufficiently scrambled output.
This can be mitigated if you use a unkeyed hash function instead, but even for these we don't have any provable guarantees unless you assume the function is a random oracle, which is an ideal object that cannot exist.
Yeah, if we’re starting with the “1 in a million” unfair coin then most of the input strings are going to be all 0 or all 1 which means the cipher is going to give the same sequence every time. Not useful!
