A few questions...

Scott Wheeler wheeler at kde.org
Tue Jul 11 15:16:44 CEST 2006

On Jul 11, 2006, at 2:42 PM, Jeff Mitchell wrote:
> When reading the ID in the UFID frame, I have come across a  
> situation where
> I'll save a uniqueid from an 8-character QString, but the value  
> returned when
> I try to read it back is 9 characters.
> When saving the frame, I use the following:
> file->ID3v2Tag()->addFrame( new  
> TagLib::ID3v2::UniqueFileIdentifierFrame(
>                         QStringToTString( ourId ),
>                         TagLib::ByteVector( m_uniqueId.ascii(),  
> randSize )
>                         ) );
> where ourId is Amarok's identifier, and m_uniqueId is a QString  
> consisting of
> randSize characters.
> However, when I read it back:
> m_uniqueId = TStringToQString( TagLib::String( ourMP3UidFrame( file,
> ourId )->identifier().data() ) );

At least here the extra ".data()" isn't needed.

> When this is run, m_uniqueId is equal to the uniqueId that was  
> saved into the
> tag, plus one extra character, which shows up in my debug as ? (I  
> could try
> to get the hex code for you if you want).  To solve this I've had  
> to add
> a .left( randSize ) onto the returned string:

It would be mostly interesting to see if it's a null.  I suspect that  
somewhere along the line in the conversion from TagLib::ByteVector to  
c-string to TagLib::String to QString it's picking up an extra null.   
Doing each of those conversions separately and seeing when the value  
picks up the extra character would also be useful.


More information about the taglib-devel mailing list