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.

-Scott


More information about the taglib-devel mailing list