Follow-up on UniqueFileIdentifierFrame weirdness

[Jeff Mitchell]

Scott--

You asked me to follow up if I did some testing...here are some results (for 
MP3s...I haven't tested OGGs, but I expect they do not have the same 
problem).

I add a unique file identifier frame with the following:

file->ID3v2Tag()->addFrame( new TagLib::ID3v2::UniqueFileIdentifierFrame(
                        QStringToTString( ourId ),
                        TagLib::ByteVector( m_uniqueId.ascii(), randSize )
                        ) );
                file->save( TagLib::MPEG::File::AllTags );

where m_uniqueId and ourId are QStrings, randSize is an integer = 8.

eyeD3 shows the correct information:

Steve Miller Band - Greatest Hits 1974-78 - 01 - Swingtown.mp3  [ 5.52 MB ]
--------------------------------------------------------------------------------
Time: 3:29      MPEG1, Layer III        [ ~220 kb/s @ 44100 Hz - Joint 
stereo ]
--------------------------------------------------------------------------------
ID3 v2.4:
title: Swingtown                artist: Steve Miller Band
album: Greatest Hits 1974-78            year: None
track: 1                genre: General Listening (id None)
Unique File ID: [AMAROK - REDISCOVER YOUR MUSIC AT HTTP://AMAROK.KDE.ORG] 
*HX9GiAP

Now, I run this code:

QString temp = TStringToQString( TagLib::String( ourMP3UidFrame( file, 
ourId )->identifier().data() ) );
                QChar currchar;
                uint i;
                for( i = 0; i < temp.length(); i++)
                {
                    currchar = temp.at( i );
                    debug() << "value at position " << i << " is " << 
int((currchar.latin1())) << endl;
                }

ourMP3UidFrame simply iterates through the list of UFID frames for one 
matching our ID and returns it.

I get the following output:

value at position 0 is 42
value at position 1 is 72
value at position 2 is 88
value at position 3 is 57
value at position 4 is 71
value at position 5 is 105
value at position 6 is 65
value at position 7 is 80
value at position 8 is 24
value at position 9 is -110
value at position 10 is 14
value at position 11 is 8
value at position 12 is 41

As you can see, this equates to *HX9GiAP...plus five extra characters, one of 
which is negative.

This is what happens with every file...all are 13 characters long (when 8 was 
passed in to the frame constructor), and most of them contain both invalid 
(negative) and non-text ASCII characters.

eyeD3 is reporting the correct UID, so my feeling is that it is correctly 
stored in the file, but not being correctly read out of the file.  Things 
work fine if I do a left() on the QString to pull out the 8 left characters, 
but it shouldnt be necessary :-)

Thanks,
Jeff