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" <[email protected]> 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.
