When a file is very, very short (i.e., only one packet) and uses
 end-trimming, the apparent granule position preceding the first
 sample in the first packet can underflow.
We were computing this value by subtracting the packet duration
 from the computed per-packet granule position and expecting this
 computation to always succeed.
Because it could fail in the presence of end-trimming on the first
 packet (ironically, exactly the situation where the short-circuit
 is helpful), it would leave the value uninitialized, and then use
 it in a comparison, which is undefined behavior.
The correct solution is to check for failure and force the previous
 page's granule position to 0 in this case.