It gets weirder. The CP_UTF8 option seems to work for data input to the OLE object, but not for returned data. It appears that data is returned in CP_ACP if possible, and only returned as a Perl string if conversion to CP_ACP fails. Nothing seems to be returned to indicate to the caller how the returned data is encoded. Please check whether I'm missing something or whether this is a bug. In test1.mp3, the 'artist' tag is "The Crüxshadows" and in test2.mp3 it's the Cyrillic text "Издатель." Is there a way for me to supply the files I'm using for testing? Thanks.

use strict;
use warnings;
use Encode qw( is_utf8 );
use Win32::OLE ();
Win32::OLE->Option ( CP => Win32::OLE::CP_UTF8 );

binmode( STDOUT, ':raw' );
my $filename = shift or die "No file specified\n";
my $dmcconverter = Win32::OLE->new('dMCScripting.Converter') 
    or die "Can't create dMCScripting.Converter object: $!\n";
my $data = $dmcconverter->AudioProperties($filename);
printf( STDERR "The UTF-8 flag for converter output is %d\n", is_utf8(
+$data) // 0 );
print "$data";


d:\Mp3\Encode>perl -S test-ole-out.pl D:\Mp3\Encode\test1.mp3 >test1.t
+xt
The UTF-8 flag for converter output is 0

d:\Mp3\Encode>perl -S test-ole-out.pl D:\Mp3\Encode\test2.mp3 >test2.t
+xt
The UTF-8 flag for converter output is 1
Wide character in print at D:\Batch/test-ole-out.pl line 15.
[download]

UPDATE: I just realized that part of the weirdness is in how Perl represents strings internally. I had been led to believe that it was (almost) UTF-8, but that doesn't seem to be the case. If I read the string "The Crüxshadows" from a file in raw mode, the string data is UTF-8 octets, with the UTF-8 flag off. If I read the same data with an ":encoding(UTF-8)" layer specified, the string data is cp1252 octets with the UTF-8 flag on.