Yes, I use @CRC32 extensively for such purposes.
I have one .btm, CRC32TAG, which adds a "CRC: 0123CDEF" (example)
description to any file(s) I specify. It's a little smarter than
that, of course. It first checks to see if a description begins
with "CRC: " and if that's followed by a hex string. If it finds
such a match, it skips that file and moves on to the next. If it
doesn't find that, it adds the string to an undescribed file or
prepends it to any existing description.
Its complement is CRC32CHK, which looks for that same specific
format of string in a description. If one is found, the CRC is
computed anew and compared to the stored value. Results are
displayed in green for a match or red for a mismatch, giving a
visual clue that's very easy to spot. I like and use both .btms on
a regular basis. Writing them was time well spent. I almost never
have any need to create .md5, .sfv or .par2 files for myself
anymore. And since I nearly always use TCC to perform copy and move
operations, the descriptions travel around nicely from directory to
directory or drive to drive.
I also have a few PDIR commands that integrate just that portion of
a description into their output.
I realize that @CRC32 is probably the weakest of my available
choices in TCC but it produces the shortest output and is therefore
best suited to my needs.
-- Dan McMullin