isnt that basically the same as the previous comment? That one fails to work properly in all cases iirc, hence why it didn't live long after commit before we reverted it. (revisions 1754 and 1765, and bug 223547, if you're curious)
Really, I don't think there is _any_ safe way to autodetect the encoding, and until that statement is proven wrong (by logic, not example), I am very much inclined not to accept any such patches. What I would like to do is instead offer an option in the tag editor to correct misencoded tags manually, as that is safe and will restore the files to a standards-compliant format, which they should be in in the first place.
It's also worth noting that your patch only works at scan time - it won't help users who already have misencoded tags in their databases unless they force it to re-read the tags. Offering a reencode option in the tag editor would work for that case as well.
isnt that basically the same as the previous comment? That one fails to work properly in all cases iirc, hence why it didn't live long after commit before we reverted it. (revisions 1754 and 1765, and bug 223547, if you're curious)
Really, I don't think there is _any_ safe way to autodetect the encoding, and until that statement is proven wrong (by logic, not example), I am very much inclined not to accept any such patches. What I would like to do is instead offer an option in the tag editor to correct misencoded tags manually, as that is safe and will restore the files to a standards-compliant format, which they should be in in the first place.
It's also worth noting that your patch only works at scan time - it won't help users who already have misencoded tags in their databases unless they force it to re-read the tags. Offering a reencode option in the tag editor would work for that case as well.