This is something I came across when trying to figure out what some of the "standard" information in the debug logs meant, and where it came from. The code contains this:
m_skipmode_m = bitrate / 8 / 90000 * m_cue->m_skipmode_ratio / 8;
and while there is a nearby comment saying, "i agree that this might look a bit like black magic." I don't think this is what it meant. The problem is that all of the quantities on the R/h side are integers, so the calculation is done using integer arithmetic. Since the * and / operators have equal precedence it will be done left-to-right. By the time the /90000 is done the intermediate result is a small integer (it was 5 in the recording I was testing with and could easily be lower). I don't think this integer truncation is intended. Replacing this with:
m_skipmode_m = (bitrate / 8) * (m_skipmode_frames / 8);
resolves this issue (although where the second 8 comes from is a bit of
a mystery). It also avoids doing the same division
(m_cue->m_skipmode_ratio / 90000) twice, although it's not
obvious in the original code that this was being done - it looks more
like a multiplication there, but it's not.
So nothing to do with the hang, but it's always a good idea to fix bugs when you come across them.