catzcat vs bzcat do different things... AKA "bzcat is broken

As long as some data is available, a read() call will return that amount of data immediately, even if it is less than the amount requested. Your input block size (65536) is larger than the likely output block size of either gunzip or bzcat, so there is always the possibility that less than 65536 bytes would be read, and dd will stop that the slower performance of bzcat results in there being only a partial block available when dd issues its read().

You might try running "dd ibs=4k obs=64k ..." and adjust your count parameter accordingly. With conventional I-O buffering, you should not encounter any partial 4K blocks. If you think that "should not encounter" sounds a bit dangerous, you're right. There is just no way to tell dd, "Unless you encounter EOF first, read 65536 bytes even if you have to wait for them." It just isn't the right tool for copying a precise amount of data from a pipeline or other communication channel. You can do it with "dd ibs=1 count=64k ...", but at the cost of horrible inefficiency (65536 invocations of the read() system call).

-- Bob Nichols AT comcast.net I am "rnichols42"