there are a LOT of bugs that can be fixed quite easily in MAME by fudging the clocks.
such chances simply won't be accepted vs. actual measured values unless you can prove them to be correct tho, the end result isn't proof in this case, other things could be slowing the CPU down (waitstates on RAM/ROM, ready lines on sound chips etc.)
that said I'm not 100% sure the clocks are properly verified in vaportra.c
crude buster, which uses the same sound system (and apparnetly suffers from the same problem in places) has the clock 'verified' at 6Mhz (derived from the main crystal, not the 32.2 one, which is apparently only used for the actual sound chips) that's still some way off what you're suggesting tho, so you'd really need to prove there was an internal divider we're missing via CPU documentation or similar.