I don't think you're going to find a standalone application that will fix up your particular selection of incorrectly-tagged encodings. Having a mixture of cp1252, UTF-16 and GB-18030 is quite unusual and I don't think existing software will be able to solve that automatically.
So I'd download Mutagen and write a custom Python script to automate your own decisions about how to fix up unknown encodings. For example:
tryencodings= 'gb18030', 'cp1252'
for child in os.listdir(path):
child= os.path.join(path, child)
for mp3 in findMP3s(child):
for path in findMP3s(musicroot):
for key, value in id3.items():
if value.encoding!=3 and isinstance(getattr(value, 'text', [None]), unicode):
for encoding in tryencodings:
raise ValueError('None of the tryencodings work for %r key %r' % (path, key))
for i in range(len(value.text)):
The above script makes a few assumptions:
Only the tags marked as being in encoding 0 are wrong. (Ostensibly encoding 0 is ISO-8859-1, but in practice it is often a Windows default code page.)
If a tag is marked as being in UTF-8 or a UTF-16 encoding it's assumed to be correct, and simply converted to UTF-8 if it isn't already. Personally I haven't seen ID3s marked as UTF (encodings 1-3) in error before. Luckily encoding 0 is easy to recover into its original bytes since ISO-8859-1 is a 1-to-1 direct mapping of the ordinal byte values.
When an encoding 0 tag is met, the script attempts to recast it as GB18030 first, then if it's not valid falls back to code page 1252. Single-byte encodings like cp1252 will tend to match most byte sequences, so it's best to put them at the end of the list of encodings to try.
If you have other encodings like cp1251 Cyrillic, or a lot of cp1252 filenames with multiple accented characters in a row, that get mistaken for GB18030, you'll need a cleverer guessing algorithm of some sort. Maybe look at the filename to guess what sort of characters are likely to be present?