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