I really think they are complementary. Crc protects against corrupted
frames/bitstream and enables resync without necessarily decoding and playing
what might otherwise be a valid but garbage (and noisy) frame. You (should)
get a much more pleasant gap/skip instead of audio hell. Whereas checking
the sanity checking the contents of the data frame prevents the decoder
crashing or entering unknown states when processing the invalid frame (or,
in the case of a deliberately malicious frame with a valid crc, hopefully
prevents the decoder being exploited). Tremor, as far as I'm aware, does
both. It may well be possible to feed tremor 'valid frames according to the
spec with correct crc but essentially meaningless data' and it would of
course decode them but it shouldn't crash. If it crashes, sure, more checks
could be added but I believe Tremor is already pretty rigorous over data
sanitization. I don't really see the point of just removing the crc check
step, when it's part of the spec and serves a purpose.

On 1 Jul 2010 08:58, "Vladimir Pantelic" <pan_at_nt.tu-darmstadt.de> wrote:

pondlife wrote:
>
> I'd vote to remove CRC checks, but also maybe put a little effort in to
> check ...
nobody prevents you from putting a correct CRC for corrupted/malicious data
and, IIRC most MP3 files in the wild don't have a CRC anyway....
So, relying on the CRC to keep the decoder "safe" does not help much.
Received on 2010-07-01