I'd expect the average difference in entropy of random data vs. a compressed format to be so small as to be a useless filter. After all if it wasn't so, it would be bad compression. Now I don't know about mp3 specifically...
However, since the format is also resilient and flexible, it should have a structure - even if that complexity is hidden in the codec - with a magnitude less entropy than the mis-decrypted possible plaintexts.
But yes, you compress, than encrypt. If your encrypted data is compressible or otherwise distinguishable from random noise, than you have (exploitable, correlatable) bias in your encryption functions, or you have inefficiency/redundancy in your compression.
I would think a very limited set of magic numbers/possible hex ranges would yield the highest performance per error.
A highly optimized (for this _exact_ context) hash/bloom function may yield comparable results, in general.
Or you can compute an efficient delineation algorithm using the docs:
https://www.loc.gov/preservation/digital/formats/fdd/fdd0001...
If the so many bytes of the rolling context don't match any numbers, keep brut'in the key til you have magic numbers and non-random garbage.